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
