Re: massping migration and you

[David Fifield <david () bamsoftware com>]

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