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

[Yang Luo <hsluoyb () gmail com>]

Hi list,

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. On Linux, we use iwconfig to create a
"mon0" for "eth0", then capturing on "mon0" will get the raw 802.11 traffic.

I have finished the work on the driver side. Now the driver will provide
another "\Device\NPF_WIFI_{XXXX}" device besides the original
"\Device\NPF_{XXXX}" one for each wireless adapter. These new interfaces
will be provided smoothly in the libpcap API of Npcap and no problems here.
However, it seems that dumpcap.exe has also called IPHelper API to do
something like retrieving the friendly name of an interface.

The friendly name is the description on the right side when executing
"dumpcap -D".

*C:\Program Files\Wireshark>dumpcap -D*
*1. \Device\NPF_{7C4E0476-D3F1-4F4C-9FE4-FA514710032A} (VMware Network
Adapter VMnet1)*
*2. \Device\NPF_{F0353155-69D0-4611-AB2A-EE864BE0ADD9} (Local Area
Connection* 19)*
*3. \Device\NPF_{385F30D0-9166-45D3-BBC6-F1D9C5300AF9} (Wi-Fi)*
*4. \Device\NPF_{2F6EC492-5488-42D4-BAF4-049CD820EB66} (VMware Network
Adapter VMnet8)*
*5. \Device\NPF_{1CD23D3C-5192-4BD6-AC31-91220CAA7C89} (Ethernet 2)*
*6. \Device\NPF_{44B1169F-6D1D-473B-B3D9-E5FC46BAE748} (Ethernet)*
*7. \Device\NPF_{2A2FCEC4-C241-4B8B-8532-C901A74DC867} (Npcap Loopback
Adapter)*

The dumpcap.exe code is shown as below:

https://github.com/wireshark/wireshark/blob/master/caputils/capture-pcap-util.c#L340-L352

if (strncmp("\\Device\\NPF_", name, 12) == 0)  //<----------------------
there's also a small issue here, if Npcap provides a prefix like
"\Device\NPF_WIFI_".
guid_text = name + 12;
else
guid_text = name;

/* Now try to parse what remains as a GUID. */
if (parse_as_guid(guid_text, &guid)) {
/*
* Success. Try to get a friendly name using the GUID.
* As this is a regular interface, the description is a
* vendor description.
*/
if_info->friendly_name =
get_interface_friendly_name_from_device_guid(&guid);
 //<-------------------------------- Get the friendly name using IPHelper
API.

Since friendly name is shown on Wireshark/dumpcap, its value of the two
interfaces of a wireless adapter must be different, like adding a "(raw
802.11)" at the end of the friendly name of the raw 802.11 interface. Since
Npcap doesn't control this friendly name, dumpcap.exe must be patched to
adapt to this change. Or we change the libpcap API to add a friendly name
member to the pcap_if_t structure (if Guy agreed). And Wireshark can just
use what it gets from Npcap.

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?
2) How to let Wireshark output the correct friendly name of the raw 802.11
interface? Change dumpcap or change libpcap API?
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?

Any opinions? Thanks!


Cheers,
Yang

___________________________________________________________________________
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