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

[Yang Luo <hsluoyb@xxxxxxxxx>]

Hi Guy,

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, and this functions only return one type at a time. It can't return a list.

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.

 

> 2) For CLI, run "dumpcap" command with -I option, your adapter will turn into monitor mode right before capturing.

"-I" should also work with tshark (and tcpdump if built for Windows).

I tried with TShark.exe, it works too.

 

> 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.  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 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.

> 2) After I check "Capture packets in monitor mode" option, the "Mon. Mode" column in "Capture Options" won't change from "disabled" to "enabled". This behavior is weird.

I.e., you check "Capture packets in monitor mode" and click "OK", and the "Capture Options" dialog doesn't show "enabled" for the adapter whose entry you double-clocked to get the "Edit Interface Settings" dialog?

That doesn't happen on OS X.

OK. Maybe we need to see when this column will be changed to "enabled".

 

> 3) libpcap API (wpcap.dll) doesn't export a pcap_get_rfmon function, which means Wireshark can't get the current operation mode in any way.

There's not supposed to be a need for that mode - libpcap/WinPcap and the underlying capture mechanism are supposed to turn it on if any open pcap_t has it on, and turn it off if no pcap_t has it off.  Yes, this requires that some location shared between processes, whether it's in the kernel or in userland, needs to keep a count of open pcap_t's for which monitor mode has been requested. 

> 4) Wireshark does nothing after capturing with "Capture packets in monitor mode" option checked. I think Wireshark should be responsible to change the mode back to managed when the capture ends, if it changed the mode to monitor when capture starts. 

Again, that's supposed to be done by libpcap/WinPcap.

OK. I remembered that. So it's Npcap's responsibility.

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