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

[kx <kxmail () gmail com>]

> Now to look at this:
>
> nmap -e lo0 -sP 10.33.56.0/24

In targets.cc line 422

/* Then we do the mass ping (if required - IP-level pings) */
if ((*pingtype == PINGTYPE_NONE && !arpping_done) ||
hs->hostbatch[0]->ifType() == devt_loopback) {
   for(i=0; i < hs->current_batch_sz; i++)  {
     if (!hs->hostbatch[i]->timedOut(&now)) {
       initialize_timeout_info(&hs->hostbatch[i]->to);
       hs->hostbatch[i]->flags |= HOST_UP; /*hostbatch[i].up = 1;*/
     }
   }


Because the device is set to loopback, it will just report all hosts
as up.  Perhaps we need a warning or some additional checks when -e
lo0 is specified?

Cheers,
  kx

On 12/19/05, kx <kxmail () gmail com> wrote:
> 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