Re: new Win install fails beyond localhost

[David Fifield <david () bamsoftware com>]

On Fri, Mar 12, 2010 at 03:53:42PM -0700, David Fifield wrote:
> On Tue, Mar 09, 2010 at 03:30:30PM -0600, Norris Carden wrote:
> > Results as requested... thanks for pointing out these options.. 
> >
> > nmap --iflist
> >
> > Starting Nmap 5.21 ( http://nmap.org ) at 2010-03-09 15:13 Central
> > Standard Time
> >
> > ************************INTERFACES************************
> > DEV  (SHORT) IP/MASK         TYPE     UP MAC
> > eth0 (eth0)  10.1.1.XX/24 ethernet up 00:00:00:00:00:00
> > lo0  (lo0)   127.0.0.1/8     loopback up
> >
> > DEV    WINDEVICE
> > eth0   \Device\NPF_{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
> > lo0    <none>
> > <none> \Device\NPF_{ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ}
> > <none> \Device\NPF_{YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY}
> >
> > **************************ROUTES**************************
> > DST/MASK           DEV  GATEWAY
> > 10.255.255.255/32  eth0 10.1.1.1
> > 10.1.1.XX/32    lo0  127.0.0.1
> > 255.255.255.255/32 eth0 10.1.1.XX
> > 10.1.1.0/0       eth0 10.1.1.XX
> > 127.0.0.0/0        lo0  127.0.0.1
> > 224.0.0.0/0        eth0 10.1.1.XX
> > 0.0.0.0/0          eth0 10.1.1.1
> >
> > nmap -sP -d3 -PE -PA21,23,80,3389 10.1.1.0/29 (this should find 6
> > responding IPs).
> > Nmap scan report for 10.1.1.0 [host down, received no-response]
> > Nmap scan report for 10.1.1.1 [host down, received no-response]
> > Nmap scan report for 10.1.1.2 [host down, received no-response]
> > Nmap scan report for 10.1.1.3 [host down, received no-response]
> > Nmap scan report for 10.1.1.4 [host down, received no-response]
> > Nmap scan report for 10.1.1.5 [host down, received no-response]
> > Nmap scan report for 10.1.1.6 [host down, received no-response]
> > Nmap scan report for 10.1.1.7 [host down, received no-response]
>
> I think this has now been fixed.
>
> http://seclists.org/nmap-dev/2010/q1/845
>
> The eth0 device has the address and netmask 10.1.1.XX/24, so Nmap was
> considering all the 10.1.1.0/29 hosts directly connected and was using
> ARP scan for them. But the routing table entry
>
> > 10.1.1.0/0       eth0 10.1.1.XX
>
> should have overridden that, and caused traffic to be routed through the
> gateway.

I've had to revisit this issue, and now I take back what I said about it
being fixed. I think the problem is actually the network teaming you
mentioned in http://seclists.org/nmap-dev/2010/q1/832, not the routing
table.

I've prepared a test version of Nmap with lots of debugging output
around the assignment of interface names.

http://nmap.org/dist/nmap-5.30BETA1-debug1-win32.zip

I think the output will help me solve the problem. Please run

nmap --iflist > nmap-iflist-debug1.txt

and then send me the file nmap-iflist-debug1.txt. I've attached the diff
used to prepare this release.

David Fifield

Attachment: nmap-5.30BETA1-intf-debug1.diff
Description:

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