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

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.

from pcapy.

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.)

from pcapy.

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.

from pcapy.