Bug#501371: nmap: failed to determine route
Michael Gebetsroither
Version: 4.68-1
Severity: important
Nmap is unable to determine route to any addresse which is matched by
the default routing table.
Nmap thus only works for explizit matches from the main table which
renders it completly useless.
# nmap -sS -vvv -p 80 -e ppp0 www.heise.de
Starting Nmap 4.68 ( http://nmap.org ) at 2008-10-03 17:32 CEST
nexthost: failed to determine route to 193.99.144.85
QUITTING!
# ping www.heise.de
PING www.heise.de (193.99.144.85) 56(84) bytes of data.
64 bytes from www.heise.de (193.99.144.85): icmp_seq=1 ttl=246 time=35.2
ms
--- www.heise.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 35.246/35.246/35.246/0.000 ms
# ip rule
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
cu,
michael
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (991, 'unstable'), (500, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.23-grml64 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.iso885915, LC_CTYPE=en_US.iso885915 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages nmap depends on:
ii libc6 2.7-13 GNU C Library: Shared libraries
ii libgcc1 1:4.3.2-1 GCC support library
ii libpcap0.8 0.9.8-5 system interface for user-level pa
ii libpcre3 7.8-1 Perl 5 Compatible Regular Expressi
ii libssl0.9.8 0.9.8g-13 SSL shared libraries
ii libstdc++6 4.3.2-1 The GNU Standard C++ Library v3
nmap recommends no packages.
nmap suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lukas Schwaighofer
sorry for reviving this almost 9 year old bug, I'm trying to do a bit
of housekeeping :) .
I suspect that what you experienced is a limitation of libdnet (the
library that nmap uses to query the routing table) in combination with
policy routing: It looks like the "default" table is not read, while
the "main" table is. If I put my routes into the "default" routing
table and remove them from "main", the routes disappear from
`nmap --iflist`.
What I don't understand is why you can't put your default route into
the "main" table (instead of the "default" table). From my
understanding, this should not make a difference for any application
using the kernel to determine the correct route. "main" is just looked
at first, and "default" after if there is still no match. Since your
"main" table is empty, moving the contents of "default" to "main"
should be fine.
I also tested performing nmap scans with my routes moved from the
"main" to the "default" table. It turns out that both scans using
normal TCP sockets (tested with `nmap -sT`) as well as those using raw
sockets (tested with `nmap -sS`) worked correctly, even though the
routes used were not present in `nmap --iflist`. So I suspect your
original bug is fixed, at least in nmap 7.60 I'm using now. Would
you mind checking if the problem still exists?
Thanks & Regards
Lukas