On May 20, 2016, at 6:46 PM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:
> On Sat, May 21, 2016 at 3:28 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>> On May 18, 2016, at 11:41 AM, Yang Luo <hsluoyb@xxxxxxxxx> 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)
> 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*.
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.
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.
>> 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.
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.
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.
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.
> 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).
