Wireshark mailing list archives

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


From: Guy Harris <guy () alum mit edu>
Date: Fri, 7 Oct 2016 10:05:32 -0700

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


Current thread: