Found possible issue in tcpip.cc - route_dst() Re: --win_help

[kx <kxmail () gmail com>]

Possible fix below.

On 12/19/05, Baumgart, Alexander (K-GOT-1)
<alexander.baumgart () volkswagen de> wrote:
> nmap -e eth0 -sP 10.33.56.0/24
>
> Starting Nmap 3.95 ( http://www.insecure.org/nmap ) at 2005-12-19 13:45
> Westeuropõische Normalzeit
> NmapArpCache() can only take IPv4 addresses.  Sorry
> QUITTING!

tcpip.cc - route_dst()  - Line 2534 (my apologies if my line numbers
are off slightly).

It appears as though route_dst() is not setting rnfo->nexthop when -e
is set, and possibly when -S is set. Line 2553 of tcpip.cc   if
(o.spoofsource || *o.device) {..}

Then in setTargetNextHopMAC at line 1948 of tcpip.cc

    if (!target->nextHop(&targetss, &sslen))
      fatal("%s: Failed to determine nextHop to target", __FUNCTION__);
  }

This returns true, even though this.nexthopsock does not contain a
valid sockaddr_storage.

My suggestion is that where the if (o.spoofsource || *o.device) {..}
block would have returned true, we instead jump to the end of
route_dst where rnfo->nexthop is set, or we handle rnfo->nexthop in
the above block, whichever makes more sense.

Now to look at this:

nmap -e lo0 -sP 10.33.56.0/24


Cheers,
  kx


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