Could an error other than ERROR_OPERATION_ABORTED be reported if a device is removed? #2036
I think the NT status STATUS_CANCELLED, returned by the driver if NPF_StartUsingOpenInstance() returns FALSE, gets mapped to ERROR_OPERATION_ABORTED in userland from a ReadFile() or WriteFile() call.
If NPF_StartUsingOpenInstance() returns FALSE because the device has been removed, returning a different error might be useful, so that libpcap can distinguish between "the capture stopped because the device was removed", which it could report with the standard "The interface disappeared" error for that case, and report "PacketReceivePacket error (995)" for other cases, which would be "shouldn't happen" cases (as was the case in older versions, where sleeping and waking up could provoke that error).
There is an NT status value STATUS_DEVICE_REMOVED; I don't know what Windows status that's mapped to.
This came up because of Wireshark bug 16555; the error message in Wireshark suggested reporting it as an error before the fixes in 0.9988, to try to get more information, but if it's due to a known cause, such as the device being removed, we should just tell the user that the device was removed.
The text was updated successfully, but these errors were encountered:
Or, if the only reason why an operation would get ERROR_OPERATION_ABORTED is now, and will continue to be, "the device was removed", I could handle this entirely in libpcap, by interpreting ERROR_OPERATION_ABORTED as "The interface disappeared".
(If not, a distinction should be made between "the device disappeared" and other reasons, using different status values.)
For the Read call, we returned
Now, I just pushed a change that ought to make things much better by distinguishing between operations that require an adapter to be present (packet write operations and some IoControl/OID things) and those that do not (getting stats, reading remaining packets in the buffer, configuring the capture session, etc.). If an operation requires an adapter that is not present, we return
The Read operation (
I don't currently have a way to "reattach" an instance if the adapter is plugged back in. This wouldn't be too hard to do if it gets the same GUID as before it was removed, but I haven't tested that. It will probably have to wait for another time.
So presumably that'll show up as
Any idea what that userland status code
"Network disconnect" in what sense? Unplugging an Ethernet, disconnecting from a Wi-Fi network, etc.?
That's the right thing to do - it's not as if waiting for more packets to arrive is worthwhile, given that the disappearance of the adapter means that they won't arrive.
Presumably packets being written won't get written if the adapter is gone, so they shouldn't get wrapped back as input.
So if that means that capturing on a removable device, and removing the device, will get
That's probably not a high priority - the capture should return an error if the interface goes away, and the app should probably note that to the user, because there's no guarantee that they'll plug it in again.