Nmap Development mailing list archives
Re: massping migration and you
From: David Fifield <david () bamsoftware com>
Date: Thu, 30 Aug 2007 23:34:45 -0600
On Fri, Aug 31, 2007 at 04:57:16AM +0000, Brandon Enright wrote:
On Thu, 30 Aug 2007 21:08:36 -0600 plus or minus some time David Fifield <david () bamsoftware com> wrote:Which is all the more puzzling because I thought your --min-hostgroup option might be the source of the speed discrepancy. Just for the heck of it, can you try a scan using --min-parallelism 2048 instead?This made an impressive difference: Nmap finished: 186368 IP addresses (13174 hosts up) scanned in 1901.990 seconds Raw packets sent: 1630152 (65.206MB) | Rcvd: 41809 (2.022MB) real 31m42.005s user 0m6.297s sys 0m25.964s
Well, that's good, as long as hosts weren't missed. A parallelism of 2048 is awfully high, though. Does anyone else have ideas why the speeds aren't matching up? Is anyone experiencing the same thing?
I've always been under the impression that --min-parallelism was only used on a per-host basis so I thought setting it to anything above the number of ports being probed per host was useless. Clearly that isn't the case.
With ultra_scan, parallelism is the size of the congestion window, which is the total number of active probes allowed for the current host group. If one host has sent all its probes, probes from other hosts will be sent until the congestion window is filled.
Say I normally scan a single host with --min-parallelism 128. If I scan two hosts at once can I safely set it to 256? How fairly balanced between hosts is this value? If I'm scanning a /24 I may want this to scale into the thousands. At what point is Nmap/ultrascan() going to thrash? Is there a reasonable point of diminishing return?
Parallelism shouldn't depend on the number of hosts. If you say --min-parallelism 128, then the congestion window will not drop lower than 128. Those 128 (or more) probes can be directed at one host or a thousand, it doesn't matter. I don't think you'll gain from increasing the parallelism with the number of hosts. The only thing to watch out for is not to make it too high with too few targets, because then each target will be fielding a lot of probes at once.
Thanks for your help. Let me know if there is anything else you'd like me to try.
Can you do one of your scans like nmap -n -d2 --packet-trace | grep -B 3 DROPPED I want to know what the nature of the drops is. There are conditions under which a good response can be counted as a drop. We're looking for output like RCVD (4.2070s) TCP xxx.xxx.xxx.xxx:80 > yyy.yyy.yyy.yyy:38710 SA ttl=119 id=10597 iplen=44 seq=3589141442 win=65535 ack=75965513 <mss 1460> We got a TCP ping packet back from xxx.xxx.xxx.xxx port 80 (trynum = 1) ultrascan_host_probe_update called for machine xxx.xxx.xxx.xxx state HOST_UP -> HOST_UP (trynum 1 time: 462422) Ultrascan DROPPED probe packet to xxx.xxx.xxx.xxx detected Where the important part is the HOST_UP -> HOST_UP (as opposed to UNKNOWN -> HOST_UP). Those should probably not be counted as drops, and if they are, we need to fix the code. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- Re: massping migration and you, (continued)
- Re: massping migration and you Kris Katterjohn (Aug 29)
- Re: massping migration and you David Fifield (Aug 29)
- Re: massping migration and you Kris Katterjohn (Aug 29)
- Re: massping migration and you Brandon Enright (Aug 29)
- Re: massping migration and you Brandon Enright (Aug 29)
- Re: massping migration and you David Fifield (Aug 30)
- Re: massping migration and you Brandon Enright (Aug 30)
- Re: massping migration and you Brandon Enright (Aug 30)
- Re: massping migration and you David Fifield (Aug 30)
- Re: massping migration and you Brandon Enright (Aug 30)
- Re: massping migration and you David Fifield (Aug 30)
- Re: massping migration and you Brandon Enright (Aug 31)
- Re: massping migration and you David Fifield (Sep 02)