Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: Counter-intuitive handling of --min-parallelism argument without --max-parallelism
From: Chris Woodbury <woodbusy () gmail com>
Date: Tue, 4 Oct 2011 15:19:03 -0500

David-

Sorry for the extreme delay - your email slipped through the cracks.
You are correct that the simple check would solve the problem;
however, you would then have a situation where the scan engines could
have minimum values that were above the maximums. For example, if I
ran with --min-parallelism 350 (not necessarily a good idea, but for
the sake of discussion), then NmapOps::min_parallelism would be 350
and ::max_parallelism would be 0. In scan_engine, this would result in
low_cwnd being 350 and max_cwnd being 300. In idle_scan, max_groupsz
would be 100 and min_groupsz would be 350. Etc.

Off the top of my head, I'm not sure what the effects of this would
be, but it sounds like it could cause problems. If that is indeed the
case, I think it would be better to have each scan engine do its own
min < max checking.

What are your thoughts?
-chris

On Tue, Aug 2, 2011 at 12:11 AM, David Fifield <david () bamsoftware com> wrote:
On Sun, Jul 10, 2011 at 01:02:47PM -0500, Chris Woodbury wrote:
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.

Thanks for noticing this. Couldn't option #1 be done much more simply
with something along the lines of

  /* Prevent performance values from getting out of whack */
-  if (min_parallelism > max_parallelism)
+  if (max_parallelism != 0 && min_parallelism > max_parallelism)
    max_parallelism = min_parallelism;

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


  By Date           By Thread  

Current thread:
  • Re: Counter-intuitive handling of --min-parallelism argument without --max-parallelism Chris Woodbury (Oct 04)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]