mailing list archives
Re: max-scan-delay not honored?
From: Filippo Solinas <allanon-ph () users sf net>
Date: Sat, 11 Mar 2006 16:17:46 +0100
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
--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?
Sent through the nmap-dev mailing list