Nmap Development mailing list archives
Re: Counter-intuitive handling of --min-parallelism argument without --max-parallelism
From: David Fifield <david () bamsoftware com>
Date: Sat, 7 Apr 2012 01:08:24 -0700
On Tue, Oct 04, 2011 at 03:19:03PM -0500, Chris Woodbury wrote:
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.
I have just committed a patch based on this one. It's r28413. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: Counter-intuitive handling of --min-parallelism argument without --max-parallelism David Fifield (Apr 07)