Nmap Development mailing list archives
Counter-intuitive handling of --min-parallelism argument without --max-parallelism
From: Chris Woodbury <woodbusy () gmail com>
Date: Sun, 10 Jul 2011 13:02:47 -0500
I have been using the --min-parallelism argument for some time now to speed up my scans, but I just recently discovered that it does not have the effect I thought it did. My intention was to use --min-parallelism to set a floor on the scan's parallelism but to let it go higher dynamically. However, I discovered that using --min-parallelism without --max-parallelism does not have this effect, and that instead it sets the maximum to be the same as the minimum, potentially slowing down scans on fast networks. This behavior is not noted in the Nmap documentation and seems counter-intuitive to me. The reason for this is lines 482-483 of NmapOps.cc. The NmapOps::min_parallelism and NmapOps::max_parallelism variables are initially set to 0, which NmapOps.h defines as meaning their value "has not been set." If no values for these are provided on the command line, the various scan engines see the zeroes and use default values instead. However, if only the minimum is provided on the command line, when NmapOps.cc does a check on line 482 to see whether min_parallelism > max_parallelism, it sets max_parallelism to be the same as min_parallelism. This changes its meaning from "has not been set" to 'has been set to X' and the engines' defaults are no longer used. I can think of a few solutions off the top of my head: 1) Move the min > max checks into the scan engines - Users would be able to set a minimum while still using the default maximum. This is my favorite and seems to best align with my intuition of what --min-parallelism and --max-parallelism should be. 2) Make the initial value for NmapOps::max_parallelism something very high - Users would be able to set a minimum while still using the default maximum. However, the scan engines would now have to check max_parallelism against whatever the new magic value is, instead of 0, which seems a bit less elegant. 3) At the very least, warn the user about what we're doing. I made a patch [parallelism.patch] for #1 because it's my favorite, and I made a patch [parallelism_warning.patch] for #3 because it's easy. I was less comfortable implementing #2 and wanted to get some more-knowledgable input if we're going to go that route. I'd love to hear people's thoughts on this. -chris
Attachment:
parallelism.patch
Description:
Attachment:
parallelism_warning.patch
Description:
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Counter-intuitive handling of --min-parallelism argument without --max-parallelism Chris Woodbury (Jul 10)
- Re: Counter-intuitive handling of --min-parallelism argument without --max-parallelism David Fifield (Aug 01)