Closed johnthacker closed 1 month ago
What happens if some other process removes that device out from under the program doing the capturing?
It stops capture, in the same way as if some other process removes the new monitor device out of from under the program (as can unfortunately happen with Network Manager and some other programs) or as if some other process removes the originally specified device out from under the program doing the capture if libpcap were not compiled with libnl support (whether a monitor device or not).
And it will still try to create a monitor device if you try to capture in monitor mode on a regular Wi-Fi interface, which is what we're stuck with if we want monitor mode to be sustained as long as somebody's capturing in monitor mode on the physical device and turned off once there isn't anybody doing so.
(macOS, at least, does reference-counting on BPF devices capturing with 802.11 headers - or did, at least, when I was still there, although I didn't have access to the AirPort driver code (need to know and all that). Wireshark issue 20051 may mean that they're not doing it right any more, however.)
Given that it won't add a new monitor device if you're capturing on a monitor device, it also won't remove the monitor device in question when it's finished capturing, so it won't remove a manually-created device.
I think all mac80211 monitor-mode interfaces on Linux support 802.11+radiotap as the link-layer type, so we might be able to make pcap_list_datalinks()
, at least on Linux, work on handles that haven't been activated, which might let programs find out the available link-layer types without having to activate the handle.
If we're trying to enter rfmon mode, and an interface is a mac80211 device, and nl80211 reports that it's already NL80211_IFTYPE_MONITOR, don't bother to create another monitor device from it. Just use that device as-is and report success, without setting mondevice.