Re: Some questions about Wireshark monitor mode support on Windows

[Yang Luo <hsluoyb () gmail com>]

Hi Guy,

On Wed, May 25, 2016 at 2:05 AM, Guy Harris <guy () alum mit edu> wrote:

> On May 20, 2016, at 6:46 PM, Yang Luo <hsluoyb () gmail com> wrote:
>
> > On Sat, May 21, 2016 at 3:28 AM, Guy Harris <guy () alum mit edu> wrote:
> > > On May 18, 2016, at 11:41 AM, Yang Luo <hsluoyb () gmail com> 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 () 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