Please change Resource data

[gvanem]

Please change the resource-strings / data inside your wpcap.dll. I just installed your Win10Pcap-v10.1-5001.msi alongside my original WinPcap and now I've got what I think are Win10Pcap's version under:

 c:\Windows\System32\wpcap.dll
 c:\Windows\Sysnative\wpcap.dll   (shadow of the above?)
 c:\Windows\SysWOW64\wpcap.dll

All with the same resource-data:

CompanyName     Riverbed Technology, Inc.
FileDescription wpcap.dll Dynamic Link Library - based on libpcap 1.0rel0b branch (20091008)

I think even though wpcap.dll is binary-compatible with the original wpcap.dll, it's very confusing that neither Win10Pcap nor SoftEtherVPN is mentioned in the resource-data.

Although I see you have updated the resource data in Packet.dll:

CompanyName     Daiyuu Nobori, University of Tsukuba, Japan
LegalCopyright  Copyright (C) 2015 Daiyuu Nobori, University of Tsukuba, Japan.

IMHO both .DLLs should indicate they are part of the same Win10Pcap project.

Anyway, a good job. Good to see WinPcap is alive again.

[dnobori]

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.

[gvanem]

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.

[dnobori]

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.

[gvanem]

@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.

[hsluoyz]

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

[I-gor-C]

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.