Revision history [back]

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.

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.