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 <[email protected]> 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 <[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=unsubscr >> ibe >> > >
___________________________________________________________________________ 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
