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 <[email protected]> wrote: > On Oct 7, 2016, at 8:20 AM, Yang Luo <[email protected]> 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 <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject= > unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
