Home page logo

nmap-dev logo Nmap Development mailing list archives

nmap: [REGRESSION 5.00-3 -> 6.00-0.3] -sP fails with "nexthost: failed to determine route to X.X.X.X"
From: Timo Juhani Lindfors <timo.lindfors () iki fi>
Date: Fri, 05 Jul 2013 09:50:18 +0300


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

Package: nmap
Version: 6.00-0.3
Severity: normal

Steps to reproduce:
1) configure eth0 to use 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

More info:
1) after step 2 the network is somewhat unusable:

$ ping
connect: No buffer space available

2) I can workaround the problem with

sudo sh -c 'echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3'

3) The default value of gc_thresh3 seems to be 1024. The "refcnt" value
   of the following command seems to hit 1024 when nmap fails:

$ ip ntable show dev eth0 name arp_cache
inet arp_cache 
    dev eth0 
    refcnt 1024 reachable 33340 base_reachable 30000 retrans 1000 
    gc_stale 60000 delay_probe 5000 queue 3 
    app_probes 0 ucast_probes 3 mcast_probes 3 
    anycast_delay 1000 proxy_delay 800 proxy_queue 64 locktime 1000 

4) I tried to use git bisect to figure out where the problem
   started. However, git svn clone kept timing out so I couldn't get a
   copy of the repo. The publicly available git-svn mirror didn't carry
   svn submodules (like nbase/).

6) Finally I resorted into trying older tarball releases. It seems that
   nmap-5.52.IPv6.Beta1 works while nmap-5.52.IPv6.Beta2.tgz fails. I
   could not figure out which svn revisions correspond to these tarballs

grep -hr "/\* \$Id: " nmap-5.52.IPv6.Beta1/|cut -d' ' -f4|sort -n|tail

   hints that they could be r23406 and r23787 respectively.

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?

9) Even an unprivileged user can do this (with -sT -p 100), is this also
   a DoS?

Please let me know if you can't reproduce the problem.

-- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages nmap depends on:
ii  libc6        2.13-38
ii  libgcc1      1:4.7.2-5
ii  liblinear1   1.8+dfsg-1
ii  liblua5.1-0  5.1.5-4
ii  libpcap0.8   1.3.0-1
ii  libpcre3     1:8.30-5
ii  libssl1.0.0  1.0.1e-2
ii  libstdc++6   4.7.2-5
ii  python       2.7.3-4

nmap recommends no packages.

nmap suggests no packages.

-- no debconf information
Sent through the dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]