Cannot even open the capture session

[carpe7]

Hi,

We are conducting some tests of Win10Pcap to see if it perfoms better than the original WinPcap in our scenario.
We P/Invoke wpcap.dll from .NET Framework.
We've built a C# application that successfully uses WinPcap (the original) to send packets (pcap_sendpacket function) in Windows Server 2012 R2. Then we've switched to Win10Pcap, and we don't even succeed in invoking pcap_open. It always returns NULL.
On the contrary, pcap_findalldevs works, but we also find a big change in behaviour here: where the original WinPcap reports \Device\NPF_{} as device name now Win10Pcap reports only {}. It is relevant, because the device name reported by the driver is expected to work intact as source in the call to pcap_open. Neither combination (prefixed or not by \Device\NPF_) works for us with Win10Pcap.
But, interestingly, Wireshark (after ignoring its complaint about NPF not being found) works with Win10Pcap (we've tested interface listing and also capturing; can't test sending packets with Wireshark).
That's why we are wondering what might be the cause of the problem with our (otherwise, very simple) usage of the driver and its API. Problem that Wireshark seems not to be facing.

Any help would be appreciated.

Regards,

J.M.

[carpe7]

Hi,

We have traced the problem deeper.
It seems that pcap_open doesn't work, but pcap_open_live works.
pcap_open may be vital for us, because it is the only function that allows us to include the PCAP_OPENFLAG_NOCAPTURE_LOCAL flag. We use that flag to prevent receiving the same packets that we've sent, which would be harmful in our case for performance reasons.
On the contrary, It seems that Wireshark uses pcap_open_live, and that's why Wireshark works.
But many programs that use other opening functions may be at stake.
pcap_open_live still doesn't work with WinPcap's original device names. You have to drop the \Device\NPF_ prefix in order for it to work. Even if it is consistent with the rule "what pcap_findalldevs tells you as device name can be used to open the interface", take into account that not all programs list the available interfaces and ask you to choose one (e.g., our program queries Windows for the interface id associated with a given IP address, using a .NET API instead of pcap_findalldevs, and adds the \Device\NPF_ prefix to derive the actual device name). So, modifying the device name format is a compatibility breaking change.
Last, but not least, the perfomance (sending with pcap_sendpacket) achieved with Win10Pcap is several orders of magnitude worse than with the original WinPcap. And it also worsens with the number of sending threads past 2.
We suspect that it is related to this message in the console (not regenerated by us) that appears on sending every frame (even if the frame leaves the interface and reaches its destination):
FATAL Bad Memory Block.
Synchronizing with the console to write this message on every frame is simply unbearable.

We would like to know your impressions about these findings.

Thank you very much.

J.M.

[hsluoyz]

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

[hsluoyz]

@chengr28
Npcap has already added all functions that Win10Pcap has, including its own capturing IEEE802.1Q VLAN tags feature. So you can say Npcap is 100% compatible with WinPcap 4.1.3 or Win10Pcap.