Re: The best practice to capture on the raw 802.11 interface on Windows

[Yang Luo <hsluoyb () gmail com>]

Hi Guy,

Thanks for the clarification! I still have one question.

*I can't find a way to check which 802.11 operation modes an adapter
supports without querying OID in Npcap driver.* I have posted a question
here:
http://stackoverflow.com/questions/39928736/how-to-get-the-supported-802-11-operation-modes-for-a-wlan-adapter-in-user-mode.
But I don't think I can get a satisfactory answer. You also said in a
previous post (http://seclists.org/wireshark/2015/Dec/120) that:

*That might be the only way - you might have to open the device, try to get
the OID in question, and, if that succeeds, assume you can set the mode,
otherwise assume you can't.*

So this 802.11 operation modes checking has to be done when the pcap_t is
opened, so that it can calls the Npcap driver to query the OID. And I see
that in Wireshark (
https://github.com/wireshark/wireshark/blob/c3b25e8111dc304486537d7cc60e54ba27c04fa0/caputils/capture-pcap-util.c#L1025-L1054),
the call order is:

pcap_create() -> *pcap_can_set_rfmon()* -> pcap_activate() (*pcap_t is
opened here*)

We can see that the pcap_t has not been opened yet when calling
*pcap_can_set_rfmon()*. I think pcap_can_set_rfmon() doesn't need to work
based on an opened pcap_t on Linux. So won't change this call order in the
user software level.

We have to open the adapter in libpcap/wpcap level. in libpcap, the current
implementation is as below:

/*
* Check if rfmon mode is supported on the pcap_t for Windows systems.
*/
static int
pcap_can_set_rfmon_win32(pcap_t *p)
{
return (PacketIsMonitorModeSupported(p->opt.device) == 1);
}

So I think I need to open the adapter (and then close it) in this
pcap_can_set_rfmon_win32() function. Is this appropriate?


Cheers,
Yang


On Sat, Oct 8, 2016 at 1:05 AM, Guy Harris <guy () alum mit edu> wrote:

> On Oct 7, 2016, at 8:20 AM, Yang Luo <hsluoyb () gmail com> wrote:
>
> > What value should PacketGetNetType() return for a wireless adapter?
> NdisMedium802_3 or NdisMediumRadio80211?
> > This value reflects on Wireshark Capture Options's "Link-layer header",
> and controls how Wireshark dissects the packets. As you said, whether the
> traffic is fake Ethernet or raw 802.11 is based on whether the monitor mode
> is enabled. However, at the point of Wireshark Capture Options, the user
> has not yet chosen whether to capture in monitor mode.
>
> Yes, they *have* chosen it.
>
> For Wi-Fi adapters, there's a checkbox in the Capture Options dialog, in
> the "Monitor" column.  If that checkbox is checked, the user has said that,
> if they've selected that interface as one on which to captures, when they
> start the capture, it should capture in monitor mode.  If it's not checked,
> they've said that it should not capture in monitor mode.
>
> This does, in fact, work correctly on macOS
>
> > Let's say even if Npcap could let PacketGetNetType() returns the right
> value based on whether the adapter is currently on monitor mode. When the
> user opens the Wireshark Capture Options window, it shows NdisMedium802_3
> because the it's not in monitor mode.
>
> It only shows "Ethernet" (meaning DLT_EN10MB) if the "Monitor" checkbox
> isn't checked.  If the user checks that checkbox, it changes to "802.11
> plus radiotap header".  (I just tested it on my Mac, and that's exactly
> what happens.
>
> > Then the user checks the "Capture packets in monitor mode" and starts
> capturing. I don't know if Wireshark will check the "Link-layer header"
> again after monitor mode is turned on?
>
> Yes, it will - in fact, it'll check it when the user checks the "Monitor"
> checkbox *before they start the capture*.
>
> > Or just use the NdisMedium802_3 value got from Wireshark Capture Options
> window. If it is the latter, Wireshark will get the wrong result because
> the actual traffic it is provided is raw 802.11.
> > The two interface implementation doesn't have this issue.
>
> Remember, not all operating systems *have* a two-interface implementation
> - macOS, except for Mac OS X Tiger, doesn't, and neither do most *BSDs
> (and, if mac80211 isn't being used, neither does Linux).
> ____________________________________________________________
> _______________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.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://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe