Re: Does it make any sense to supply Radiotap + 802.11 headers for packets captured on wireless adapter for managed mode?

[Graham Bloice <graham.bloice () trihedral com>]

On 25 April 2016 at 04:33, Yang Luo <hsluoyb () gmail com> wrote:

> Hi Guy,
>
> On Mon, Apr 25, 2016 at 7:56 AM, Guy Harris <guy () alum mit edu> wrote:
>
> > On Apr 19, 2016, at 7:24 PM, Yang Luo <hsluoyb () gmail com> 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.


> > 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 <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe