RadioTap support

[nico@…]

RadioTap? is equivalent to PrismHeader?, but it is (or will be) used by a growing number of wifi drivers like ipw2200 (and by the Linux's unified ieee80211 stack also?).

This protocol is a crap to implement in scapy : fields must be naturally aligned, it's not a TLV (you have a 32 bits bitmap indicating which fields will follow the headers, and theses fields have a specific order), everything use the host's endianess (by the way, it lacks a LEBitEnumField), etc.

This patch is a bit messy, but it works well on ipw2200 and Atheros (the driver can use RadioTap? headers if you put 803 into /proc/sys/net/ath0/dev_type). There are two link layer numbers (127 and 803), one for Atheros, the other for the rest. It doesn't make sense to inject RadioTap? packet so it was written with "read-only mode" in mind.

Some documentation/reference :

•  http://netbsd.gw.com/cgi-bin/man-cgi?ieee80211_radiotap+9+NetBSD-current
•  http://madwifi.org/wiki/DevDocs/RadiotapHeader
•  http://www.tcpdump.org/lists/workers/2004/09/msg00062.html

-- Nicolas Bareil

[nico@…]

Patch (under the GNU GPL)

[frealek]

I tested the patch with ipw2100. It doesn't work as good as expected, because it fails to decode the payloads correctly.

$ file eth1.p
eth1.p: tcpdump capture file (little-endian) - version 2.4 (802.11 with radiotap header, capture length 65535)

>>> pkts = rdpcap('eth1.p')
>>> pkts
<eth1.p: UDP:0 TCP:0 ICMP:0 Other:1>
>>> pkts.show()   
0000 RadioTap / 802.11 Control 1L None > 00:ff:ff:ff:ff:ff / Dot11WEP
>>> pkts[0]    
Traceback (most recent call last):
  File "<console>", line 1, in ?
  File "./scapy.py", line 4953, in __repr__
    val = f.i2repr(self, self.fields[f.name])
  File "./scapy.py", line 5921, in i2repr
    return '%d / %0.3f GHz' % ((val-2407)/5.0, val/1000.0)
TypeError: unsupported operand type(s) for -: 'NoneType' and 'int'

It seems to work better with this mod :

47c47
< +        if val == 0:
---
> +        if not val:

Perhaps it is NOT the good way to fix this, I'm no scapy expert... I didn't take much time to understand why this None appears. This feels more like a workaround, just to get the underlying Dot11 packets.

I found out that radiotap_packet.payload removes only 11 bytes from the packet. As with the eth1.p attached packet, wireshark shows the radiotap header is "0000 0c00 2000 0000 eaff 0015", and str(radiotap_packet.payload) begins with '\x15@\x00\x00\x00\xff\xff\xff\xff\xff\xff...'.

This modification (of the patch) seems to work for me... but I'm not sure of the implications :

154c154
< +        pkt.l = pkt[RadioTap].len - pkt.l - 8 - 1 # 8 is the header's length
---
> +        pkt.l = pkt[RadioTap].len - pkt.l - 8 # 8 is the header's length

[frealek]

1 packet capture with radiotap header, from ipw2100

[.NetRolller 3D]

Radiotap is now used by Linux's new mac80211 stack for both injection and reception, so a new, "read-write" patch would be needed.