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

Detect network disconnection and stop scanning. #1394

dmiller-nmap opened this Issue Nov 21, 2018 · 1 comment


None yet
1 participant

dmiller-nmap commented Nov 21, 2018

When the network is disconnected (for instance, by unplugging the Ethernet cord or disconnecting from WiFi), Nmap continues to scan, but none of the probes will succeed. In fact, Nmap will detect its timing probes as being dropped and will continuously slow down, prolonging the scan indefinitely. We would rather have Nmap stop immediately.


  • Different platforms will report different errors on socket operations with the network disconnected.
  • Some of those errors may be reported in other cases besides network disconnection.
  • Nmap does not have any capability for partial host output. Any in-progress targets would initially be treated as "timed out." See #64 and #243.
  • "Immediately" might be too soon. We want to be able to tolerate some network interruptions (poor WiFi signal, perhaps).

Some thoughts on possible implementations:

  • Start with the most simple working solution: detect the condition and fatal() error. Cleanup actions can be added incrementally.
  • Consider accumulating a "likelihood the network is down for good" factor. Reset it to 0 when a socket operation or pcap read succeeds. When it crosses a threshold, quit. Maybe a "time since last successful read/write" instead?
  • At first sign of trouble, aggressively adjust timing to slow down so fewer probes are missed if the scan recovers (Nmap may be causing the problem!)

This comment has been minimized.

dmiller-nmap commented Nov 21, 2018

Related to this is the idea of manually stopping a scan. That is just a matter of choosing the user interface (signal? Runtime interaction?) and then following the same code path as here. Partial results are still a separate design issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment