While running a scan over a huge range, we have to have to wait for the entire scan to complete, is there a specific reason why nmap doesn't output simultaneously? or its just to save time?

  • You could try masscan which is way faster than nmap (a /8 range with simple port scan takes about 3-10 minutes) – architekt Sep 6 '17 at 6:54
  • because it can be scanning multiple targets in parallel – schroeder Sep 6 '17 at 9:33
  • 1
    @schroeder isn't that half of my answer?;) – Tobi Nary Sep 6 '17 at 11:11
  • @SmokeDispenser yep, but the nmap term is 'paralellism', which is something you can control – schroeder Sep 6 '17 at 17:39
  • @schroeder yeah, didn't I cover that, as well as the verbosity that can be controlled as well? – Tobi Nary Sep 6 '17 at 17:41

Because nmap is most often used to generate a result file; if none is specified, the results are written to stdout. That is what you are probably referring to.

It's just easier to have a single routine that collects data and then transforms it in the correct format for output.

More importantly: Depending on the scan you are executing, there might be multiple results rolling in on different hosts at a time.

Thus, real time output of findings would be unstructured and unhelpful. If you rather want to know more of what is going on in the background, you can use the verbosity and debug flags to generate much, much, much more output.


You do not have to wait for the entire scan to complete before you get results, but you do have to wait for the entire hostgroup to finish. Fortunately, you can control somewhat the size of each hostgroup.

Nmap waits to output scan results for a target until the target has completed all phases of scanning (host discovery, port scan, OS detection, NSE scripts, etc.). And it performs each of these scan phases in batches of targets so that it can be doing work on faster targets while it waits for slower targets. The batches are called hostgroups, and the size is determined by the type of scan and the timing level. For UDP or SCTP scans, Nmap tries to scan 128 hosts at a time. For TCP-only scans, the size is determined by the number of ports scanned, though for -T4 and below with large numbers of ports, it begins with a very small hostgroup (4 or 8 hosts) so that you get at least some results quickly before it moves on to the bulk of the scan.

You can control the maximum hostgroup size with the --max-hostgroup option. Setting this to a smaller number (16, 32, etc.) will give you results sooner, but at the cost of reduced parallelism. More time will be spent just waiting on responses from slow targets with nothing else to do. Usually, it's best to find other reasons for slowness and adjust those timing variables instead.


In addition to @SmokeDispenser's answer, be aware that you can adjust the verbosity and other feedback behavior of nmap while it is scanning by entering the following keystrokes:

v / V : Increase / decrease the verbosity level
d / D : Increase / decrease the debugging Level
p / P : Turn on / off packet tracing
?     : Print a runtime interaction help screen

Any other character (or, as I like to call it, "banging away at the space bar") will print a short status message which, while not that trustworthy in predictions, at least reassures you nmap isn't dead:

$ nmap -sP

Starting Nmap 7.40 ( https://nmap.org ) at 2017-09-06 14:42 UTC
Stats: 0:00:02 elapsed; 0 hosts completed (0 up), 4096 undergoing Ping Scan
Ping Scan Timing: About 0.12% done
Stats: 0:00:04 elapsed; 0 hosts completed (0 up), 4096 undergoing Ping Scan
Ping Scan Timing: About 0.24% done
Stats: 0:00:07 elapsed; 0 hosts completed (0 up), 4096 undergoing Ping Scan
Ping Scan Timing: About 0.43% done

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.