Npcap: pcap_findalldevs is very slow

[dmiller-nmap]

Users are complaining about Wireshark taking a long time to populate the list of adapters, even going so far as to suggest turning off Npcap when using Wireshark for reading pcap files. This shouldn't take so long.

The most promising idea so far is: Don't try to open each adapter as it is found (PacketOpenAdapter) in order to determine if it is supported. Packet API docs (unpublished) indicate that PacketGetAdapterNames is supposed to only return supported adapters, but I don't know if anything relies on that. Need to check libpcap to see, since that's the primary consumer of that API.

[guyharris]

There was a time when libpcap itself tried to open interfaces when enumerating them; this was done because, on Solaris, not all devices provided by the SIOCGLIFCONF ioctl supported being opened as DLPI devices, so, while the loopback device was listed as a network interface with addresses, you couldn't capture on it.

I changed libpcap to make the "is this a usable device?" check platform-specific. It still has to do some of the open process platforms where not all devices supplied by the enumerate-interfaces mechanism support the platform's capture mechanism, but:

• that doesn't do quite as much work;
• we don't treat "you don't have permission" as meaning "you can't capture on this" (so the user won't be asking "why are there no interfaces?" if they don't have permission, they'll see the interfaces and get told "you don't have permission" so they can ask about that).

Currently, pcap-npf.c doesn't do any checks to see whether the devices returned by PacketGetAdapterNames() are devices on which it can capture, so libpcap, in WinPcap/Npcap, does, in fact, rely on PacketGetAdapterNames() returning only supported adapters. If the NPF driver only puts supported adapters into the Registry, there's presumably no need to try to open the device to see if it's supported.

[fyodor]

Until we make pcap_findalldevs faster, please note that one problem can be extraneous Npcap Loopback Adapters created by earlier (pre-0.996) Npcap installs/upgrades. Issue #55 describes how you can check if you have these and remove them manually, and we're looking at doing this automatically in the future.

[dmiller-nmap]

Npcap 0.9983 includes a minor simplification: Even though PacketOpenAdapter is still called for each adapter while listing, PacketOpenAdapter itself no longer tries to check whether the npcap driver service is running. This almost never worked anyway because most users cannot open a handle to the Service Control Manager.

I did not notice a big improvement in performance, but thought it was worth noting.

[dmiller-nmap]

Related improvements merged in #20

[desowin]

Related improvements merged in nmap/npcap#20

As far as Wireshark is concerned probably the next biggest performance improvement is to be done in the Wireshark/dumpcap itself. See https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16191 for more information.