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

[Yang Luo <hsluoyb () gmail com>]

Hi Guy,

On Wed, Apr 27, 2016 at 11:33 AM, Guy Harris <guy () alum mit edu> wrote:

> On Apr 24, 2016, at 8:33 PM, Yang Luo <hsluoyb () gmail com> wrote:
>
> > 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.
>
> No, because it *used* to work - VMware Fusion provides USB pass-through,
> so the virtual machines on which I was using the Belkin adapter saw a USB
> Wi-Fi stick plugged in, and, until recently, handled it just fine, even
> managing to connect to the local Wi-Fi network and to run in monitor mode.
> The hypervisor neither knows nor care that it's a Wi-Fi adapter, or *any*
> kind of network adapter; it just thinks it's a USB device and virtualizes
> it at that level.

OK. I saw another mail of you. I'm not a MAC user, so unfortunately I can't
help you about that issue.


> > > > 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?
>
> To let the user choose, from the command line (with the -I flag) or the
> GUI (with the monitor mode checkbox), whether to do a monitor-mode capture
> or an active capture of traffic to and from the machine?  Both of them are
> useful at different times.

Adding that function is not hard, I will look into this these days.


> > 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,
>
> You already have *three* "drivers", in a sense:
>
>         an LWF driver;
>
>         a WFP driver;
>
>         a "regular device driver" which is what Packet.dll opens and reads
> from/writes to.
>
> with two separate .inf files:
>
>
> http://stackoverflow.com/questions/31363985/wfp-callout-and-ndis-lwf-cant-sit-inside-the-same-driver-binary?rq=1
>
> What you'd do here would be to have a fourth "driver", which is an LWF
> driver, and, for 802.11 adapters, one would be bound above the adapter
> driver and one would be bound above NWIFI.  That might require that the
> driver be installed three times.

Oh, you even found this post!

I personally think the device is not a driver, so at least, Npcap has two
"drivers", LWF + WFP, sitting inside one binary. But I can't imagine it is
possible to stuck in another LWF into this binary? Like:
LWF1 (above NWIFI) + LWF2 (below NWIFI) + WFP?

What I'm afraid of is providing two binaries. Because that will complicate
the model in many aspects. Like the driver choosing in Packet.dll.
Your idea of providing two LWFs in one binary is very interesting. But I
don't know if this is possible?



> For 802.11 adapters, NPF_TapExForEachOpen() would:
>
>         if it's being called for the version below NWIFI, hand the packet
> to any monitor mode instances;
>
>         if it's being called for the version above NWIFI, hand the packet
> to any non-monitor-mode instances.

Sounds good.


Cheers,
Yang


> You could also choose to do the second of those only if the adapter isn't
> in monitor mode - on OS X, I can run one instance of tcpdump in monitor
> mode and one instance not in monitor mode, and see traffic on both of them,
> but, on OS X, I can remain associated with a Wi-Fi network when I'm in
> monitor mode, and I think all of that is also true of Linux, but it's not
> true for Windows, where going into monitor mode disassociates you from the
> Wi-Fi network.
>
> > 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.
>
> I don't - this means that you can't just use, for example, the Wireshark
> GUI to control whether to capture in monitor mode or not.
> ___________________________________________________________________________
> 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
___________________________________________________________________________
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