Nmap Development mailing list archives
Re: --win_help
From: Fyodor <fyodor () insecure org>
Date: Mon, 19 Dec 2005 12:12:08 -0800
On Mon, Dec 19, 2005 at 01:53:08PM +0100, Baumgart, Alexander (K-GOT-1) wrote:
************************INTERFACES************************ DEV (SHORT) IP/MASK TYPE UP MAC eth0 (eth0) 10.33.56.221/24 ethernet up 00:0B:5D:24:7A:F7 eth1 (eth1) 192.168.120.254/24 ethernet up 00:07:77:64:09:32
[cut]
192.168.120.254 is a "AVM FRITZ!web PPP over ISDN", that make the trouble. Its per default enable and unplugged.
That certainly casts into question the interface info, which is obtained from libdnet. If the interface is known by the system to be unplugged, I don't think it should be counted as UP. We get that from libdnet (in tcpip.cc) as so: dcrn->ifaces[numifaces].device_up = (entry->intf_flags & INTF_FLAG_UP)? true : false; Dnet decides if a device is up in intf-win32.c: if (ifrow->dwAdminStatus == MIB_IF_ADMIN_STATUS_UP) entry->intf_flags |= INTF_FLAG_UP; It looks like Microsoft also has a dwOperStatus with values such as 'MIB_IF_OPER_STATUS_DISCONNECTED' if the interface is unplugged. See: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mib/mib/mib_ifrow.asp It sounds to me like we should change libdnet to check that as well, and consider the interface down if it is disconnected. This brings us to the next problem. If this is an "AVM FRITZ!web PPP over ISDN", why is it considered ethernet? It even has a supposed MAC address listed. Is that legitimate for this device? I know nothing of this device, but one would expect it to be PPP given the name. As before, Nmap gets this (ethernet) from libdnet. In tcpip.cc: if (entry->intf_type & INTF_TYPE_ETH) { dcrn->ifaces[numifaces].device_type = devt_ethernet; /* Collect the MAC address since this is ethernet */ memcpy(dcrn->ifaces[numifaces].mac, &entry->intf_link_addr.addr_eth.data, 6); } And how does libdnet get the information? Again, in intf-win32.c: entry->intf_type = (uint16_t)ifrow->dwType; As before, ifrow is an MIB_IFROW. This looks a little suspicious at first, since intf_type uses a bunch of ethernet type constant #defines from include/dnet/intf.h, while Microsoft uses their own set of defines from dwType ( in Vc7/PlatformSDK/Include/Ipifcons.h ). But at least on my system, both sets of #defines have equivalent values, which are taken from http://www.iana.org/assignments/ianaiftype-mib . So it appears that Windows may be the one wrongly classifying the device as ethernet. This is a problem (non-ethernet devices appearing to Nmap as ethernet) that I have seen before on Windows, and one I'd definitely like to get fixed. Does anyone have any ideas how to do this? If you have non-ethernet devices on your system (besides loopback), does Nmap properly report the device type with --iflist, or are they wrongly classified as ethernet? Do Nmap scans using the device work?
nmap -e lo0 -sP 10.33.56.0/24 work as usally, what i also didnt understand. Its seem not to be a nmap problem, its more strange behaviour under XP SP2.
That is strange. Cheers, -F _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev
Current thread:
- AW: --win_help Baumgart, Alexander (K-GOT-1) (Dec 19)
- Re: --win_help kx (Dec 19)
- Re: --win_help Fyodor (Dec 19)
- Re: --win_help Fyodor (Dec 28)
- Re: --win_help Fyodor (Dec 28)