Nmap Development mailing list archives
Found possible issue in tcpip.cc - route_dst() Re: --win_help
From: kx <kxmail () gmail com>
Date: Mon, 19 Dec 2005 18:53:05 -0500
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
Current thread:
- Found possible issue in tcpip.cc - route_dst() Re: --win_help kx (Dec 19)