[Yang Luo <hsluoyb@xxxxxxxxx>]

Hi Guy,

I have encountered one issue when implementing as what you said. This is:

What value should PacketGetNetType() return for a wireless adapter? NdisMedium802_3 or NdisMediumRadio80211?

This value reflects on Wireshark Capture Options's "Link-layer header", and controls how Wireshark dissects the packets. As you said, whether the traffic is fake Ethernet or raw 802.11 is based on whether the monitor mode is enabled. However, at the point of Wireshark Capture Options, the user has not yet chosen whether to capture in monitor mode.

Let's say even if Npcap could let PacketGetNetType() returns the right value based on whether the adapter is currently on monitor mode. When the user opens the Wireshark Capture Options window, it shows NdisMedium802_3 because the it's not in monitor mode. Then the user checks the "Capture packets in monitor mode" and starts capturing. I don't know if Wireshark will check the "Link-layer header" again after monitor mode is turned on? Or just use the NdisMedium802_3 value got from Wireshark Capture Options window. If it is the latter, Wireshark will get the wrong result because the actual traffic it is provided is raw 802.11.

The two interface implementation doesn't have this issue. Because the "standard" interface can have the NdisMedium802_3 link-layer header, and the "wifi" interface can have NdisMediumRadio80211.

Cheers,

Yang

On Fri, Oct 7, 2016 at 2:42 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

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.


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
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