Wireshark · Wireshark-dev: Re: [Wireshark-dev] Some questions about Wireshark monitor mode support on Windows

[Yang Luo <hsluoyb@xxxxxxxxx>]

Hi Guy,

On Wed, May 25, 2016 at 2:05 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On May 20, 2016, at 6:46 PM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:

> On Sat, May 21, 2016 at 3:28 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>> On May 18, 2016, at 11:41 AM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:
>>
>>> I just released Npcap 0.07 R4:
>>> https://github.com/nmap/npcap/releases
>>>
>>> This version Npcap already supports monitor mode setting using Wireshark GUI or command line.
>>>
>>> 1) For GUI, if you check the "Capture packets in monitor mode" option in "Edit Interface Settings", your adapter will turn into monitor mode immediately.
>>
>> I see you figured out that you need to use the GTK+ version if you want to be able to turn monitor mode on.  Bug 11364
>>
>>         https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11364
>>
>> causes problems trying to use monitor mode in the Qt interface.
>
> I saw that bug. It seems that the link-layer header type can be multiple (a list)? Why this? I thought this value is obtained from the pcap_datalink() function,

No, it's returned from pcap_list_datalinks(), which can return multiple values - and does; for example, on my Mac:

$ tcpdump -i en0 -L
Data link types for en0 when not in monitor mode (use option -y to set):
  RAW (Raw IP)
  PPI (Per-Packet Information)
  EN10MB (Ethernet)
$ tcpdump -i en0 -L -I
Data link types for en0 when in monitor mode (use option -y to set):
  RAW (Raw IP)
  IEEE802_11_RADIO_AVS (802.11 plus AVS radio information header)
  IEEE802_11 (802.11)
  IEEE802_11_RADIO (802.11 plus radiotap header)
  PPI (Per-Packet Information)

TCPDump is only for Linux, so I use WinDump instead. And all interfaces return:

EN10MB (Ethernet).

I doubt that WinDump only uses pcap_datalink() function to get a single data link type value.

The source code here (https://github.com/nmap/npcap/blob/master/wpcap/libpcap/pcap-win32.c#L599-L675) shows that only Ethernet interfaces will be given two data link types (DLT_EN10MB + DLT_DOCSIS) in Npcap. But "Link-layer Header" column in "Capture Interfaces" of Wireshark QT GUI still only shows one type (Ethernet) for all Ethernet interfaces. Where is the DLT_DOCSIS type?

> And Npcap should not have this issue. Because a wireless adapter will always get "802.11 plus radiotap header" using Npcap. There's no need to choose.

Wireshark doesn't treat adapters with multiple entries in that list differently from adapters with one entry in that list.

>>> And I have several questions:
>>>
>>> 1) In "Edit Interface Settings", if I check "Capture packets in monitor mode" option, my adapter will turn into monitor mode immediately.
>>
>> As soon as you check the box, it *immediately* switches into monitor mode, and stays in monitor mode, even though you haven't started a capture?
>>
>> That doesn't happen on OS X - it shouldn't happen until you actually start the capture.

Actually, with the *current* way libpcap works, the only way to find out the list of link-layer header types for an interface is to open the interface for capturing and call pcap_list_datalinks() - and, if you want the list of link-layer header types available in monitor mode, you have to open the interface *in monitor mode*.

Is this really good? The user has to go through a network disconnection even before real capturing. This seems to be unavoidable, since data link types in monitor mode can be different from normal setting.

 

So that's what Wireshark (or, rather, dumpcap) does - but it then closes the pcap_t, which *should* turn monitor mode off if it wasn't already on.  If WinPcap isn't correctly turning monitor mode off, it'll stay on even after the pcap_t is closed.

OK. I have done this in: https://github.com/nmap/npcap/commit/253ca4ff83f16372a14c15c1e9b58c3e72edfed2

 

Now, that means that, on platforms where switching to monitor mode disassociates you from the network, clicking the "monitor mode" option will disassociate you from the network.  I'm working on changing libpcap so that you can call pcap_create() and then call pcap_list_datalinks() on the pcap_t *without* calling pcap_activate() (just as you can, for example, call pcap_can_set_rfmon() without calling pcap_activate()); this means that if the module can determine the list of link-layer header types available in monitor mode *without* actually putting the adapter in monitor mode, checking that checkbox won't put the adapter into monitor mode.

That should be possible in WinPcap; it's not possible in, for example, OS X 10.5 or later, but, at least for most if not all of the Wi-Fi capable Macs I've used, you don't get disassociated from the network if you go into monitor mode.

Is that possible for Npcap/WinPcap? The data link types are retrieved by the Npcap driver I think? Without opening the adapter, the DLLs can't communicate with the driver. Unless we find a way to get the types without asking the driver. 

>>  Something in Npcap is setting monitor mode, but it's probably failing to turn monitor mode back off again.
>
> I added the PacketSetMonitorMode() call in pcap_activate_win32(), right before calling PacketOpenAdapter(). I think this is the right place?
> https://github.com/nmap/npcap/commit/e5606a9f5286992104a85b110ce6b1eff82aafa7

I'd do it *after* calling PacketOpenAdapter(), so you don't go into monitor mode on an adapter that can't be opened.

PacketOpenAdapter() calls the driver to create the OPEN instance. In future, Npcap driver is supposed to determine the wifi attaching or non-wifi attaching based on the current operation mode when creating the OPEN instance. So I'd rather switch to monitor mode before the driver starts its work.

Another solution is better: we switch back to managed mode if the adapter can't be opened.

 

Also, if you've set monitor mode, undo the PacketSetMonitorMode() call in all of the "open failed" cases after setting monitor mode, so it doesn't stay in monitor mode if any of the later calls fails.

 

OK. I have done this in: https://github.com/nmap/npcap/commit/253ca4ff83f16372a14c15c1e9b58c3e72edfed2

And PacketIsMonitorModeSupported() should have three possible return values: "supported", "not supported", and "error", so that pcap_can_set_rfmon() can report errors, rather than 1 or 0, if a call to determine whether monitor mode is supported failed rather than returning information.

OK. I have done this in: https://github.com/nmap/npcap/commit/bf5f79b8411271f605b35d99e970e96da2ebc61f

 

PacketSetMonitorMode() should do the same, so that pcap_activate() can distinguish between "that device doesn't support monitor mode", in which case it should return PCAP_ERROR_RFMON_NOTSUP, and "an error occurred", in which case it should return the appropriate error.

OK. I have done this in: https://github.com/nmap/npcap/commit/515f5b455b0b6e39f8e4ae1e6c85a45863ede770

 

> I don'y know why if I check "Capture packets in monitor mode" option, my adapter will turn into monitor mode immediately. At that time, the adapter is not expected to be opened yet.

See above - currently, you *have* to open the device to find out the list of link-layer header types.  As per the above, I'm working on fixing libpcap so that you *don't* have to activate the device to do that (the libpcap/WinPcap module might open it internally and then close it if necessary).

Maybe this is a bug of Wireshark GTK UI? Because in QT UI, I didn't encounter this, after I switched from "disabled" to "enabled", the monitor mode is not switched immediately.

Cheers,

Yang

 

___________________________________________________________________________
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