On Dec 29, 2015, at 11:29 PM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:
> 2) pcap_cant_set_rfmon function in wpcap\libpcap\pcap.c:
> https://github.com/nmap/npcap/blob/master/wpcap/libpcap/pcap.c
> Line 98
>
> /*
> * For systems where rfmon mode is never supported.
> */
> static int
> pcap_cant_set_rfmon(pcap_t *p _U_)
> {
> return (1);
> // return (0);
> }
That's a temporary hack, I hope.
What you *should* do is have a pcap_can_set_rfmon_win32() function in pcap-win32.c, and, at the end of pcap_create_interface() in pcap-win32.c, do
p->can_set_rfmon_op = pcap_can_set_rfmon_win32;
right after setting p->activate_op.
> I changed this function to always returning 1, which means "supported". I know here I should check whether the adapter supports the monitor mode, but I found no way to check. All I can do is to get/set the current mode using the OID way above.
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. (I think that whether getting and setting that OID works, or not, is ultimately up to the driver, and a driver that lets you get the mode but doesn't let you set it to monitor mode would mess things up - you'd be able to request monitor mode, but attempting to do so would fail - in which case the only way to handle that would be to try to set monitor mode. Doing that, however, would, if it succeeds, disconnect you from the wireless network, so we really don't want to do that.)
> After all these changes, there's no change in Wireshark, I didn't find a place to switch on/off the monitor mode like Microsoft Network Monitor. So I doubt whether Wireshark supports the monitor mode of Wlan in Windows?
Currently, dumpcap only uses the pcap_create()/pcap_activate()/pcap_can_set_rfmon() APIs if, when it was compiled, it was built against a version of libpcap/WinPcap that doesn't have pcap_open().
WinPcap has pcap_open(), so that means dumpcap *doesn't* use those APIs, which means that Wireshark on Windows won't use them and won't support monitor mode.
This means that dumpcap needs to be changed to use those APIs on local adapters if they're available, regardless of whether pcap_open() is available, and to use pcap_open() *only* for remote adapters.
*If* we're willing to require that the Windows version of Wireshark use only WinPcap 4.1 and later, or NPcap, that's a straightforward source code change. This would mean people who had some reason to, for example, use WinPcap 3.x - for example, to capture on PPP devices (dial-up, mobile phone USB adapter, VPN, etc.) on Windows 2000 or the 32-bit versions of Windows XP and Windows Server 2003 - would be unable to do so.
Given that 1.10 was the last release to support Windows XP packages, and 1.12 was the last release to support Windows Server 2003 packages:
https://wiki.wireshark.org/Development/LifeCycle
I wouldn't *personally* have a problem with Wireshark 2.2 and later not supporting WinPcap earlier than 4.1.
If we still want to allow people to use 2.2 and later with WinPcap 3.x, dumpcap would have to be able to choose whether to use pcap_create() *et al* at run time. That's probably doable, but I'd really rather not have to do that.
Note also that this all means that, until Wireshark 2.2, the only way to use Windows Native WLAN to capture in monitor mode would be to run a development build. Unless we backport changes to 2.0 - and 1.12 if people want it - you're not going to be able to just drop in NPcap and capture in monitor mode.