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

[Fyodor <fyodor () insecure org>]

On Mon, Dec 19, 2005 at 06:53:05PM -0500, kx wrote:
> 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.

Good find.  I have implemented a fix that seems to resolve the
problem:

--- tcpip.cc    (revision 3014)
+++ tcpip.cc    (working copy)
@@ -2571,7 +2571,22 @@
       ifsin = (struct sockaddr_in *) &(iface->addr);
       if ((ifsin->sin_addr.s_addr & mask) == (dstsin->sin_addr.s_addr & mask))
        rnfo->direct_connect = 1;
-      else rnfo->direct_connect = 0;
+      else {
+       rnfo->direct_connect = 0;
+       /* must find the next hop by checking route table ... */
+       routes = getsysroutes(&numroutes);
+       /* Now we simply go through the list and take the first match */
+       for(i=0; i < numroutes; i++) {
+         if (strcmp(routes[i].device->devname, iface->devname) == 0 && 
+             (routes[i].dest & routes[i].netmask) == 
+             (dstsin->sin_addr.s_addr & routes[i].netmask)) {
+           /* Yay, found a matching route. */
+           ifsin = (struct sockaddr_in *) &rnfo->nexthop;
+           ifsin->sin_family = AF_INET;
+           ifsin->sin_addr.s_addr = routes[i].gw.s_addr;
+         }
+       }
+      }
       memcpy(&rnfo->ii, iface, sizeof(rnfo->ii));
       if (o.spoofsource)
        memcpy(&rnfo->srcaddr, &spoofss, sizeof(rnfo->srcaddr));
Index: CHANGELOG
===================================================================
--- CHANGELOG   (revision 3014)
+++ CHANGELOG   (working copy)
@@ -14,6 +14,12 @@
   window.  Thanks to Priit Laes (amd(a)store20.com) for writing these
   excellent patches.
 
+o Fixed a problem with the -e option when run on Windows (or UNIX with
+  --send_eth) when run on an ethernet network against an external
+  (routed) host.  You would get the message "NmapArpCache() can only
+  take IPv4 addresses.  Sorry".  Thanks to kx (kxmail(a)gmail.com) for
+  helping to track down the problem.
+
 o Made some changes to allow source port zero scans (-g0).  Nmap used
   to refused to do this, but now it just gives a warning that it may not
   work on all systems.  It seems to work fine on my Linux box.  Thanks



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