On Oct 6, 2016, at 10:19 AM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:
> I'm working on the new raw 802.11 capture feature with Npcap on Windows these days. This new raw 802.11 feature doesn't need to install different versions of Npcap to turn on/off the raw 802.11 mode. In Wireshark, Npcap will provide two interfaces which can be chosen for each wireless adapter, one normal interface and another raw 802.11 interface. So when capturing on the normal interface of a wireless adapter, you will get fake Ethernet traffic. When capturing on the raw 802.11 interface, you can get raw 802.11 traffic like mgmt, control and data. This idea is the same as how Linux's raw 802.11 capture is implemented.
The way Linux's raw 802.11 capture is implemented is a misfeature, not a feature.
So is the way macOS's raw 802.11 capture is implemented.
Libpcap tries to work around those misfeatures, by:
on Linux, by, if you've requested monitor mode with pcap_set_rfmon(), trying to figure out whether the mac80211 mechanism (with a "monN" device created, corresponding to a "wifiN" device) can be used and, if so, creating the "monN" device and capturing on it rather than on the "wifiN" device and, if not, using whatever the driver-specific mechanism is for turning monitor mode on;
on macOS, by, if you've requested monitor mode with pcap_set_rfmon(), offering only the DLT_ values that cause monitor mode to be turned on (and, if you haven't, offering only the DLT_ values that *don't* cause monitor mode to be turned on), and, if you haven't requested a DLT_ value, defaulting to a mode that does or doesn't turn monitor mode on, whether or not you've requested it.
The goal here is to *hide* the OS-specific details of how you do monitor mode, allowing a command-line program to support a command-line flag such as -I (which tcpdump and the Wireshark programs use) and allowing a GUI program to support a checkbox to request monitor mode.
Unfortunately, there are some issues that mean it doesn't usually work on Linux, but I have plans to fix those.
> On Linux, we use iwconfig to create a "mon0" for "eth0", then capturing on "mon0" will get the raw 802.11 traffic.
On Linux, we do that only because libpcap usually doesn't do it for you; that's a deficiency in libpcap and needs to be fixed.
Having two devices on Windows would be *another* misfeature, and I'd have to make libpcap work around *it*, so that -I and the checkbox work on Windows the same way they work on macOS (and on at least some *BSDs, although I think FreeBSD may have broken that) and the way they will work on Linux once I deal with the libnl issues.
So please do *NOT* implement this the way Linux does, with two separate devices - that's the *WRONG* way to do it! (And don't implement it the way macOS does, either - the BIOCSDLT-based hack is another wrong way.)
Just implement it in such a way that:
if the user hasn't called pcap_set_rfmon(p, 1) before calling pcap_activate(p), capture with monitor mode off, with fake Ethernet headers;
if the user *has* called pcap_set_rfmon(p, 1) before calling pcap_activate(p), capture with monitor mode on, with 802.11+radiotap headers;
and show only *one* device for a Wi-Fi adapter, which you use both with and without monitor mode.
> Since friendly name is shown on Wireshark/dumpcap, its value of the two interfaces of a wireless adapter must be different,
If you don't show the user two interfaces for a Wi-Fi adapter, this is not a problem.
> So to summarize, there are several questions:
>
> 1) Is using "\Devicce\NPF_WIFI_{XXXX}" as the GUID name a good way to represent the raw 802.11 interface?
No. Not *having* a raw 802.11 interface is a good way to do things.
> 2) How to let Wireshark output the correct friendly name of the raw 802.11 interface? Change dumpcap or change libpcap API?
Don't have a separate interface, and you don't need to give it a separate friendly name.
> 3) How the friendly name of the raw 802.11 interface should be like? Is adding a "(raw 802.11)" at the end of the original friendly name a good way?
Don't have a separate interface, and you don't need to give it a separate friendly name.