Nmap Development 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 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
Current thread:
- max-scan-delay not honored? Filippo Solinas (Mar 10)
- Re: max-scan-delay not honored? Fyodor (Mar 10)
- Re: max-scan-delay not honored? Fyodor (Mar 10)
- Re: max-scan-delay not honored? Filippo Solinas (Mar 10)
- Re: max-scan-delay not honored? Fyodor (Mar 10)
- Re: max-scan-delay not honored? Filippo Solinas (Mar 11)
- Re: max-scan-delay not honored? Fyodor (Mar 10)