Nmap Development mailing list archives
Re: Nmap got a wrong result in windows 2003
From: David Fifield <david () bamsoftware com>
Date: Mon, 21 Jan 2013 02:58:10 -0800
On Fri, Nov 30, 2012 at 01:29:39PM -0000, Rob Nicholls wrote:
I think David may have been confused into thinking two different people were talking about the same bug, as the original emails you sent had the name "rirong zhu", but your recent couple of emails now say "Jarett" (the email address is the same for all of the emails). David, I think the subnets aren't being determined correctly when there's more than one IP address assigned to an interface. I've just checked a Windows 7 host that has two IP addresses running over the same interface (a workaround on a test network due to a lack of spare physical interfaces, not something I'd normally do) and instead of showing the correct subnet of /25 it's showing a subnet of /24 (which matches the subnet of the second IP address assigned to the interface). It looks like the subnet is correctly identified/shown in the ROUTES output (for me and Jarett), but is incorrect under the INTERFACES output. If we were to assume that the subnet mask should be /28 for 115.236.23.45 instead of /29 I suspect it'll work as Nmap should know it can reach 115.236.23.33 directly (instead of trying to route it through 115.236.23.45, which is probably why we're seeing "localhost" issues). Jarett, as a workaround, it may be possible for Nmap to work if the second IP (i.e. 124.160.125.118) is removed from the interface, assuming you're able to do that.
Thanks Rob, I think you're right. This code in libdnet-stripped/src/intf-win32.c is responsible: /* Find the netmask length. This is stored in a parallel list. We just take the first one with a matching address family, but that may not be right. Windows Vista and later has an OnLinkPrefixLength member that is stored right with the unicast address. */ bits = 0; for (prefix = a->FirstPrefix; prefix != NULL; prefix = prefix->Next) { if (prefix->Address.lpSockaddr->sa_family == addr->Address.lpSockaddr->sa_family) { bits = (unsigned short) prefix->PrefixLength; break; } } Unfortunately, I don't see an obvious solution to fixing this. The FirstPrefix list isn't guaranteed to come in any particular order, and the entries don't match up one-to-one with those of the FirstUnicastAddress list. http://msdn.microsoft.com/en-us/library/windows/desktop/aa366058%28v=vs.85%29.aspx It looks as if one can go to heroic lengths to match prefixes to addresses, making some assumptions about the order and handling some special cases: https://code.google.com/p/openpgm/source/browse/trunk/openpgm/pgm/getifaddrs.c?r=1475#923 An option is only to fix the problem for Vista and later, where IP_ADAPTER_UNICAST_ADDRESS has an OnLinkPrefixLength member. http://msdn.microsoft.com/en-us/library/windows/desktop/aa366066%28v=vs.85%29.aspx It looks like even this has a bug with the prefix length of Teredo interfaces. http://stackoverflow.com/a/6579990 http://openpgmdev.blogspot.nl/2011/07/cupcake-and-teredo.html David Fifield _______________________________________________ Sent through the dev mailing list http://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: Nmap got a wrong result in windows 2003 David Fifield (Jan 21)
- Re: Nmap got a wrong result in windows 2003 Jarett (Feb 02)