-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] 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@xxxxxxxxx> wrote:
> On Thursday, December 31, 2015, Guy Harris <guy@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe