Nmap Development mailing list archives
Re: New development in host discovery: response rate scaled congestion control
From: David Fifield <david () bamsoftware com>
Date: Thu, 6 Sep 2007 10:11:48 -0600
On Thu, Sep 06, 2007 at 04:58:20AM +0000, Brandon Enright wrote:
I did 2 rounds of testing, 4 scans per round. The first was done with r5786 and the second with r5788. Here are the test results for round 1: 64-64: (david_new_2a.svg) # Nmap done at Thu Sep 6 01:31:57 2007 -- 186368 IP addresses (10602 hosts up) scanned in 5013.688 seconds 64-2048: (david_new_2b.svg) # Nmap done at Thu Sep 6 01:16:10 2007 -- 186368 IP addresses (7656 hosts up) scanned in 4066.421 seconds 2048-2048: david_new_2c.svg) # Nmap done at Thu Sep 6 01:16:10 2007 -- 186368 IP addresses (7656 hosts up) scanned in 4066.421 seconds NOMIN-NOMAX (just -T5): david_new_2d.svg) # Nmap done at Thu Sep 6 01:47:37 2007 -- 186368 IP addresses (8972 hosts up) scanned in 5943.742 seconds
You said that you ran all the scans at the same time. This new technique ought to approximate TCP congestion control more closely--if four concurrent Nmaps are run, each one should run about 1/4 as fast. That's the best explanation I can think of. Otherwise, your 2048-2048 result doesn't jibe with the one from a few days ago:
Nmap done: 186368 IP addresses (15804 hosts up) scanned in 258.023 seconds Raw packets sent: 1398404 (55.937MB) | Rcvd: 51659 (2.426MB)
The effect of both the scaled congestion control and the additional drop processing should be negligible with such a large minimum parallelism. The difference in time should not be that great. All of the Nmaps are sharing the bandwidth, except that the 2048-2048 guy is unfairly blasting the network. That's causing the other scans to slow down and drop packets. Please run the NOMIN-NOMAX scan all by itself. And then the 2048-2048 scan by itself, just as a sanity check. If the time is again over about 500 seconds, then I must have changed something I didn't intend to. The only other possibility I can think of is that the additional drop processing is slowing it down. I had previously ignored dropped ICMP destination unreachables; those are no longer ignored because I thought the scaled congestion control would more than make up for the drops. If the above tests don't give favorable results, please try again with the attached patch (it's just the reverse of r5780). Ignoring those drops was something of a compromise to begin with. I think not ignoring them is more correct. Thanks again for your dedicated testing.
I can't explain these results. I've generated graphs these scans in case those will be helpful at all. I removed the y axis limit of 80 before generating these. The graphs are located at: http://noh.ucsd.edu/~bmenrigh/nmap/
Thanks, those help. (The SVG is good because I can stretch them out and get higher resolution.) Although they all looked to be capped at 80, so for the 2048-2048 scans the black line was clipped completely (not even present in the XML file). David Fifield
Attachment:
drops.diff
Description:
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- New development in host discovery: response rate scaled congestion control David Fifield (Sep 05)
- Re: New development in host discovery: response rate scaled congestion control Brandon Enright (Sep 05)
- Re: New development in host discovery: response rate scaled congestion control David Fifield (Sep 05)
- Re: New development in host discovery: response rate scaled congestion control Brandon Enright (Sep 05)
- Re: New development in host discovery: response rate scaled congestion control David Fifield (Sep 05)
- Re: New development in host discovery: response rate scaled congestion control Brandon Enright (Sep 05)
- Re: New development in host discovery: response rate scaled congestion control David Fifield (Sep 05)
- Re: New development in host discovery: response rate scaled congestion control Brandon Enright (Sep 05)
- Re: New development in host discovery: response rate scaled congestion control David Fifield (Sep 06)
- Re: New development in host discovery: response rate scaled congestion control Brandon Enright (Sep 06)
- Re: New development in host discovery: response rate scaled congestion control David Fifield (Sep 06)
- Re: New development in host discovery: response rate scaled congestion control Brandon Enright (Sep 06)
- Re: New development in host discovery: response rate scaled congestion control David Fifield (Sep 05)
- Re: New development in host discovery: response rate scaled congestion control Brandon Enright (Sep 05)
- Re: New development in host discovery: response rate scaled congestion control David Fifield (Sep 05)