Re: massping-migration and other dev testing results

[Brandon Enright <bmenrigh () ucsd edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 13 Sep 2007 11:53:34 -0600 plus or minus some time David Fifield
<david () bamsoftware com> wrote:
...snip...
> > I agree that lose is occurring somewhere, I just don't think it is the
> > fault of the network.  I've seen other tools that use libpcap report
> > dropped packets once in a while.  Is it possible that Nmap either isn't
> > getting the packets out and they are being dropped by libpcap or that
> > the responses are getting dropped on the way in?
>
> To investigate this, I added a function to the massping migration branch
> that prints the number of dropped packets reported by libpcap. With -d2,
> it's called once per invocation of ultra_scan, so roughly once per 4096
> hosts during host discovery.
>
> Please run your mpm 'b' scan again with -T5 and see if there are any
> drops (the stats lines start with "pcap stats:"). Then run it with -T3
> and see if more hosts are detected in the (presumably) longer time the
> scan takes.
>
> David Fifield

Okay, did that.  To recap, my 'b' scan is '-sP -P A135,139,445,3389' across
180k hosts.

I did this scan with MPM r5829 twice, sequentially, with no other network
traffic or CPU load on the box.  Once with T3 and once with T5.

david_mpm_r5829bT3.nmap:
# Nmap done at Fri Sep 14 04:14:31 2007 -- 186368 IP addresses (12502 hosts
up) scanned in 4032.982 seconds

david_mpm_r5829bT5.nmap:
# Nmap done at Fri Sep 14 03:07:18 2007 -- 186368 IP addresses (7773 hosts
up) scanned in 2519.749 seconds

Pretty scary how many more hosts -T3 found.  I don't really understand this
considering the packet loss over the actual network should be 0 and the
latency less than 5 ms.  Are hosts really that slow to respond?

Here's the drop information:

$ egrep 'Ultrascan DROPPED' david_mpm_r5829bT3.nmap | wc -l
1246

$ egrep 'Ultrascan DROPPED' david_mpm_r5829bT5.nmap | wc -l
1353

 $ egrep -i 'pcap stats' david_mpm_r5829bT3.nmap
pcap stats: 115 packets received by filter, 0 dropped by kernel.
pcap stats: 18 packets received by filter, 0 dropped by kernel.
pcap stats: 43 packets received by filter, 0 dropped by kernel.
pcap stats: 53553 packets received by filter, 5614 dropped by kernel.
pcap stats: 13849 packets received by filter, 769 dropped by kernel.
pcap stats: 7488 packets received by filter, 272 dropped by kernel.

$ egrep -i 'pcap stats' david_mpm_r5829bT5.nmap
pcap stats: 139 packets received by filter, 0 dropped by kernel.
pcap stats: 18 packets received by filter, 0 dropped by kernel.
pcap stats: 43 packets received by filter, 0 dropped by kernel.
pcap stats: 39723 packets received by filter, 223 dropped by kernel.
pcap stats: 9289 packets received by filter, 46 dropped by kernel.
pcap stats: 7515 packets received by filter, 699 dropped by kernel.

It is interesting that in only two of the groups in -T5 were fewer packets
received than in -T3.  I also find it concerning that the kernel dropped
more packets in -T3; or that the kernel is dropping packets at all.

I've generating graphs for these scans, available at
htpp://noh.ucsd.edu/~bmenrigh/nmap/

I'll look though the host comparison to see if I can find a trend and
report anything interesting.

I know we're starting to get out of the realm of your migration code so if
you've seen enough, to be happy with your code, I'd understand.  If you
still want to run test and try to figure things out, I'm all for that.

Thanks again for your help in getting the most out of these large scans.

Brandon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFG6hD2qaGPzAsl94IRApxbAJ93uJv/KhjwLmsbYyoBhvcQzqXK0wCfXTRF
02yqFfbkjq2hFVvvfMpPdvQ=
=ruF9
-----END PGP SIGNATURE-----

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