Hi folks -
This patch adds the monitor mode packet injection stuff that was talked
about a week or so ago to mac80211. Using a radiotap header prepended
to the injection payload was felt to be a reasonable way forward.
The patch can deal with a variable-sized radiotap header containing any
fields that are understood by Linux, although currently it skips
everything except antenna, power and rate selection. You just put an
interface in monitor mode and direct packets at it, selecting rate and
so on by using radiotap semantics.
Along with this patch I have also updated packetspammer
http://warmcat.com/packetspammer-0.3.tar.gz
to allow it to send [ radiotap + ieee80211 + payload ] packets from
userspace into a Monitor mode interface. The --help and README both
show how to do it. At the moment it simply injects a 54Mbps packet with
a ping-type payload in it to fixed fake MAC addresses, you can see these
packets from another box running in Monitor mode on the same channel.
I tested the rate action with a zd1211rw-mac80211 USB device and it
seems to be happy. I'm not sure how to test the antenna selection
action and didn't try to test the tx power selection action yet.
The patch is against Linville's FC7 #4 test kernel sources, which are
only a few days old.
-Andy
On Wednesday 14 March 2007 21:13, Andy Green wrote:
> This patch adds the monitor mode packet injection stuff that was talked
> about a week or so ago to mac80211. Using a radiotap header prepended
> to the injection payload was felt to be a reasonable way forward.
>
It seems rather odd to inject with radiotap headers when capturing with AVS
headers. I've attached a patch which switches mac80211 to using radiotap.
It's pretty much the same patch I posted a while ago, except all support for
AVS on monitor interfaces was removed. Drivers need to implement radiotap for
best results, but if it isn't implemented, the stack fills in a minimal
radiotap header. The minimal radiotap header filling code is new in this
version of the patch and I haven't had a chance to test it yet. The rate
filling part might be wrong. Anyway, I recommend basing your patch on top of
this one. Aside from the new default radiotap filling code, the rest is
fairly solid AFAIK. I had a corresponding patch to hook up radiotap support
in zd1211rw-mac80211 but it seems like I've lost it. I'll put together a new
one tomorrow.
Thanks,
-Michael Wu
Michael Wu wrote:
> On Wednesday 14 March 2007 21:13, Andy Green wrote:
>> This patch adds the monitor mode packet injection stuff that was talked
>> about a week or so ago to mac80211. Using a radiotap header prepended
>> to the injection payload was felt to be a reasonable way forward.
>>
> It seems rather odd to inject with radiotap headers when capturing with AVS
> headers. I've attached a patch which switches mac80211 to using radiotap.
Yes it seemed that radiotap on the capture part of Monitor was preferred
and seen as the place to end up from the last discussion. But the itch
I needed to scratch was the injection, so your patch and mine go
together really well in principle and migrate the whole stack to radiotap.
> It's pretty much the same patch I posted a while ago, except all support for
> AVS on monitor interfaces was removed. Drivers need to implement radiotap for
> best results, but if it isn't implemented, the stack fills in a minimal
> radiotap header. The minimal radiotap header filling code is new in this
> version of the patch and I haven't had a chance to test it yet. The rate
> filling part might be wrong. Anyway, I recommend basing your patch on top of
> this one. Aside from the new default radiotap filling code, the rest is
> fairly solid AFAIK. I had a corresponding patch to hook up radiotap support
> in zd1211rw-mac80211 but it seems like I've lost it. I'll put together a new
> one tomorrow.
Okay I will apply your code when I can resume work on this later today.
They shouldn't conflict since yours is only on the receive path and
mine only on the transmit path. I need to learn about quilt it seems.
I am monitoring from an ipw2200 box that issues driver radiotap headers
and tcpdump can do a lot more with them than the PRISM2 stuff.
> + struct ieee80211_rtap_hdr {
> + struct ieee80211_radiotap_header hdr;
> + u8 flags;
> + u8 pad0;
> + u8 rate;
> + u8 pad1;
> + __le16 chan_freq;
> + __le16 chan_flags;
> + u8 antsignal;
> + } __attribute__ ((packed)) *rthdr;
One thing though, what is the truth about endian-ness of radiotap args?
It seemed from the struct ieee80211_radiotap_header header version in
Linville's latest FC7 #4 RPM anyway that they were native endian, ie,
using u16 in there. I took from that the args were likewise u16, which
was possible since the radiotap part doesn't normally leave the machine.
But having fixed endianness makes more sense.
-Andy
On Thu, 2007-03-15 at 06:32 +0000, Andy Green wrote:
> It seemed from the struct ieee80211_radiotap_header header version in
> Linville's latest FC7 #4 RPM anyway that they were native endian, ie,
> using u16 in there. I took from that the args were likewise u16, which
> was possible since the radiotap part doesn't normally leave the machine.
> But having fixed endianness makes more sense.
I posted a patch that annotates radiotap as little-endian, but I haven't
seen any reaction so far.
I'm not aware of any driver that implements radiotap as native endian
(at least intentionally). All implementation I know are little endian,
even if it means sparse warnings (that's how I became aware of the
problem with the non-annotated include file for radiotap).
--
Regards,
Pavel Roskin