Hi Guy, On Mon, Apr 25, 2016 at 7:56 AM, Guy Harris <[email protected]> wrote:
> On Apr 19, 2016, at 7:24 PM, Yang Luo <[email protected]> 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 <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected] > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
