Re: problem while examinate 802.11-packets

[Guy Harris <guy () alum mit edu>]

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.