Re: New option: --min-rate for minimum-rate scanning

["Razi Shaban" <razishaban () gmail com>]

What does it do when the user requests more packets than the computer
can physically send?

I figure a warning of some sort would be better than a crash...

Just my two cents.

--
Razi

On 3/26/08, David Fifield <david () bamsoftware com> wrote:
> Hello,
>
>  I just added a new option --min-rate to Nmap in Subversion. Its option
>  is a number, which is a minimum number of packets to send per second. In
>  other words, use
>
>         nmap --min-rate 1000
>
>  to send at least 1000 packets per second. You can push it as high as you
>  like, but eventually Nmap will hit a limit at which it can't physically
>  send packets any faster, which will depend on your CPU and network
>  hardware.
>
>  This option is good if you think you know a better speed for your
>  network than Nmap can find, or if you have to make sure a scan finishes
>  by a certain time, possibly at the expense of accuracy.
>
>  As a bonus you get a packet sending rate meter built into Nmap. Use the
>  -d option to enable it, then press a key during a scan or wait for
>  overall stats at the end. It looks something like
>
>         Current sending rates: 1024.11 packets / s, 45060.93 bytes / s.
>
>  But watch out when interpreting the overall (average) rates at the end
>  of a scan. The number is likely to be lower than what you asked for,
>  because it includes time at the end of the scan while Nmap is waiting
>  for the last probes to time out, during which no packets are sent. Rest
>  assured that Nmap is honoring your rate request during the times it's
>  sending packets. I admit it's disconcerting to say "--min-rate 1000" and
>  then see "Overall sending rates: 911.84 packets / s".
>
>  There is currently an algorithmic inefficiency in the scan engine that
>  can show itself at really high send rates. When the list of outstanding
>  probes gets really long, it takes a long time to traverse it to find
>  probes to retransmit, and this CPU usage can slow the scan to below the
>  minimum rate. I consider this a bug, and a fix should be forthcoming. In
>  the meantime just be careful about pushing --min-rate too high.
>
>  This is a new, semi-experimental feature, and I invite comments on the
>  implementation or the interface or whatever. For example, Kris suggested
>  a syntax like "--min-rate 100/s" or "--min-rate 600/h" to mean "100
>  packets per second" or "600 packets per hour." Also it would be possible
>  to specify the rate in bytes rather than packets, but I don't know if
>  there's demand for that. Does anyone want a complementary --max-rate
>  option?
>
>  David Fifield
>
>  _______________________________________________
>  Sent through the nmap-dev mailing list
>  http://cgi.insecure.org/mailman/listinfo/nmap-dev
>  Archived at http://SecLists.Org

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