Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Users seeing STATUS_CANCELLED from PacketReceivePacket() #1903

Closed
guyharris opened this issue Jan 31, 2020 · 6 comments
Closed

Users seeing STATUS_CANCELLED from PacketReceivePacket() #1903

guyharris opened this issue Jan 31, 2020 · 6 comments

Comments

@guyharris
Copy link

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
Copy link

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
Copy link

orvly commented Feb 20, 2020

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 pushed a commit to nmap/npcap that referenced this issue Feb 24, 2020
@bonsaiviking
Allow a capture handle to withstand a Pause event.

Verified

This commit was signed with the committer’s verified signature.
jmiszczak83
GPG key ID: 010C3BE8618FBA8D
Verified
Learn about vigilant mode
9c8f78e 
See nmap/nmap#1903. This should allow capture to continue across things
like a system sleep or installation of a new filter driver.
@dmiller-nmap
Copy link

This should be resolved in Npcap 0.9988, released today.

@samuel-jimenez
Copy link

This is still occurring with Npcap 0.9990.

@sysopch
Copy link

sysopch commented Jun 23, 2020

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@guyharris @dmiller-nmap @orvly @sysopch @samuel-jimenez