Users seeing STATUS_CANCELLED from PacketReceivePacket()

[guyharris]

That error has been reported in Wireshark bug 16329 and bug 16355.

It looks as if the most likely reason for that would be that NPF_Pause() is called before pcap_dispatch()/pcap_loop() without NPF_Restart() also having been called after NPF_Pause() but before the libpcap routine.

According to Pausing a Driver Stack; might that be occurring due to adding (or removing?) a binding? The second bug involves disconnecting from the Wi-Fi network, which might tweak bindings if, for example, a disconnected adapter doesn't have the Internet protocol stack bound to it but a connected adapter does.

Is this covered by the comment

/* TODO: Allow the read to continue if the filter module is
 * detached (NPF_StartUsingOpenInstance above returned false)
 * but we have packet data in the buffer that can still be
 * delivered. */

in NPF_Read()?

And should there be OpenPausing and OpenPaused states, so that the instance isn't marked as "closing" or "closed" if it's just being paused or finished being paused?

[dmiller-nmap]

That sounds reasonable. I'll take a closer look at making these changes after the next release (this week, I hope), since I want this to be a solid bugfix release without new features.

[orvly]

I came here from Wireshark's bug 16329, referenced above.

I figured adding more details here instead of there would be better, sorry if this isn't the correct place. I'll move my report there if this isn't appropriate.

It's basically the same error reported there:

Error while capturing packets: PacketReceivePacket error: The I/O operation has been aborted because of either a thread exit or an application request. (995)

But, in my case I'm getting this very consistently when sending Windows 10 into hibernation, while Wireshark is running a capture, on a WIFI interface. This messages appears when I restart from the hibernation and switch back to Wireshark.

This is with Wireshark 3.2.1.0 , with Npcap version 0.9986. Hardware is a Dell Latitude laptop, with Intel Dual Band wireless AC 7265, driver version 18.33.17.1. Running on Windows 10 (build 18363.657),

[dmiller-nmap]

This should be resolved in Npcap 0.9988, released today.

[samuel-jimenez]

This is still occurring with Npcap 0.9990.

[sysopch]

coming from wireshark bug 16329, I assume it is the same bug (did not catch all details). I saw it today with Wireshark 3.2.4 and Npcap 0.9991

I was capturing from wifi generated by a test device, doing a netcat transfer test.

3.2.4 (v3.2.4-0-g893b5a5e1e3e)

Compiled (64-bit) with Qt 5.12.8, with WinPcap SDK (WpdPack) 4.1.2, with GLib
2.52.3, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.15.0, with Lua 5.2.4,
with GnuTLS 3.6.3 and PKCS #11 support, with Gcrypt 1.8.3, with MIT Kerberos,
with MaxMind DB resolver, with nghttp2 1.39.2, with brotli, with LZ4, with
Zstandard, with Snappy, with libxml2 2.9.9, with QtMultimedia, with automatic
updates using WinSparkle 0.5.7, with AirPcap, with SpeexDSP (using bundled
resampler), with SBC, with SpanDSP, with bcg729.

Running on 64-bit Windows 10 (1903), build 18362, with Intel(R) Core(TM)
i7-8565U CPU @ 1.80GHz (with SSE4.2), with 16235 MB of physical memory, with
locale Italian_Italy.1252, with light display mode, without HiDPI, with Npcap
version 0.9991, based on libpcap version 1.9.1, with GnuTLS 3.6.3, with Gcrypt
1.8.3, with brotli 1.0.2, without AirPcap, binary plugins supported (19 loaded).

Built using Microsoft Visual Studio 2019 (VC++ 14.25, build 28614).

[guyharris]

As of the most recent commit, the driver's read routine returns STATUS_CANCELLED only if NPF_StartUsingOpenInstance() returns FALSE, so, unless there's another way to get STATUS_CANCELLED from NtReadFile() or to get error 995 (ERROR_OPERATION_ABORTED) from packet.dll, that's probably what's happening.