ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] How Wireshark supports monitor mode for WLAN 802.11 adapter

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 1 Jan 2016 11:59:55 -0800
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.