Re: Counter-intuitive handling of --min-parallelism argument without --max-parallelism

[David Fifield <david () bamsoftware com>]

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/