Christian Stålp wrote:
Argh, thats are very very sad news. That dumps all my ideas. My project
was to track the retry field and in case of a dramitical increase switch
over to the monitor mode, and see what wrong. Maybe you see some
pattern, some events? My idea was to obserse which station in the bss
has the most troubble while transmission.
Is there really now way to track these information from the fake
ethernet-frames?
No, there's no way to track, for example, the Retry flag in the Frame
Control field; the only packets you'll see outside of monitor mode are
data frames, and the frame control field will be discarded - there's no
place to put that information in a fake Ethernet header.
Now, if you were using *BSD, you might be able to get 802.11 headers
from adapters without putting the device into monitor mode, the way I
described in my earlier mail. Unfortunately, Linux doesn't have a
standard mechanism for requesting particular link-layer header types,
and I don't know if any drivers support
yes this confused me also the first time. But the real target of my
project is the broadcom-chip. This means this is thought to become a
daemon on a openwrt-AP. And now that become more complex that I thought.
If I consider how laborious it is to send atheros (madwifi) into monitor
modus. This is not done with simple "iwconfig ath0 mode monitor", no you
have to create a monitor VAP first.
So that command doesn't work?
The page at
http://madwifi.org/wiki/UserDocs/MonitorMode
says
To create a monitor mode VAP, see: UserDocs/MonitorModeInterface. After
that, it won't be necessary to use the command iwconfig ath0 mode monitor.
which sounds as if it's saying that you *can* create a monitor mode
virtual access point, but that you don't have to - if you create one,
you don't have to do "iwconfig ath0 mode monitor", which seems to imply
that you could also do "iwconfig ath0 mode monitor".
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
