Hi Graham, On Wed, Apr 27, 2016 at 1:40 AM, Graham Bloice <[email protected]> wrote:
> > > On 25 April 2016 at 04:33, Yang Luo <[email protected]> wrote: > >> 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. >> > > I agree with Guy here, because of the restrictions in the Windows stack to > provide a similar behaviour to that on other OS's, i.e. not having to > reinstall to switch modes, implies installing the two driver instances and > switching which one is enabled according to the capture mode. > OK. It seems that no one wants to reinstall to switch to raw 802.11 capturing. I will think about it. Cheers, Yang > > >> >>> 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 >> >> > > > -- > Graham Bloice > > ___________________________________________________________________________ > 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
