Wireshark-dev: Re: [Wireshark-dev] Does it make any sense to supply Radiotap + 802.11 headers f
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.)
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.
> 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.
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?
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.
