Please change Resource data about win10pcap HOT 6 OPEN

Hi gvanem,

Thank you for pointing it out.

However, the "wpcap.dll" file in our Win10Pcap package is not modified by us.
We did not modify not only this resource string but also any bits in the wpcap.dll file.

It is the exact copy (just simple redistribution) from the original WinPcap (including the digital signature). Please see the Authenticode digital signature on wpcap.dll.

To comply with the redistribution requirement of the original wpcap.dll, we write the "Portions copyright of WinPcap (original)" statement clearly on the text in our msi file.

So I think that there are no concern about users would confuse that the author of the "wpcap.dll" file. (In fact, the "wpcap.dll" is not modified at all.)

If there are other reasons that we should change only the resource string of "wpcap.dll", I'm willing to do anything. Please feel free to let me know.

from win10pcap.

Okay, fair points.

I'm more concerned about the various Packet.dll messing up my system. I'm trying to support Win10Pcap in a program that has packet32.c directly compiled in (to avoid a Packet.DLL-hell).

I guess the device-names for CreateFile() needs to be changed? And are your IOCTL-commands compatible with NPF?

So far from reading your Packet_dll sources, I'd need to replace all \\.\NPF_x to \\.\WTCAP_A_x etc. A migration document would be nice.

from win10pcap.

Hi Gisle Vanem,

Thank you for understanding.

Anyway, please tell me if I should recompile the "wpcap.dll" to change the resource string etc. from the original wpcap.dll source code. Probably it is not difficult for me to recompile wpcap.dll and embed the Authenticode certificate of us into wpcap.dll. (Actually I suppose that it is desirable to keep the current policy to use the original wpcap.dll file in Win10Pcap, because wpcap.dll has no changed bits from the original binary. However, if this might be concerned to make a trouble with the original WinPcap project, please tell me so.)

About the Packet.dll duplication problem which you mentioned, I think this should be considered carefully. I feel that DLL hell problem might be certainly serious.

Unfortunately, our communication interface between our Packet.dll and our Win10Pcap.sys is NOT compatible with the original WinPcap.
We wrote most part of Packet.dll and Win10Pcap.sys from scratch. It was necessary because there are many differences of miniport-adapter bindings between NDIS 5 and NDIS 6. I felt that it is too difficult to absorb the differences between NDIS 5 and NDIS 6 on the kernel-mode code. So I decided to make a driver from scratch, and absorb them in the user-mode Packet.dll file.
(The export interface of Packet.dll and bpf-header data format is exactly same to the original WinPcap's Packet.dll since we copied definitions from the WinPcap's header file. Therefore, the original wpcap.dll can work with our Packet.dll without modification.)
It means that simply replacement of the CreateFile path in the original WinPcap.dll, from ".\NPF_x" to ".\WTCAP_A_x", does not work well.

Just now I got another idea as followings.

As the background circumstances, most of all well-known packet capture applications are compiled to use "wpcap.dll" on Windows PCs (as same as using libpcap for Linux PCs). These application are statically linked to "wpcap.dll" (while some of them are dynamically linking by using the LoadLibrary API). That is the reason why Win10Pcap need to use the "wpcap.dll" filename to support such static-linking (or hard coding) applications.

The original wpcap.dll (in the WinPcap installer, and in the Win10Pcap installer) is also statically linking to the "Packet.dll" exported functions. Currently, on the wpcap.dll, there are no methods to switch the user-mode driver-interface DLL (Packet.dll) in run-time by the user's instruction.

So I suppose that: if the original WinPcap's wpcap.dll would have a new function and a new interface to allow users to choose which Packeti.dll should be loaded, it is great, because we will be able to use another filename, e.g. "PacketNdis6.dll" . The control flag whether to load "Packet.dll" (original) or "PacketNdis6.dll" (ours) should be on the registry. (Use HKLM to avoid the modification by non-privileged users).

There are very few applications to call directly "Packet.dll" . Most of application call "wpcap.dll" instead. The above solution feels better to keep the compatibility and to avoid the DLL-hell problem.

Your comments are very welcome.

from win10pcap.

@dnobori The export interface of Packet.dll and bpf-header data format is exactly same to the original WinPcap's ..

Not in all versions of the original Packet.dll. My AirPcap adapter stopped working in WireShark after installing your version today. Since that Packet.dll had AirPcap support hard-coded inside it. Same issue with WanPacket (VPN capture etc.) I guess.

So renaming it to PacketNdis6.dll would be a good idea. Or maybe even a better idea would be to create a plugin-feature (in Win32's libpcap) to switch and select the correct .sys-driver.

from win10pcap.

You would like to try Npcap: https://github.com/nmap/npcap

from win10pcap.

The change in interface namings is pretty confusing. The original winpcap works with the \Device\NPF_{GUID} format and win10pcap requires only the {GUID} part, so it's not compatible out-of-the-box. This change should be somehow documented for the users, IMHO.

from win10pcap.