[prev in list] [next in list] [prev in thread] [next in thread]
List: wireshark-dev
Subject: Re: [Wireshark-dev] Some questions about Wireshark monitor mode support on Windows
From: Yang Luo <hsluoyb () gmail ! com>
Date: 2016-05-25 9:39:16
Message-ID: CAM_tFoZeEA5kbOW_UPR=K3+y+VdEwB4ru30+dK4GWcBr6C+zgg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
>
[Attachment #5 (text/html)]
<div dir="ltr">Hi Guy,<div class="gmail_extra"><br><div class="gmail_quote">On Wed, \
May 25, 2016 at 2:05 AM, Guy Harris <span dir="ltr"><<a \
href="mailto:guy@alum.mit.edu" target="_blank">guy@alum.mit.edu</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span \
class="">On May 20, 2016, at 6:46 PM, Yang Luo <<a \
href="mailto:hsluoyb@gmail.com">hsluoyb@gmail.com</a>> wrote:<br> <br>
> On Sat, May 21, 2016 at 3:28 AM, Guy Harris <<a \
href="mailto:guy@alum.mit.edu">guy@alum.mit.edu</a>> wrote:<br> >> On May \
18, 2016, at 11:41 AM, Yang Luo <<a \
href="mailto:hsluoyb@gmail.com">hsluoyb@gmail.com</a>> wrote:<br> >><br>
>>> I just released Npcap 0.07 R4:<br>
>>> <a href="https://github.com/nmap/npcap/releases" rel="noreferrer" \
target="_blank">https://github.com/nmap/npcap/releases</a><br> >>><br>
>>> This version Npcap already supports monitor mode setting using Wireshark \
GUI or command line.<br> >>><br>
>>> 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.<br> >><br>
>> 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<br> >><br>
>> <a \
href="https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11364" rel="noreferrer" \
target="_blank">https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11364</a><br> \
>><br> >> causes problems trying to use monitor mode in the Qt \
interface.<br> ><br>
> 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,<br> <br>
</span>No, it's returned from pcap_list_datalinks(), which can return multiple \
values - and does; for example, on my Mac:<br> <br>
$ tcpdump -i en0 -L<br>
Data link types for en0 when not in monitor mode (use option -y to set):<br>
RAW (Raw IP)<br>
PPI (Per-Packet Information)<br>
EN10MB (Ethernet)<br>
$ tcpdump -i en0 -L -I<br>
Data link types for en0 when in monitor mode (use option -y to set):<br>
RAW (Raw IP)<br>
IEEE802_11_RADIO_AVS (802.11 plus AVS radio information header)<br>
IEEE802_11 (802.11)<br>
IEEE802_11_RADIO (802.11 plus radiotap header)<br>
PPI (Per-Packet Information)<br></blockquote><div><br></div><div>TCPDump is only \
for Linux, so I use WinDump instead. And all interfaces return:</div><div>EN10MB \
(Ethernet).<br></div><div>I doubt that WinDump only uses pcap_datalink() function to \
get a single data link type value.</div><div><br></div><div>The source code here (<a \
href="https://github.com/nmap/npcap/blob/master/wpcap/libpcap/pcap-win32.c#L599-L675"> \
https://github.com/nmap/npcap/blob/master/wpcap/libpcap/pcap-win32.c#L599-L675</a>) \
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?</div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> 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.<br> <br>
</span>Wireshark doesn't treat adapters with multiple entries in that list \
differently from adapters with one entry in that list.<br> <span class=""><br>
>>> And I have several questions:<br>
>>><br>
>>> 1) In "Edit Interface Settings", if I check "Capture \
packets in monitor mode" option, my adapter will turn into monitor mode \
immediately.<br> >><br>
>> 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?<br> \
>><br> >> That doesn't happen on OS X - it shouldn't happen until \
you actually start the capture.<br> <br>
</span>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*.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>OK. I have done this in: \
<a href="https://github.com/nmap/npcap/commit/253ca4ff83f16372a14c15c1e9b58c3e72edfed2 \
">https://github.com/nmap/npcap/commit/253ca4ff83f16372a14c15c1e9b58c3e72edfed2</a><br></div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
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.<br> <br>
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.<br></blockquote><div><br></div><div>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. </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class=""><br>
>> Something in Npcap is setting monitor mode, but it's probably failing \
to turn monitor mode back off again.<br> ><br>
> I added the PacketSetMonitorMode() call in pcap_activate_win32(), right before \
calling PacketOpenAdapter(). I think this is the right place?<br> > <a \
href="https://github.com/nmap/npcap/commit/e5606a9f5286992104a85b110ce6b1eff82aafa7" \
rel="noreferrer" target="_blank">https://github.com/nmap/npcap/commit/e5606a9f5286992104a85b110ce6b1eff82aafa7</a><br>
<br>
</span>I'd do it *after* calling PacketOpenAdapter(), so you don't go into \
monitor mode on an adapter that can't be \
opened.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>Another solution is better: we switch back to \
managed mode if the adapter can't be opened.</div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
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.<br></blockquote><div> \
</div><div>OK. I have done this in: <a \
href="https://github.com/nmap/npcap/commit/253ca4ff83f16372a14c15c1e9b58c3e72edfed2">h \
ttps://github.com/nmap/npcap/commit/253ca4ff83f16372a14c15c1e9b58c3e72edfed2</a></div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>OK. I have done this in: <a \
href="https://github.com/nmap/npcap/commit/bf5f79b8411271f605b35d99e970e96da2ebc61f">h \
ttps://github.com/nmap/npcap/commit/bf5f79b8411271f605b35d99e970e96da2ebc61f</a><br></div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>OK. \
I have done this in: <a \
href="https://github.com/nmap/npcap/commit/515f5b455b0b6e39f8e4ae1e6c85a45863ede770">h \
ttps://github.com/nmap/npcap/commit/515f5b455b0b6e39f8e4ae1e6c85a45863ede770</a></div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> 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.<br> <br>
</span>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).<br></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><div>Cheers,</div><div>Yang</div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5">___________________________________________________________________________<br>
Sent via: Wireshark-dev mailing list <<a \
href="mailto:wireshark-dev@wireshark.org">wireshark-dev@wireshark.org</a>><br>
Archives: <a href="https://www.wireshark.org/lists/wireshark-dev" \
rel="noreferrer" target="_blank">https://www.wireshark.org/lists/wireshark-dev</a><br>
Unsubscribe: <a href="https://wireshark.org/mailman/options/wireshark-dev" \
rel="noreferrer" target="_blank">https://wireshark.org/mailman/options/wireshark-dev</a><br>
mailto:<a \
href="mailto:wireshark-dev-request@wireshark.org">wireshark-dev-request@wireshark.org</a>?subject=unsubscribe<br>
</div></div></blockquote></div><br></div></div>
___________________________________________________________________________
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic