Wireshark · Wireshark-dev: [Wireshark-dev] The best practice to capture on the raw 802.11 interface on Windows

[Yang Luo <hsluoyb@xxxxxxxxx>]

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