Wireshark-dev: Re: [Wireshark-dev] The best practice to capture on the raw 802.11 interface on
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).
