radiotap on linux

[Matthew Belcher]

Hi all,

I'm working on setting up radiotap header capture on Linux. I'm running the
latest kernel (2.6.16.18) with the radiotap extensions compiled in. I'm using
the madwifi-ng driver with an Atheros card. I pulled the latest tcpdump from
CVS. It looks like tcpdump is receiving the radiotap packets, but it can't
decode them. Here's the output I get:

21:22:43.157339 unknown IEEE802.11 frame type (3)(header) unknown IEEE802.11
frame type (3)unknown 802.11 frame type (3)
0x0000: ffff ffff ffff 0002 6f21 e671 0806 0321
0x0010: 0800 0604 0001 0002 6f21 e671 c0a8 0101
0x0020: 0000 0000 0000 c0a8 0102

Has anyone been able to get this to work?

Thanks,
Matt Belcher

[Mike Kershaw]

Post by Matthew Belcher
Hi all,
I'm working on setting up radiotap header capture on Linux. I'm running the
latest kernel (2.6.16.18) with the radiotap extensions compiled in. I'm using
the madwifi-ng driver with an Atheros card. I pulled the latest tcpdump from
CVS. It looks like tcpdump is receiving the radiotap packets, but it can't
21:22:43.157339 unknown IEEE802.11 frame type (3)(header) unknown IEEE802.11
frame type (3)unknown 802.11 frame type (3)
0x0000: ffff ffff ffff 0002 6f21 e671 0806 0321
0x0010: 0800 0604 0001 0002 6f21 e671 c0a8 0101
0x0020: 0000 0000 0000 c0a8 0102
Has anyone been able to get this to work?

Are you running it with -s0 (or some larger-than-default capture size)?
A full RT header can be bigger than the 32 or 64 or whatever the default
# of bytes is for tcpdump to process.

-m

[Matthew Belcher]

Post by Mike Kershaw
Are you running it with -s0 (or some larger-than-default capture size)?
A full RT header can be bigger than the 32 or 64 or whatever the default
# of bytes is for tcpdump to process.

Thanks for your suggestion. I tried it with -s0 to see if that would help.
Here's what I get now:

(none):~# tcpdump -i wifi0 -L
Data link types (use option -y to set):
IEEE802_11 (802.11)
(none):~# tcpdump -vv -i wifi0 -s0 -x
tcpdump: listening on wifi0, link-type IEEE802_11 (802.11), capture size 65535
bytes
11:41:33.240612 unknown IEEE802.11 frame type (3)More Data More Fragments Pwr
Mgmt Retry Strictly Ordered WEP Encrypted 65535us (header) unknown IEEE802.11
frame type (3)unknown 802.11 frame type (3)
0x0000: ffff ffff ffff 0002 6f21 e671 0806 0321 ........o!.q...!
0x0010: 0800 0604 0001 0002 6f21 e671 c0a8 0164 ........o!.q...d
0x0020: 0000 0000 0000 c0a8 0165

As you can see that doesn't seem to have helped. Are the radiotap packets in
Linux formatted differently than in BSD? If so, does tcpdump only accept BSD
formatted radiotap packets? I'm trying to figure out whether this
functionality needs to be added or whether it is already there and I'm just
not setting things up right.

Thanks again,
Matt

[David Young]

Post by Matthew Belcher

Post by Mike Kershaw
Are you running it with -s0 (or some larger-than-default capture size)?
A full RT header can be bigger than the 32 or 64 or whatever the default
# of bytes is for tcpdump to process.

Thanks for your suggestion. I tried it with -s0 to see if that would help.
(none):~# tcpdump -i wifi0 -L
IEEE802_11 (802.11)
(none):~# tcpdump -vv -i wifi0 -s0 -x
tcpdump: listening on wifi0, link-type IEEE802_11 (802.11), capture size 65535
bytes
11:41:33.240612 unknown IEEE802.11 frame type (3)More Data More Fragments Pwr
Mgmt Retry Strictly Ordered WEP Encrypted 65535us (header) unknown IEEE802.11
frame type (3)unknown 802.11 frame type (3)
0x0000: ffff ffff ffff 0002 6f21 e671 0806 0321 ........o!.q...!
0x0010: 0800 0604 0001 0002 6f21 e671 c0a8 0164 ........o!.q...d
0x0020: 0000 0000 0000 c0a8 0165
As you can see that doesn't seem to have helped. Are the radiotap packets in
Linux formatted differently than in BSD? If so, does tcpdump only accept BSD
formatted radiotap packets? I'm trying to figure out whether this
functionality needs to be added or whether it is already there and I'm just
not setting things up right.

Are you sure this is a radiotap capture? Where it says "link-type
IEEE802_11," it should say "link-type IEEE802_11_RADIO". Perhaps the
driver is really creating a radiotap capture, but it uses the wrong DLT?

Radiotap headers had better not be formatted differently in Linux,
or else Linux is not compliant with the radiotap spec.

Dave

[Matthew Belcher]

Post by David Young
Are you sure this is a radiotap capture? Where it says "link-type
IEEE802_11," it should say "link-type IEEE802_11_RADIO". Perhaps the
driver is really creating a radiotap capture, but it uses the wrong DLT?

Thanks Dave. Is there something you have to set to change the link type from
IEEE802_11 to IEEE802_11_RADIO? I didn't realize there was a difference.

Matt

[David Young]

Post by Matthew Belcher

Post by David Young
Are you sure this is a radiotap capture? Where it says "link-type
IEEE802_11," it should say "link-type IEEE802_11_RADIO". Perhaps the
driver is really creating a radiotap capture, but it uses the wrong DLT?

Thanks Dave. Is there something you have to set to change the link type from
IEEE802_11 to IEEE802_11_RADIO? I didn't realize there was a difference.

I don't know how it works in Linux. In BSD, the taps are set up like
this:

radiotap (driver-specific; this is for Atheros):

bpfattach2(ifp, DLT_IEEE802_11_RADIO,
sizeof(struct ieee80211_frame) + sizeof(sc->sc_tx_th),
&sc->sc_drvbpf);

802.11 tap:

bpfattach2(ifp, DLT_IEEE802_11,
sizeof(struct ieee80211_frame_addr4), &ic->ic_rawbpf);

ethernet tap:

bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header));

Dave

[Matthew Belcher]

Post by David Young
I don't know how it works in Linux. In BSD, the taps are set up like

Thanks again. I solved my problem. I needed to do

echo '803' > /proc/sys/net/ath0/dev_type

on the device to switch it to radiotap header mode and also set up the device
in monitor mode (previously I was in station mode). Now I get the right
output.

Matt