Wireshark · Wireshark-dev: Re: [Wireshark-dev] Does it make any sense to supply Radiotap + 802.11 headers for packets captured

[Yang Luo <hsluoyb@xxxxxxxxx>]

Hi Guy,

On Mon, Apr 25, 2016 at 7:56 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On Apr 19, 2016, at 7:24 PM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:

> First there's a little background here: Npcap uses a build-time configuration to choose whether the driver sees fake Ethernet packets or raw 802.11 packets. This build-time configuration controls whether Npcap driver is bound below or above a Microsoft driver called NWIFI (NativeWiFi Filter). NWIFI does the translation between fake Ethernet headers and 802.11 headers. So if Npcap is below NWIFI, it can see 802.11 prior to NWIFI's handling. If Npcap is above NWIFI, it will only see the fake Ethernet provided by NWIFI. This is why there're two versions of Npcap.
>
> 1) When operation mode switches (like managed mode to monitor mode), how fast does the header switch take effect? For example, does the user need to restart the mac80211 driver (and Wireshark) to make this change take effect?

No.

On Linux, with a mac80211 device, capturing in monitor mode is done by capturing on a "monN" interface; capturing on a "wifiM" interface for the same physical device won't capture in monitor mode, and will give "fake Ethernet" headers, while capturing on the "monN" device *will* capture in monitor mode and will give radiotap+802.11 headers - and I think both captures can be in progress at the same time.  (I'd test it, but my Belkin USB adapter isn't working with any of my virtual machines; I don't know if the hardware is having a problem, or if VMware Fusion is having a problem.)

I know nearly all hypervisors don't provide 802.11 interface. They only provide Ethernet adapters. This is because virtual Ethernet adapters are implemented in NDIS 6 and LWF, the same technique used by Npcap. And 802.11 virtual support will need more handling, nearly impossible. So I have to test -wifi version Npcap on the host.

I don't know if USB adapters need special handling too. 

 

On OS X, capturing in monitor mode is done by requesting some form of 802.11 header, with or without a radio header; if another process captures on the same device but without 802.11 headers, it won't capture in monitor mode, and both captures can be in progress at the same time.

Unfortunately, that won't be possible on Windows.  On OS X, you can be in monitor mode *and* be associated with a network, with the adapter capable of sending packets, at least with some devices, and I think that's true of Linux as well.  On Windows, however, if an adapter is monitor mode, it can't transmit packets, so you're off the network.

Yes.

 

> Or without driver restart, and don't need to close Wireshark, new packets can automatically switch to radiotap + 802.11 headers in Wireshark capture window. I'm asking this because currently Npcap needs to install a -wifi version to make the switch. It should be possible to make the switch between a driver restart, but I want to know how Linux does it.

It does it by not having to have two flavors of driver; having two different flavors of driver, one bound atop an "adaptation layer" (NWIFI) and one bound below it, is a Windows-specific requirement.

> 2) Does Linux allow to inject (send) packets in monitor mode?

Yes, although it requires driver support.

> I'm asking this because Jeffery from Microsoft said in this post (http://www.osronline.com/showThread.CFM?link=265127) that they won't officially support packet injection for LWF driver below NWIFI (like -wifi version Npcap).
>
>> I'm not too surprised that the packets don't work if your driver gets stuck below NWIFI. We don't support drivers doing that, because you need to decorate your packets in a special way & synchronize with the WLAN state machine, etc.

Well, if you're in *monitor* mode, that shouldn't matter - your host injecting packets is no different from some other random host injecting packets.

However:

        https://msdn.microsoft.com/EN-US/library/ff568369.aspx

"While in NetMon mode, the miniport driver can only receive packets based on the current packet filter settings. The driver cannot send packets either on its own or through a call to its MiniportSendNetBufferLists function."

so, apparently, *Windows* doesn't allow *anything* to be sent when the device is in monitor mode.

Yes. Microsoft said they will take any measures to stop sending raw 802.11 packets. We may have lucky to find a way to do this, but they will stop it in the next second.

 

And what he means by "

> 3) According to the background, if I need to provide the header switch between a driver start, first I need to choose the -wifi version Npcap. (I can't use the normal version Npcap, because it can't see 802.11 packets in any case). And this leads to an issue: I need to handle the 802.11 data header-> Ethernet header translation for capturing and Ethernet header -> 802.11 data header translation for injection by myself under ExtSTA mode. I want to know is it possible to do this translation?
>
> I know it's easier to do the translation from 802.11 to Ethernet. I found 802.11 data header is 24 bytes and it contains Destination Address as dst_mac in Ethernet and Source Address as src_mac in Ethernet. And the following LLC header is 8 bytes and it contains Type as type in Ethernet.
> But reversely it's not easy any more. I don't know how to fill in the blanks in 802.11 data and LLC only based on the knowledge of Ethernet header information. And I feel like I'm reimplementing the NWIFI driver, which I don't know if it's possible. I don't know how NWIFI gets the needed parameters to fill in the blanks when doing the translation from fake Ethernet to 802.11.

Producing the fake Ethernet headers from 802.11 headers discards information, so you can't reliably reconstruct the 802.11 headers from the fake Ethernet headers.

> Any ideas?

Can you have the same driver module have two separate bits of driver code, one of which is bound below the NWIFI adaptation layer and one of which is bound above it?

Currently, I have made the 802.11 support switch an installation option. So no need to install the -wifi version Npcap any more.

Please download the latest Npcap 0.07 at:

https://github.com/nmap/npcap/releases

As you said above, the monitor mode + 802.11 capturing can't coexist with managed mode + Ethernet capturing on Windows. So I wonder if there's a need to actually provide two drivers at the same time? Even the two drivers are installed, only one of them is at work at one particular time.

The drawback is: the user needs to reinstall the driver (the commands can be made into a .bat file) when switching the operation mode.

The good point is: we don't need to maintain two drivers, and don't need to design the driver choosing mechanism in Packet.dll code.

And currently, I think the good point is larger than the drawback.

If Windows permits raw 802.11 sending and connecting to AP while in monitor mode, then I think providing two drivers at the same time is useful.

If the device is a Wi-Fi device, then, in the activate routine in Npcap:

        if opt.rfmon is set, you open the code bound below NWIFI, and enter monitor mode;

        if opt.rfmon is not set, you open the code bound *above* NWIFI.

If opt.rfmon is not set, and one or more instances of the code below NWIFI are running (meaning that the device is in monitor mode), the activate routine should return PCAP_ERROR and set the error string to a message indicating that you can't capture in non-monitor mode as there's a monitor-mode capture in progress.

If opt.rfmon *is* set, and one or more instances of the code *above* NWIFI are running (meaning that the device is not in monitor mode), the activate routine should return PCAP_ERROR and set the error string to a message indicating that you can't capture in monitor mode as there's a non-monitor-mode capture in progress.

I don't know whether the two bits of code could be implemented in the same .sys file; if not, they might have to somehow arrange to be able to communicate with each other in order to find out whether the code driver has any open instances.

This would mean you could only get 802.11 headers in monitor mode, and would get fake Ethernet headers when not in monitor mode, but that's the case for most (if not all) adapters on Linux and OS X, and possibly newer *BSDs as well.

If you have only one bit of code, you're going to have it below NWIFI, meaning that you won't be able to support injection when not in monitor mode.  It might also get decrypted frames with the Protected bit set, meaning that the user might have to turn "ignore the protection bit" on.

I will provide the setting and getting operation mode function in the driver. And make it configurable through wpcap.dll for now.

Cheers,

Yang

 

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe