Wireshark · Wireshark-dev: Re: [Wireshark-dev] Does it make any sense to supply Radiotap + 802.11 headers for packets captured

[Yang Luo <hsluoyb@xxxxxxxxx>]

Hi Guy,

On Wed, Apr 27, 2016 at 11:33 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On Apr 24, 2016, at 8:33 PM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:

> On Mon, Apr 25, 2016 at 7:56 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>> 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.)
>
> 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@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe