When using on macOS, pcapy thinks wireless interfaces (in monitor mode) are ethernet interfaces

[melyux]

I installed pcapy using the source and compiled it. When I set an interface into monitor mode using tcpdump, like sudo tcpdump -I -i en0 --linktype=IEEE802_11 -e -s 256 type mgt subtype probe-response, packets show up just fine in that window for tcpdump, but pcapy can't seem to tell. Capturing on pcapy on that interface causes no packets to show up. Trying to set a filter on the capture object returns pcapy.PcapError: 802.11 link-layer types supported only on 802.11. In fact, I haven't been able to get pcapy to capture anything. Calling .datalink() on the interface capture object returns 1 (ethernet) for the wireless interface.

Am I missing some dependency? Compiling pcapy went smoothly without complaints, so I can't imagine what the problem is.

[melyux]

Seems it's to do with pcapy not having the feature to turn on monitor mode like the original libpcap can (PcapPy seems to be the only libpcap wrapper that can actually manage this on OS X; and pypcap also works but is not thread-safe, so useless). Which is strange because pcapy should be able to use the en0 interface when it's already been put into monitor mode through some other means, but it continues to throw the pcapy.PcapError: 802.11 link-layer types supported only on 802.11 error as if en0 is not in monitor mode at all. Weird.

Could the pcap_set_rfmon() function be implemented in pcapy? I guess that would entail also implementing the pcap object since that function only works with that, and not with the so-far implemented open_live mode. PcapPy seems to have gone around this somewhat by adding the rfmon and activate arguments to its open_live implementation to mimic the open_live function while providing the full functionality of the pcap object creation method in the backend.

[guyharris]

If pcapy were to implement pcap_set_rfmon(), it'd also have to implement pcap_create() and pcap_activate(), as, to open in monitor mode, you have to call pcap_create() to create the pcap_t, pcap_set_rfmon() to request monitor mode (and other calls to request a particular snapshot length, etc.), and pcap_activate() to activate the pcap_t, opening the device.

(See also issue #23, which would also require pcap_create() and pcap_activate(). More and more new capabilities in libpcap will require them over time, so I'd suggest using those APIs in pcapy if they're available. A quick look at PcapPy seems to suggest that the additional arguments to open_live are keyword/value pairs, so it might be able to handle at least some future extensions.)

[guyharris]

Which is strange because pcapy should be able to use the en0 interface when it's already been put into monitor mode through some other means

Just because an interface is in monitor mode, that doesn't mean that all BPF devices bound to the interface are in monitor mode - I just ran tcpdump in two terminal windows, one with -I and one without -I, and the one with -I showed the usual 802.11 frames while the one without it just showed "fake Ethernet" frames.