Re: nmap: [REGRESSION 5.00-3 -> 6.00-0.3] -sP fails with "nexthost: failed to determine route to X.X.X.X"

[Daniel Miller <bonsaiviking () gmail com>]

I tracked this down a while back, but I don't remember what happened to my
report. Essentially, you've run up against a limit in the Linux kernel that
can be tuned. The setting mentioned,
"/proc/sys/net/ipv4/neigh/default/gc_thresh3",
is the max number of arp cache entries. If
 your network has more than the default 1024 addresses, then this table can
fill up. It won't in most cases, even if you set it to a lower number,
since most networks are sparsely populated.

It's not a bug in Nmap, because I can produce the same issue with:

    sudo ifconfig eth0:0 10.10.0.0 netmask 255.255.0.0
    for i in {1..255}; do for j in {1..254}; do ping -c 1 10.10.$i.$j &
done; done


Dan


On Wed, Jul 31, 2013 at 3:33 PM, David Fifield <david () bamsoftware com>wrote:

> On Fri, Jul 05, 2013 at 09:50:18AM +0300, Timo Juhani Lindfors wrote:
> > this was originally reported to
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714925 but here's a
> > copy for upstream now that I know that it also occurs with upstream
> > tarballs.
> >
> > Steps to reproduce:
> > 1) configure eth0 to use 10.7.0.0/16 subnet
> > 2) Run "sudo nmap -n -T normal -sP 10.7.24-34.1-254"
> >
> > Expected results:
> > 2) nmap pings each host in the network
> >
> > Actual results:
> > 2) nmap fails after it has processed 1024 hosts:
> >
> > Starting Nmap 6.00 ( http://nmap.org ) at 2013-07-04 14:35 EEST
> > nexthost: failed to determine route to 10.7.28.5
> > QUITTING!
>
> Thanks for this excellent bug report.
>
> I haven't been able to reproduce it yet, but I haven't been on a
> (simulated) network with more than 1024 live hosts.
>
> > 8) strace shows that nmap-5.52.IPv6.Beta1 uses PF_PACKET/SOCK_RAW and
> >    formats the ARP request on its own. nmap-5.52.IPv6.Beta2 on the other
> >    hand seems to use PF_NETLINK/SOCK_RAW and asks the kernel to do the
> >    ARP queries using NETLINK_ROUTE messages. Apparently this causes the
> >    kernel to cache all these queries?
>
> It's a little different--in both cases Nmap constructs and sends the ARP
> packets on its own. IPv6.Beta2 uses PF_NETLINK sockets only for reading
> the routing table--see the route_dst_netlink function. I suppose it's
> possible that reading the routing table in this way causes ARP requests
> to be sent implicitly, but I wasn't able to cause it and didn't find it
> so documented anywhere.
>
> In any case, I suspect that you are right that the change to Netlink is
> the proximate cause of the the problem you encountered. A good quick
> test is to edit libnetutil/netutil.cc to disable route_dst_netlink and
> enable route_dst_generic, and see if the problem persists.
>
> Another thing to try: The --route-dst option makes Nmap make a routing
> decision, without sending pings or any other traffic. Try something like
>         sudo nmap --route-dst 10.7.24.1
> and see if it increases the number of ARP entries in the cache. If so,
> we will have the problem localized closely.
>
> > 9) Even an unprivileged user can do this (with -sT -p 100), is this also
> >    a DoS?
>
> It might be. You don't need special privileges for the Netlink
> operations we're using.
>
> David Fifield
> _______________________________________________
> Sent through the dev mailing list
> http://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/