Re: max-scan-delay not honored?

[Filippo Solinas <allanon-ph () users sf net>]

On Fri, 10 Mar 2006 16:07:44 -0800, Fyodor wrote:

| The --scan-delay is a special delay Nmap enforces between packets when
| it detects certain kinds of rate limiting.  It probably isn't
| detecting that sort of rate limiting, so the extra scan delay is 0.
| Thus setting the maximum scan delay to 10 has no effect.  See

Now it's clear!

So, as I was supposing in the first post, --max-scan-delay takes part
only in limiting the send delay when increased due to dropped probes.
No rate limiting detected, no scan-delay adjustment.

If I am correct, for the sake of clearness the sentence
"This is particularly useful in the case of rate limiting"
in the man page should be read s/particularly/*only*/ .


| One feature I am considering that you may like is allowing you to
| specify an exact number of packets that Nmap should try to send each
| second, rather than having Nmap use its own smarts.  If you haven't

Yes, this sounds to me "extraordinarily cool!", but..
let's suppose I want to send 20 probes per second.
There are two main ways to accomplish this task:

a) parallelizing, i.e.: delta time between each probe sent =~ 0
   (and this is the same as issuing a default nmap with -P0,
   --min-parallelism 20 and --max-parallelism 20, *until*
   it finds an open/closed port or receive an ICMP, so
   that nmap can calculate a more appropriate delay);

b) serializing, by sending a probe every 1000/20 = 50 ms.

But a more flexible approach could be:

c) parallelizing or serializing, depending on --min/max-parallelism
   options, e.g.:

   --max-parallelism 1 --send-rate 20
        will send a single probe every 50 ms;

   --min-parallelism 5 --max-parallelism 5 --send-rate 20
        will send a 5-parallel-probes group every 50 ms;

   --min-parallelism 5 --max-parallelism 10 --send-rate 20
        will send a min5-max10-parallel-probes group every 50 ms,
        letting nmap choose the best number of outgoing parallel
        probes depending on network reliability.

BTW, since the "send rate" is fixed, no scan-delay adjustment
due to rate limiting should be taken into consideration.

This is a solution very flexible I'd like to see implemented.

What do you think about?


Thanks,

        ph.



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