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 <g...@alum.mit.edu> wrote:
> On Oct 6, 2016, at 10:19 AM, Yang Luo <hslu...@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-requ...@wireshark.org?subject=
> unsubscribe
>
___________________________________________________________________________
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-requ...@wireshark.org?subject=unsubscribe
