Search Linux Wireless

Re: Question about PRISM2 header rate field

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michael Wu wrote:

Hi Michael -

On Sunday 04 March 2007 20:02, Andy Green wrote:
How about for injection on the Management interface, it expects to find
a PRISM2 header prepended to the ieee80211 one and the payload, in
exactly the same format as is delivered by Monitor Mode?  The PRISM2
capture header structure has a bunch of fields for things like rate and
antenna selection already.  This has the satisfying aspect that you can
literally replay the whole Monitor Mode packet capture down the
Management Interface and get it to go out at the same rate.

Isn't this what aircrack does? I think many other drivers that support frame injection do it in a similar way (TX AVS frame on monitor interface), and this is also the way I prefer the frame injection interface. It does have the nice property of being able to directly replay captured traffic as you mentioned. Just note that AVS/prism2 is planned to be removed in favor of radiotap which is more extensible. Radiotap should also work for frame injection, though it isn't as easy as using a fixed length header format.

Radiotap is fine for me too. PRISM2 has a 32-bit magic at the start, I guess you can just check the first byte (Magic 0x1e for PRISM2, Version 0x00 for Radiotap) to find out what you have been given. Just returning -ENOSUPP or something else unique for an unsupported header will allow easy adaptation in userspace to what header system a given kernel will support for tx.

Radiotap also has better documentation in the form of the old stack header file at least. It's clear there's more than enough capability defined for my needs anyway, it will allow optional specification of antenna and even tx power too. It doesn't make any difference for me that it is variable length.

Note that modifying the management interface to do this is possible, but it would break hostap (and probably wpa_supplicant w/ MLME). Doing packet injection on monitor interfaces instead is safer in that regard.

Basing it around Monitor Mode interfaces will suit all the potential users I think, since they might already have one floating around, and they are easier to spawn than Management anyway.

-Andy
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux