Monitor-mode frames in "any"-device captures on Linux aren't dissected correctly

asked 2018-11-12 16:16:12 +0000

dega
3 ●2 ●2 ●5

updated 2018-11-13 01:57:30 +0000

Guy Harris
19890 ●3 ●659 ●207

I need to capture simultaneously on 2 interfaces (802.11 in monitor mode and Ethernet). Wireshark displays packets with a SLL prefix but cannot decode the Wifi packets and the associated RadioTap header. For those packets, the SLL contains 803 (802.11+RadioTap) in ARPHRD and 4 (Ethernet-II) in ProtocolType. It seems Wireshark is using the ProtocolType as the hint and completely ignore the ARPHRD.

I think there's no protocolType assigned in if_ether.h for RadioTap and decoding as ethernet cannot work. I even disabled all protocol dissectors (except SLL, Radiotap and 802.11) and Wireshark still cannot decode.

Since there's no protocolType assigned for Radiotap I think the SLL dissector should use ARPHRD value as the principal hint because it is explicit: the first portion must be decoded as RadioTap and the second as 802.11.

Tested in WireShark 2.2.17 and 2.6.3.

Did I missed something obvious?

Comments

I need to capture simultaneously on 2 interfaces (802.11 in monitor mode and Ethernet).

That can be done by enabling two interfaces when capturing.

On Linux (and macOS if the capturing program is running with root privileges, which it won't be by default), it can also be done by capturing on the "any" device.

Which of those are you doing?

Guy Harris ( 2018-11-12 22:14:58 +0000 )edit

Thanks for your comment Guy. I'm in wireshark group and I don't have problem capturing simultaneous on 2 interfaces. My problem is that wireshark cannot dissect 802.11 packets because the SLL specify that the protocol is LLC -802.2 (ETH_type = 4). Linux version is 4.14.78

dega ( 2018-11-12 22:34:58 +0000 )edit

In answer to the question I asked, you're doing a capture on the "any" device.

Guy Harris ( 2018-11-13 01:58:06 +0000 )edit

add a comment

answered 2018-11-13 01:56:40 +0000

Guy Harris
19890 ●3 ●659 ●207

updated 2018-11-13 02:00:13 +0000

OK, so I plugged my Netgear Wi-Fi adapter into my Mac, and told VMware Fusion to attach it to my VM running Ubuntu 16.04, and put it into monitor mode with sudo airmon-ng start wlxa42b8cf23d44, and did a tcpdump capture on the "any" device, and I did get packets that are probably Wi-Fi beacons in the capture.

I think the SLL dissector should use ARPHRD value as the principal hint

Unfortunately, if it did that, it would incorrectly dissect some other packets in the capture; there are packets with a "link-layer address type" of 1, being the ARP hardware type for Ethernet, and with the payload after the SLL header being an IPv4 datagram without an Ethernet header; the "protocol" field is 0x0800, for IPv4, so using the ARPHRD value would fail with those packets. That would break dissection of a LOT of captures, including any capture done on a machine with an Ethernet adapter on which packets arrive.

This will require me to Yet Again dive into the part of the Linux networking stack involving PF_PACKET sockets and figure out what has to be done (and to update the description of the SLL link-layer type to reflect that little surprise).

edit flag offensive delete link

Comments

OK, so I didn't bother with the deep dive, but I'll bet that, for 802.11+radiotap packets, the pointers in the skb structure are set so that the payload pointer and the link-layer header pointer are the same, so the "strip off the link-layer header" code in af_packet.c doesn't strip anything off.

I've added an additional dissector table for the hatype so that the radiotap dissector can get called for packets with an hatype of 803, regardless of the protocol type, but all other packets will still be dissected as they always have been. I checked that into the master branch, as well as the 2.6 and 2.4 branches, so the next 2.6 and 2.4 releases should handle this.

(Hopefully the Linux network stack people won't think "that's a bug, not a feature" and break it again.)

Guy Harris ( 2018-11-13 04:07:01 +0000 )edit

Hi Guy!

You wrote: "Unfortunately, if it did that, it would incorrectly dissect some other packets in the capture".

Don't fear. There is one SLL per packet and Linux kernel provide appropriate data for each packet. In my test (using one ethernet interface and one wifi in Monitor mode), I receive:
for ethernet: sll.hatype=1, sll.ltype=800
for wifi: sll.hatype=803, sll.ltype=4

With these values and your fix, WS should correctly decode every packet.

As I mentioned in my initial post, I think the problem comes from the fact that there is no value assigned to 802.11 in if_ether.h. If it's the real reason, the problem is not caused by Linux; the whole *x community is concerned. I would be curious to learn how the same situation is handled by other *x OS. Can you comment, please?

About the fix in ...(more)

dega ( 2018-11-13 14:06:51 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Monitor-mode frames in "any"-device captures on Linux aren't dissected correctly

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Monitor-mode frames in "any"-device captures on Linux aren't dissected correctly edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Monitor-mode frames in "any"-device captures on Linux aren't dissected correctly