It’s considered the first line of defense when the network server performance begins to deteriorate. Network monitoring has become a crucial and fundamental requirement for small, medium, and large enterprises. Issues such as packet loss, latency, network downtime, frequent errors, and jitters can hamper the overall user experience. 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.With an increase in demand for accessible services and applications, a good network has become more important than ever before.
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. That's probably doable, but I'd really rather not have to do that. 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. I wouldn't *personally* have a problem with Wireshark 2.2 and later not supporting WinPcap earlier than 4.1.
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: 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.
#CAN WINDOWS WIRESHARK USE MONITOR MODE CODE#
*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 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. 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. So I doubt whether Wireshark supports the monitor mode of Wlan in Windows?Ĭurrently, 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(). > 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. Doing that, however, would, if it succeeds, disconnect you from the wireless network, so we really don't want to do that.)
#CAN WINDOWS WIRESHARK USE MONITOR MODE DRIVER#
(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. 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. All I can do is to get/set the current mode using the OID way above. I know here I should check whether the adapter supports the monitor mode, but I found no way to check. > I changed this function to always returning 1, which means "supported".
P->can_set_rfmon_op = pcap_can_set_rfmon_win32 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 > * For systems where rfmon mode is never supported. > 2) pcap_cant_set_rfmon function in wpcap\libpcap\pcap.c: