Bug#501371: nmap: failed to determine route

Lukas Schwaighofer lukas at schwaighofer.name
Thu Sep 7 21:00:06 UTC 2017


Hi Michael,

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



More information about the Pkg-security-team mailing list