Hi Guy, On Wed, May 25, 2016 at 2:05 AM, Guy Harris <[email protected]> wrote:
> On May 20, 2016, at 6:46 PM, Yang Luo <[email protected]> wrote: > > > On Sat, May 21, 2016 at 3:28 AM, Guy Harris <[email protected]> wrote: > >> On May 18, 2016, at 11:41 AM, Yang Luo <[email protected]> wrote: > >> > >>> I just released Npcap 0.07 R4: > >>> https://github.com/nmap/npcap/releases > >>> > >>> This version Npcap already supports monitor mode setting using > Wireshark GUI or command line. > >>> > >>> 1) For GUI, if you check the "Capture packets in monitor mode" option > in "Edit Interface Settings", your adapter will turn into monitor mode > immediately. > >> > >> I see you figured out that you need to use the GTK+ version if you want > to be able to turn monitor mode on. Bug 11364 > >> > >> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11364 > >> > >> causes problems trying to use monitor mode in the Qt interface. > > > > I saw that bug. It seems that the link-layer header type can be multiple > (a list)? Why this? I thought this value is obtained from the > pcap_datalink() function, > > No, it's returned from pcap_list_datalinks(), which can return multiple > values - and does; for example, on my Mac: > > $ tcpdump -i en0 -L > Data link types for en0 when not in monitor mode (use option -y to set): > RAW (Raw IP) > PPI (Per-Packet Information) > EN10MB (Ethernet) > $ tcpdump -i en0 -L -I > Data link types for en0 when in monitor mode (use option -y to set): > RAW (Raw IP) > IEEE802_11_RADIO_AVS (802.11 plus AVS radio information header) > IEEE802_11 (802.11) > IEEE802_11_RADIO (802.11 plus radiotap header) > PPI (Per-Packet Information) > TCPDump is only for Linux, so I use WinDump instead. And all interfaces return: EN10MB (Ethernet). I doubt that WinDump only uses pcap_datalink() function to get a single data link type value. The source code here ( https://github.com/nmap/npcap/blob/master/wpcap/libpcap/pcap-win32.c#L599-L675) shows that only Ethernet interfaces will be given two data link types (DLT_EN10MB + DLT_DOCSIS) in Npcap. But "Link-layer Header" column in "Capture Interfaces" of Wireshark QT GUI still only shows one type (Ethernet) for all Ethernet interfaces. Where is the DLT_DOCSIS type? > > And Npcap should not have this issue. Because a wireless adapter will > always get "802.11 plus radiotap header" using Npcap. There's no need to > choose. > > Wireshark doesn't treat adapters with multiple entries in that list > differently from adapters with one entry in that list. > > >>> And I have several questions: > >>> > >>> 1) In "Edit Interface Settings", if I check "Capture packets in > monitor mode" option, my adapter will turn into monitor mode immediately. > >> > >> As soon as you check the box, it *immediately* switches into monitor > mode, and stays in monitor mode, even though you haven't started a capture? > >> > >> That doesn't happen on OS X - it shouldn't happen until you actually > start the capture. > > Actually, with the *current* way libpcap works, the only way to find out > the list of link-layer header types for an interface is to open the > interface for capturing and call pcap_list_datalinks() - and, if you want > the list of link-layer header types available in monitor mode, you have to > open the interface *in monitor mode*. > Is this really good? The user has to go through a network disconnection even before real capturing. This seems to be unavoidable, since data link types in monitor mode can be different from normal setting. > > So that's what Wireshark (or, rather, dumpcap) does - but it then closes > the pcap_t, which *should* turn monitor mode off if it wasn't already on. > If WinPcap isn't correctly turning monitor mode off, it'll stay on even > after the pcap_t is closed. > OK. I have done this in: https://github.com/nmap/npcap/commit/253ca4ff83f16372a14c15c1e9b58c3e72edfed2 > > Now, that means that, on platforms where switching to monitor mode > disassociates you from the network, clicking the "monitor mode" option will > disassociate you from the network. I'm working on changing libpcap so that > you can call pcap_create() and then call pcap_list_datalinks() on the > pcap_t *without* calling pcap_activate() (just as you can, for example, > call pcap_can_set_rfmon() without calling pcap_activate()); this means that > if the module can determine the list of link-layer header types available > in monitor mode *without* actually putting the adapter in monitor mode, > checking that checkbox won't put the adapter into monitor mode. > > That should be possible in WinPcap; it's not possible in, for example, OS > X 10.5 or later, but, at least for most if not all of the Wi-Fi capable > Macs I've used, you don't get disassociated from the network if you go into > monitor mode. > Is that possible for Npcap/WinPcap? The data link types are retrieved by the Npcap driver I think? Without opening the adapter, the DLLs can't communicate with the driver. Unless we find a way to get the types without asking the driver. > > >> Something in Npcap is setting monitor mode, but it's probably failing > to turn monitor mode back off again. > > > > I added the PacketSetMonitorMode() call in pcap_activate_win32(), right > before calling PacketOpenAdapter(). I think this is the right place? > > > https://github.com/nmap/npcap/commit/e5606a9f5286992104a85b110ce6b1eff82aafa7 > > I'd do it *after* calling PacketOpenAdapter(), so you don't go into > monitor mode on an adapter that can't be opened. > PacketOpenAdapter() calls the driver to create the OPEN instance. In future, Npcap driver is supposed to determine the wifi attaching or non-wifi attaching based on the current operation mode when creating the OPEN instance. So I'd rather switch to monitor mode before the driver starts its work. Another solution is better: we switch back to managed mode if the adapter can't be opened. > > Also, if you've set monitor mode, undo the PacketSetMonitorMode() call in > all of the "open failed" cases after setting monitor mode, so it doesn't > stay in monitor mode if any of the later calls fails. > OK. I have done this in: https://github.com/nmap/npcap/commit/253ca4ff83f16372a14c15c1e9b58c3e72edfed2 > And PacketIsMonitorModeSupported() should have three possible return > values: "supported", "not supported", and "error", so that > pcap_can_set_rfmon() can report errors, rather than 1 or 0, if a call to > determine whether monitor mode is supported failed rather than returning > information. > OK. I have done this in: https://github.com/nmap/npcap/commit/bf5f79b8411271f605b35d99e970e96da2ebc61f > > PacketSetMonitorMode() should do the same, so that pcap_activate() can > distinguish between "that device doesn't support monitor mode", in which > case it should return PCAP_ERROR_RFMON_NOTSUP, and "an error occurred", in > which case it should return the appropriate error. > OK. I have done this in: https://github.com/nmap/npcap/commit/515f5b455b0b6e39f8e4ae1e6c85a45863ede770 > > > I don'y know why if I check "Capture packets in monitor mode" option, my > adapter will turn into monitor mode immediately. At that time, the adapter > is not expected to be opened yet. > > See above - currently, you *have* to open the device to find out the list > of link-layer header types. As per the above, I'm working on fixing > libpcap so that you *don't* have to activate the device to do that (the > libpcap/WinPcap module might open it internally and then close it if > necessary). > Maybe this is a bug of Wireshark GTK UI? Because in QT UI, I didn't encounter this, after I switched from "disabled" to "enabled", the monitor mode is not switched immediately. Cheers, Yang > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
