npcap icon indicating copy to clipboard operation
npcap copied to clipboard

Better detect and report DLL and driver version inconsistencies

Open fyodor opened this issue 3 years ago • 4 comments

Npcap installs its DLL's in a systemwide Windows folder and we strongly recommend that applications use those common DLL's rather than shipping Npcap DLLs in their application directory. This is because the Npcap device driver is shared systemwide anyway, and should be paired with the DLL's corresponding to that driver version. We don't do any testing of mismatched DLL's+drivers because they are meant to be installed and used as a set.

That being said, shipping library DLL's in Windows application directories is very common and often makes sense where the library can be used independently. So some applications probably make that mistake with Npcap. We probably don't want Npcap to abort on mismatch, but we do want to make it easy for mismatches to be detected and reported.

pcap_lib_version will normally show something like "Npcap version 1.71, based on libpcap 1.10.1", but in the case of mismatch will show "Npcap version 1.71 (packet.dll version 0.99), based on libpcap 1.10.1".

PacketGetVersion() has always returned a version string like "1.71" or "0.99-r3", but we could make it check for differing driver version and extend it like "1.71 (npcap.sys 0.9985)".

I'm not sure of the right answer, but wanted to add this issue so we at least remember the problem and can think of possible improvements. We would hate to spend a great deal of issue debugging a problem just to find out it was caused by a version mismatch.

fyodor avatar Aug 15 '22 18:08 fyodor

Related issue where Snort broke with Npcap 0.9982 because they were shipping old DLLs: nmap/nmap#1677

dmiller-nmap avatar Aug 15 '22 19:08 dmiller-nmap

One thing that could be done would be to have pcap_init() (introduced in 1.10) do whatever sanity checks are necessary to make sure things will work correctly and, if they won't, return -1 and fill in the error message buffer.

Unfortunately, that only helps with applications that call pcap_init() and check its return value, i.e. it probably won't help with most applications (currently, neither tcpdump nor Wireshark do so, for example). Applications that are shipped as binaries that have to work on multiple OS versions, or with multiple versions of both flavors of libpcap-for-Windows would only call pcap_init() if they did a dlopen()/LoadLibrary() of the library and then a dlsym()/GetProcAddress() on pcap_init and call it through a pointer if it's found.

So, while it might be a good idea to have pcap_init() do checks of that sort (and not just on Windows, if necessary), it's not all that would be needed for a fix.

guyharris avatar Aug 15 '22 19:08 guyharris