Wireshark mailing list archives
Re: How Wireshark supports monitor mode for WLAN 802.11 adapter in Windows?
From: Anders Broman <anders.broman () ericsson com>
Date: Mon, 4 Jan 2016 12:08:49 +0000
-----Original Message----- From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Guy Harris Sent: den 1 januari 2016 21:00 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] How Wireshark supports monitor mode for WLAN 802.11 adapter in Windows? On Jan 1, 2016, at 8:27 AM, Yang Luo <hsluoyb () gmail com> wrote:
On Thursday, December 31, 2015, Guy Harris <guy () alum mit edu> wrote: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.Yeah, this way is more conformant with the code style.
*And* means the libpcap code in NPcap isn't changed in a way that breaks libpcap; the ultimate goal should be to have NPcap source code not include libpcap source code, and have its build process separately check out libpcap from its repository; I think that's what WinPcap now does.
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.Why not just use those APIs? I think they can totally substitute the pcap_open function?
They can't, yet, as they don't support remote interfaces. I'm working on new APIs to allow specification of authentication information etc., so that pcap_create() and pcap_activate() can work on remote devices, but doing it in a general fashion involves a bit more work (the intent is to support more than just rpcap - we could, for example, support ssh+tcpdump://hostname/device, with the aid of an ssh client library).
*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.Wireshark has shipped the winpcap 4.1.3 version, i don't know but if there are any places that 4.1.3 is inferior than an old version?
I think that 3.x might support capturing on PPP devices (dial-up, VPN, mobile phone adapters, etc.) on Windows 2000/XP; I'd have to go through my mail to see why that's not supported in 4.x. As a test I tried to compile Wireshark with HAVE_PCAP_CREATE set using nmake Linking dumpcap.exe link @C:\Users\etxrab\AppData\Local\Temp\nmFF17.tmp dumpcap.obj : error LNK2019: unresolved external symbol pcap_create referenced in function open_capture_device dumpcap.obj : error LNK2019: unresolved external symbol pcap_set_snaplen referenced in function open_capture_device dumpcap.obj : error LNK2019: unresolved external symbol pcap_set_promisc referenced in function open_capture_device dumpcap.obj : error LNK2019: unresolved external symbol pcap_can_set_rfmon referenced in function get_if_capabilities dumpcap.obj : error LNK2019: unresolved external symbol pcap_set_rfmon referenced in function open_capture_device dumpcap.obj : error LNK2019: unresolved external symbol pcap_set_timeout referenced in function open_capture_device dumpcap.obj : error LNK2019: unresolved external symbol pcap_set_buffer_size referenced in function open_capture_device dumpcap.obj : error LNK2019: unresolved external symbol pcap_activate referenced in function open_capture_device dumpcap.obj : error LNK2019: unresolved external symbol pcap_statustostr referenced in function open_capture_device dumpcap.exe : fatal error LNK1120: 9 unresolved externals Not sure why linking fails :-( Regards Anders ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Re: How Wireshark supports monitor mode for WLAN 802.11 adapter in Windows? Yang Luo (Jan 01)
- Re: How Wireshark supports monitor mode for WLAN 802.11 adapter in Windows? Guy Harris (Jan 01)
- Re: How Wireshark supports monitor mode for WLAN 802.11 adapter in Windows? Anders Broman (Jan 04)
- Re: How Wireshark supports monitor mode for WLAN 802.11 adapter in Windows? Guy Harris (Jan 04)
- Re: How Wireshark supports monitor mode for WLAN 802.11 adapter in Windows? Guy Harris (Jan 06)
- Re: How Wireshark supports monitor mode for WLAN 802.11 adapter in Windows? Yang Luo (Jan 11)
- Re: How Wireshark supports monitor mode for WLAN 802.11 adapter in Windows? Guy Harris (Jan 11)
- Re: How Wireshark supports monitor mode for WLAN 802.11 adapter in Windows? Anders Broman (Jan 04)
- Re: How Wireshark supports monitor mode for WLAN 802.11 adapter in Windows? Guy Harris (Jan 01)
- <Possible follow-ups>
- Re: How Wireshark supports monitor mode for WLAN 802.11 adapter in Windows? Yang Luo (Jan 01)
- Re: How Wireshark supports monitor mode for WLAN 802.11 adapter in Windows? Guy Harris (Jan 01)