Nmap Development mailing list archives
Re: [CAPS] Re: Desired improvements in Nmap performance? [SCAN BUDDIES]
From: David Fifield <david () bamsoftware com>
Date: Tue, 2 Dec 2008 17:00:08 -0700
On Tue, Dec 02, 2008 at 11:36:22PM +0000, Brandon Enright wrote:
What's happening is that the one totally filtered host has never sent a reply, so we have no idea what its RTT is. Nmap uses the default of one second, which is pretty slow. But the scan buddy provides a global RTT estimate, which Nmap will use when a host doesn't have its own estimate (HostScanStats::probeTimeout in scan_engine.cc). The approximation is justified in this case as the two hosts are likely to have near-identical RTTs. So the unanswered probes time out much more quickly and the scan goes fast. If you scan the filtered host with --initial-rtt-timeout 50 does the scan go as fast as with the buddy?Well, much faster but not as fast as with the buddy. No buddy, no - --initial-rtt-timeout: $ sudo ./nmap --datadir ./ -p- -T5 -v -d -PN -n 132.239.7.132 SYN Stealth Scan Timing: About 0.03% done Current sending rates: 6.81 packets / s, 284.56 bytes / s. ...killed... Now with the --initial-rtt-timeout: $ sudo ./nmap --datadir ./ -p- -T5 -v -d -PN -n --initial-rtt-timeout 50 132.239.7.132 SYN Stealth Scan Timing: About 0.18% done Current sending rates: 33.81 packets / s, 1472.89 bytes / s. Of course, the buddy was *much* faster than this.
I see, it also has to do with the congestion window (number of probes allowed to be outstanding at once). Just like with the RTT, hosts with no responses can take their congestion window from the global group (HostScanStats::getTiming). The scan buddy allows the global congestion window to grow. My guess is that combining --min-parallelism with --initial-rtt-timeout would give you comparable speeds. With -d3 you can get an output of the current congestion window size. It looks like **TIMING STATS** (0.7920s): IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ccthresh/delay, timeout/srtt/rttvar/ Groupstats (1/1 incomplete): 49/*/*/*/*/* 49.75/75/* 154278/66678/21900 Here the congestion window has a size of 49.75. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- Desired improvements in Nmap performance? David Fifield (Nov 30)
- Re: Desired improvements in Nmap performance? sara fink (Dec 01)
- Re: Desired improvements in Nmap performance? DePriest, Jason R. (Dec 01)
- Re: Desired improvements in Nmap performance? Brandon Enright (Dec 02)
- Re: Desired improvements in Nmap performance? [SCAN BUDDIES] Brandon Enright (Dec 02)
- Re: Desired improvements in Nmap performance? [SCAN BUDDIES] David Fifield (Dec 02)
- Re: [CAPS] Re: Desired improvements in Nmap performance? [SCAN BUDDIES] Brandon Enright (Dec 02)
- Re: [CAPS] Re: Desired improvements in Nmap performance? [SCAN BUDDIES] David Fifield (Dec 02)
- Re: Desired improvements in Nmap performance? [SCAN BUDDIES] Brandon Enright (Dec 02)
- Re: Desired improvements in Nmap performance? [SCAN BUDDIES] Brandon Enright (Dec 02)
- Re: Desired improvements in Nmap performance? [FASTER IS SLOWER] David Fifield (Dec 02)
- <Possible follow-ups>
- Re: Desired improvements in Nmap performance? Rob Nicholls (Dec 01)
- Re: Desired improvements in Nmap performance? sara fink (Dec 01)