[Yang Luo <hsluoyb@xxxxxxxxx>]

And although I didn't find the evidence in the code, I hope that Wireshark won't call pcap_can_set_rfmon() for adapters which are not even wireless adapters. Because if we open the adapter in pcap_can_set_rfmon(), this function will be slower than before and impacts the performance for a large amount of calling I think.

Cheers,

Yang

On Sat, Oct 8, 2016 at 1:37 PM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:

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@xxxxxxxxxxxx> wrote:

On Oct 7, 2016, at 8:20 AM, Yang Luo <hsluoyb@xxxxxxxxx> 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@xxxxxxxxxxxxx>
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