WinpkFilterDevice, losing packets?

[clw-helb]

We are seeing packets in WireShark that do not make their way into our C# App.

Initializing code:

...
_currentDevice = winpkDevice;
_currentDevice.OnPacketArrival += OnPacketCaptured;
_currentDevice.Open(DeviceModes.Promiscuous | DeviceModes.NoCaptureLocal, -1);
_currentDevice.StartCapture();
...

OnPacketCaptured-callback

private void OnPacketCaptured(object sender, PacketCapture capture)
{
   RawCapture packet = capture.GetPacket();
>>> this is where we log the incoming packets
   ...
}

WireShark log:

...
"3663","13:10:18.948799","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1425","<MIP Sequence: 106><Boot: Unknown>"
"3664","13:10:18.961600","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 219><LC: ACK>"
"3665","13:10:18.961600","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1425","<MIP Sequence: 107><Boot: Unknown>"
"3666","13:10:18.979584","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 220><LC: ACK>"
"3667","13:10:18.979584","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1425","<MIP Sequence: 108><Boot: Unknown>"
"3668","13:10:18.997669","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 221><LC: ACK>"
"3669","13:10:18.997669","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1425","<MIP Sequence: 109><Boot: Unknown>"
"3670","13:10:19.015561","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 222><LC: ACK>"
"3671","13:10:19.015561","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1425","<MIP Sequence: 110><Boot: Unknown>"
"3672","13:10:19.033972","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 223><LC: ACK>"
"3673","13:10:19.033972","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1425","<MIP Sequence: 111><Boot: Unknown>"
"3674","13:10:19.051952","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 224><LC: ACK>"
"3675","13:10:19.062759","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1425","<MIP Sequence: 112><Boot: Unknown>"
"3676","13:10:19.075508","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 225><LC: ACK>"
"3677","13:10:19.081911","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1425","<MIP Sequence: 113><Boot: Unknown>"
"3678","13:10:19.094691","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 226><LC: ACK>"
"3679","13:10:19.094691","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1425","<MIP Sequence: 114><Boot: Unknown>"
"3680","13:10:19.113223","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 227><LC: ACK>"
"3681","13:10:19.113223","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1425","<MIP Sequence: 115><Boot: Unknown>"
"3682","13:10:19.132129","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 228><LC: ACK>"
"3683","13:10:19.132129","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1425","<MIP Sequence: 116><Boot: Unknown>"
"3684","13:10:19.150087","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 229><LC: ACK>"
"3685","13:10:19.157149","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1425","<MIP Sequence: 117><Boot: Unknown>"
"3686","13:10:19.169902","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 230><LC: ACK>"
"3687","13:10:19.176925","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1425","<MIP Sequence: 118><Boot: Unknown>"
"3688","13:10:19.190063","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 231><LC: ACK>"
"3689","13:10:19.190063","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1425","<MIP Sequence: 119><Boot: Unknown>"
"3690","13:10:19.208025","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 232><LC: ACK>"
"3691","13:10:19.215675","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1425","<MIP Sequence: 120><Boot: Unknown>"
"3692","13:10:19.227617","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 233><LC: ACK>"
"3693","13:10:19.227617","LCFCElectron_dd:ed:67","00:19:19_00:01:ff","B5-P-MIP-BOOT","1161","<MIP Sequence: 121><Boot: Unknown>"
"3694","13:10:19.243528","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-LC","60","<MIP Sequence: 234><LC: ACK>"
"3699","13:11:31.196865","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-BOOT","60","<MIP Sequence: 235><Boot: OperationDone>"
"3700","13:11:31.196865","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-BOOT","60","<MIP Sequence: 236><Boot: OperationDone>"

Our log:

...
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 219
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 220
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 221
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 222
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 223
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 224
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 225
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 226
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 227
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 228
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 229
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 230
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 231
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 232
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 233
23.01.2025 13:09:22 OnPacketCaptured length: 60 MIP Sequence: 234

as we can see

"3699","13:11:31.196865","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-BOOT","60","<MIP Sequence: 235><Boot: OperationDone>"
"3700","13:11:31.196865","00:19:19_00:01:ff","LCFCElectron_dd:ed:67","B5-P-MIP-BOOT","60","<MIP Sequence: 236><Boot: OperationDone>"

are not being captured. As we can also see between 232 (13:10:19.243528) and 233 (13:11:31.196865) there seems to no traffic. But should not be an issue for capturing?

Note:

• times differ because WireShark was not run on the same PC as the PC the app was run on
• this does not always happen. But quite often and when it happens we are always seeing equal logs

Additional context;
the above software used to make use of SharpPcap/WinPcap. As of Win11 we noticed SharpPcap/WinPcap to become "unstable". Replacing WinPcap with npcap brought back the stability. But as npcap has very high license costs we now try to make use of SharpPcap/WinPkFilter

I am looking for advices to trackt this down even more. To me (see additional contex) it looks like npcap is "more stable" than WinPcap and/or WinPK/ndisapi ...

Thanks in advance
Clemens

[kayoub5]

please check usual suspects from https://stackoverflow.com/a/64287748/1438522

Also, if you are logging in the callback function, you will basically cause it to slow down (logging in the console is super slow), thus effectively making the driver have no choice but to drop packets.

[clw-helb]

thx Ayoub,
in "production code" we just put the packets into a ConcurrentQueue and read from the queue from another thread.

Vadim, the developer of WinpkFilter, mentioned:
"I haven’t gone deep into SharpPcap, but based on your description of packet loss, I would guess that Listen mode (SentListen | RecvListen) is being used. In this mode, packets are observed passively, which can lead to drops in high-traffic scenarios.

I recommend switching to Tunnel mode (SentTunnel | RecvTunnel) to ensure reliable packet capture. Don’t forget to re-inject the original packet back into the network stack after processing to maintain proper flow."

and

"The main difference between listening and tunnel modes lies in how they handle the original packet. In listening mode, you receive a copy of the packet while the original is forwarded (though if resources are limited, you may lose the copy). In tunnel mode, the original packet is dropped, requiring you to re-inject it. However, this ensures that no traffic bypasses you unnoticed."

[kayoub5]

• You can use AdapterModes enum to configure the mode the mode, see

  sharppcap/Examples/WinpkFilterExample/Program.cs

  Line 39 in 88fd988

  device.AdapterMode = AdapterModes.Tunnel

  as example
• If you are using a ConcurrentQueue, this means you are making a copy of the packet, and that is performance wise not recommended.