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.
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
Feature discussion: Keep capture handles open when adapter is removed and reattach them when it is restored #506
Comments
Alternatively, if user software (i.e. libpcap) can tolerate the error during any read/write operations, we could leave it up to the user software to close the handle if it's been too long. That's probably best and easiest. |
This is implemented in Npcap 1.60, from the driver side: the interruption (removal, rebinding, etc.) will cause the same errors, but if the interface comes back before the user program closes the handle, it will be reattached and can pick up capturing where it left off. Libpcap (wpcap.dll) does not have a separate error return value for this condition, however, so the best that user code can do for now is to sleep a moment and try again with @guyharris - any ideas for making this easier to use? |
The way Linux handles removed devices is... suboptimal. To quote the comment in pcap-linux.c:
This sounds a bit similar. What we could do is:
I'd have to think about whether that would work in nonblocking mode. |
As discussed in #250, Npcap currently invalidates any open capture handles when NDIS detaches it from the network adapter. This can happen when the adapter is removed or when certain stack maintenance activity takes place.
We would like to consider the possibility of keeping a capture handle open in order to resume capture as soon as NDIS attaches us to the adapter again. This would probably require a user-configurable timeout.
The text was updated successfully, but these errors were encountered: