Comment 11 for bug 1908223

Revision history for this message
Bryce Harrington (bryce) wrote :

> On my host I just run
> sudo nmap -PS22 -p22 192.168.77.0/24

I've tried this and several other permutations described on this bug and the upstream PRs on my own network, but I also do not reproduce the crash.

From what I understand of the problem, however, it might depend on either the network configuration or on devices present on the network. That may explain why some people see the issue consistently, and others cannot reproduce. There might be some form of race condition involved as well - which could explain why it sometimes works and sometimes doesn't, and why workarounds that change the scanning time resolved it for some people in some cases.

This comment gives some insight into what is going on under the hood, however it's from 2018 and things have changed, so it's only good for background:
  https://github.com/nmap/nmap/issues/1361#issuecomment-431485063

If the issue is caused by a particular machine on your network, you may be able to narrow it down by running the scan on smaller and smaller subsets, e.g.:

$ sudo nmap -PS22 -p22 192.168.77.0-128
$ sudo nmap -PS22 -p22 192.168.77.128-254

If one of those fails but the other doesn't, keep narrowing the range until you can identify it. If it does happen to pinpoint specific machine(s), look at what might be odd about that system.