Npcap 1.70 PacketOpenAdapter returns empty string for ADAPTER.Name

[DarkDarro]

Call Npcap API PacketOpenAdapter with a specific device string.
In our case the device is a virtual ethernet adapter if it is relevant.
The returned ADAPTER object's "Name" member is an empty string "".

In Npcap 1.60 the device string parameter of PacketOpenAdapter was the same as the member after a successful call and we reused the member later on as a parameter to API pcap_open_live.

In Npcap 1.70 this now fails with the empty string.

[dmiller-nmap]

Thanks for bringing this up. The Packet32.h (Packet.dll) API is not intended as a public API, but rather as the interface between Npcap and libpcap. The Npcap Developer's Guide says, "The Npcap API is exported by wpcap.dll and is the Windows port of libpcap." This is not a new policy, as even WinPcap's documentation states:

[...] packet.dll should be considered an internal API, because its purpose inside WinPcap is to be a building block for the real public API: wpcap.dll.

As a consequence, since the normal and suggested way for an application to use WinPcap is through wpcap.dll, we don't guarantee that the packet.dll API will not be changed in future releases of winpcap, and we don't provide support for this API.

User software should avoid using the Packet API, since because Packet.dll is always shipped with a compatible and tested wpcap.dll (libpcap), it is subject to incompatible changes between versions. Future versions may make data structures like ADAPTER and PACKET opaque.

In this particular case, libpcap was not using the ADAPTER.Name member, so we removed the step of populating it. If you have a Npcap OEM license with support option, you can use the support email address to request a change to this feature.

[dmiller-nmap]

For reference, here is the commit that changed this: e2f60e4#diff-fbde706694dbead2c023e9f5ba579b5d724a4a35c8831f03df023c9f0ee183c8L1385-L1391

[fyodor]

Just as an update, @dmiller-nmap and I were chatting about this and it looks like we'll probably be able to add back the Name for the Npcap 1.71 release, which we're hoping to put out next week. Still, as Dan mentioned so persuasively above, it's best to avoid calling the Packet API if possible. We and the libpcap team work had to maintain the wpcap (libpcap) API, but Packet is meant to be an internal API with no compatibility guarantees. I'll re-open this so we can close it after we put Name back.

[DarkDarro]

Thanks for the information.
I can delegate to the customer, that future releases should use the expected API functions.
The code had been like this even with the last winpcap release and then continued with Npcap 0.9995.
Older versions of the product had already been released (bundled with the latest Npcap OEM version at their respective release) which would have failed to run when people decided to manually update Npcap to 1.70 or had it already installed prior to the product installation.

[fyodor]

Thanks for the extra details @DarkDarro. If you are bundling Npcap OEM 1.60 with your product, that means you must have an Npcap OEM redistribution license and thus are probably entitled to priority support. If you don't have your support contact details, feel free to write to sales@nmap.com and they will hook you up. What sometimes works best is to file an issue here and then provide the issue number to support so they know to mark it high priority and start work on it ASAP.