Re: The best practice to capture on the raw 802.11 interface on Windows

[Guy Harris <guy () alum mit edu>]

On Oct 6, 2016, at 10:19 AM, Yang Luo <hsluoyb () gmail com> 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.


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe