1

I'm performing a TCP scan on a network and noticed that nmap decreased the percentage of the progress.

The command is: nmap -A -sT 10.0.0.1-254 -oG scan.txt

Amongst the output I found:

Stats: 0:13:37 elapsed; 211 hosts completed (43 up), 43 undergoing Connect Scan
Connect Scan Timing: About 98.48% done; ETC: 04:04 (0:00:13 remaining)
Stats: 0:17:53 elapsed; 211 hosts completed (43 up), 43 undergoing Connect Scan
Connect Scan Timing: About 98.47% done; ETC: 04:09 (0:00:17 remaining)

Can this be disregarded as a fluctuation, or is there something else about the scan going on, I don't know about?

2

Nmap's percent completion stats are based on number of things completed divided by number of things attempted plus the number of things left to do. During a port scan, the "things" are probes being sent. If Nmap had completed 94 of 100 probes, the percent would be 94%. If it then sends out a new probe, the completed part is still 94/100, but the attempted part is 0/1. The total fraction would be 94/101, or 93%.

This might seem like a poor way to do it, but it works pretty well given how Nmap sends many probes at once and may change the number of probes it intends to try at any time based on the target's response.

2

The per-host completion fraction is calculated (scan_engine.cc UltraScanInfo::getCompletionFraction()) as:

 ports_finished * ( maxtries - 1 ) + probes_sent
 _______________________________________________
             maxtries * numprobes

The total completion percentage is calculated from this across all the hosts. In a TCP scan (-sT) the number of probes numprobes is fixed to the number of ports ( scan_engine.cc UltraScanInfo::numProbesPerHost()) and never changes after initialization, so maxtries is the interesting term of the calculation. ports_finished and probes_sent are incrementing counters, the above works out to 1.0 when ports_finished == probes_sent == numprobes. numprobes will be 1000, the default number of TCP probes in the example you gave.

If maxtries increases (due to timeout and retry) the estimated amount of work left to do increases, and hence the fraction of work completed decreases. (--max-retries can control this, though with a -sT for TCP connection by the OS IP stack connect() some of the other timeout/retry parameters that nmap supports are ineffective).

The maxtries count is not naïve, it is the high water mark of retries (+1) for a successfully probed port in the scan so far. If you add -d (debug) you will see the message "Increasing max_successful_tryno for 1.2.3.4 to 1 (packet drop)". This is not the same message as "Increasing send delay ...". You will likely see both messages when there is packet loss during a scan.

What you have seen then is a successful TCP probe for a host, but it required a retry, it occurred late in the scan and managed to bump up the upper bound on the work estimate. It probably revised the completion down more than 1%, and packet loss probably cause timeouts to increase, decreasing the scan rate. Approximately 4 minutes elapsed between the two status lines, so the drop in completion was not simply 0.01%.

Service scan timing is a separate calculation.

0

I'd recommend to build latest version of Nmap from source and testing it.

If it still persist, report to the author with the full command line.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.