Fixing potential race-condition in WinpkFilterDevice.cs

[meta-space]

Summary

I would like to offer a bugfix for a race condition in the WinpkFilterDevice

Motivation

In the Capture loop an incoming Packet might go undetected if is arrives once all packets from the buffer have been processed:

protected override void CaptureLoop(CancellationToken token)
{
	using (ManualResetEvent manualResetEvent = new ManualResetEvent(false))
	{
		WaitHandle[] waitHandles = new WaitHandle[] { token.WaitHandle, manualResetEvent };
		bool success = NativeMethods.SetPacketEvent(DriverHandle, AdapterHandle, manualResetEvent.SafeWaitHandle);
		if (!success)
		{
			throw new PcapException("Can not perform capture");
		}
		while (!token.IsCancellationRequested)
		{
			if (WaitHandle.WaitAny(waitHandles) == 0)
			{
				// We got a cancellation request
				return;
			}
			while (GetNextPacket(out PacketCapture capture) == GetPacketStatus.PacketRead)
			{
				RaiseOnPacketArrival(capture); // forward all queued packets to application
			}
			// race condition HERE: arriving packets won't trigger waitHandles, because manualResetEvent.Reset() immediately resets
			manualResetEvent.Reset();
		}
	}
}

Changes

Simply move the manualResetEvent.Reset(); in from of the while loop.

Testing

Tricky, I did add artifial Sleeps to increase to window of the race condition.
Depending how the HW Filter and Adapter are configured and how "noisy" your network is, the Capture will get unblocked on its own. Ideally you need a completely isolated network segment.

Notes

I'm aware that probably 99.99% of people won't be affected by this defect because most protocols today have retries and recovery mechanisms. We where implementing a proprietary legacy serial protocol over ethernet, which was strictly request/response and were experiencing strange hangs and aborts we did not receive a response.

We since patched and built sharppcap DLL for our application. But then I thought a PR might be welcome upstream

[kayoub5]

Thanks, merged