Nmap Development mailing list archives
RE: Windows 7
From: "Rob Nicholls" <robert () robnicholls co uk>
Date: Sat, 5 Feb 2011 00:39:29 -0000
David will see it all anyway as he's on the nmap-dev mailing list too. I've
not looked through this sort of debug output before, but it looks to me like
Nmap is failing to match the WINDEVICE correctly:
eth16 \Device\NPF_{AEC749F8-57B4-4542-AEF6-30539FC9FC87}
eth17 \Device\NPF_{AEC749F8-57B4-4542-AEF6-30539FC9FC87}
eth18 \Device\NPF_{AEC749F8-57B4-4542-AEF6-30539FC9FC87}
eth19 \Device\NPF_{AEC749F8-57B4-4542-AEF6-30539FC9FC87}
eth20 \Device\NPF_{AEC749F8-57B4-4542-AEF6-30539FC9FC87}
eth0 <none>
eth1 <none>
eth2 <none>
eth3 \Device\NPF_{47C778F5-8BAC-4C1C-A7BD-7CB05BBAE58B}
eth4 \Device\NPF_{47C778F5-8BAC-4C1C-A7BD-7CB05BBAE58B}
eth5 <none>
eth6 <none>
eth7 \Device\NPF_{47C778F5-8BAC-4C1C-A7BD-7CB05BBAE58B}
<none> \Device\NPF_{EED21227-E2CE-4EFF-A995-9C4110FF08D1}
You can see there's a DEV called "<none>" that's matched against
"\Device\NPF_{EED21227-E2CE-4EFF-A995-9C4110FF08D1}" (this happens in both
debug outputs).
In the second debug output eth16 has <none> against it.
Your wireless card appears to have a MAC of f0:7b:cb:8f:71:b7 that matches
two devices:
eth_get_pcap_devname: iter
"\Device\NPF_{AEC749F8-57B4-4542-AEF6-30539FC9FC87}" mac f0:7b:cb:8f:71:b7
eth_get_pcap_devname: iter
"\Device\NPF_{EED21227-E2CE-4EFF-A995-9C4110FF08D1}" mac f0:7b:cb:8f:71:b7
I would guess that Nmap is incorrectly matching the eth16 DEV against the
AEC749F8 WINDEVICE in the first debug output and <none> in the second
output, when the WINDEVICE that should be used is the EED21227 device that
hasn't been matched against anything! It's hopefully a case of matching up
the wireless interface to the right device.
I've just seen your follow up email and the iteration at the very end
suggests to me that debug1 matches against two devices and decides to use
the first one (when we probably want it to use the second). I'm not sure if
Nmap can handle it better as it might not have enough information to
correctly match them up. Debug2 makes sense as eth16 has <none> as the
WINDEVICE so Nmap gives up with a nice error message.
Do you only have one wireless interface displayed in Windows 7, or are there
multiple devices? If there's more than one, does it help if you disable the
unused interface so Nmap/WinPcap might not see it as up/with a MAC? It
might be a workaround until Nmap can improve the way it matches the devices.
Rob
-----Original Message-----
From: Christian Savalas [mailto:csavalas () gmail com]
Sent: 05 February 2011 00:06
To: Rob Nicholls
Cc: nmap-dev () insecure org
Subject: Re: Windows 7
Hi Rob,
Well, I went ahead and saved the output of IFlist from those two debug BETA
releases (5.30 debug 1&2) to two text files. They are attached to this
message; do I need to forward it to David as well? I am pretty good with
this stuff, but the output of that command was so monstrous from those two
debug releases, that I have no idea how to even begin making sense of it.
Let's see what happens!
Christo
On Fri, Feb 4, 2011 at 3:20 PM, Rob Nicholls <robert () robnicholls co uk>
wrote:
Christo, That sounds quite unusual, and could be related to the similar problem recently mentioned here: http://seclists.org/nmap-dev/2011/q1/52 David suggested providing him with the --iflist output from those two debug releases. This does look to me like an Nmap problem, but I have no idea why the mapping to the WINDEVICE isn't present at all. Hopefully this is something that can be fixed in a later release of Nmap. I'm glad we seem to be getting somewhere, but you'll probably have to thank David from now on as I'm getting out of my depth here! Rob -----Original Message----- From: nmap-dev-bounces () insecure org [mailto:nmap-dev-bounces () insecure org] On Behalf Of Christian Savalas Sent: 04 February 2011 23:05 To: Rob Nicholls Cc: nmap-dev () insecure org Subject: Re: Windows 7 Hi Rob, Maybe we are onto something now. The output of -iflist which I sent you was the output in its entirety. It does not continue to display the libpcap mapping of DEV to WINDEVICE. Why would that be? I've got my
fingers crossed!
Thank you again for helping me! Christo On Fri, Feb 4, 2011 at 2:49 PM, Rob Nicholls <robert () robnicholls co uk> wrote:Hi Christo, You're right, eth16 does look like the correct interface. After running --iflist and getting the list of interfaces seen below, do you get any further output before the list of routes? It should look somethinglike:DEV WINDEVICE eth0 <none> eth1 <none> eth2 \Device\NPF_{12AB34CD-E567-89F0-AB01-234C567890D1} eth3 \Device\NPF_{12AB34CD-E567-89F0-AB01-234C567890D1} eth4 <none> eth5 \Device\NPF_{12AB34CD-E567-89F0-AB01-234C567890D1} eth6 <none> eth7 \Device\NPF_{12AB34CD-E567-89F0-AB01-234C567890D1} eth8 <none> eth9 <none> eth10 <none> ppp0 <none> ppp1 <none> lo0 <none> eth0 <none> eth1 <none> eth2 \Device\NPF_{12AB34CD-E567-89F0-AB01-234C567890D1} eth3 \Device\NPF_{12AB34CD-E567-89F0-AB01-234C567890D1} eth4 <none> eth5 \Device\NPF_{12AB34CD-E567-89F0-AB01-234C567890D1} For this particular host, eth2 is the correct interface, and eth2 has the right WINDEVICE against it. If you're getting <none> against eth16 then this could be why you're not seeing any traffic sent by
Nmap/WinPcap.
The "Microsoft" entry in Wireshark should be normal, I think it simply means you're using Vista/7 with NDIS6 drivers that hand everything over to an intermediate Microsoft driver that does the (hard?) work of converting 802.11 frames into 802.3 frames that can be dealt with more easily. Rob -----Original Message----- From: nmap-dev-bounces () insecure org [mailto:nmap-dev-bounces () insecure org] On Behalf Of Christian Savalas Sent: 04 February 2011 22:31 To: Rob Nicholls; nmap-dev () insecure org Subject: Re: Windows 7 Hi Rob, Nice to hear from you again. Btw, you had a good point, that the -e switch is unnecessary with -sT... overlooked the redundancy. Anyway, I'll try to speak to each of your presumptions. When iflist is run while connected wirelessly, the result is this: ************************INTERFACES************************ DEV (SHORT) IP/MASK TYPE UP MTU MAC eth0 (eth0) (null)/0 ethernet down 0 00:00:00:00:00:00 eth1 (eth1) (null)/0 ethernet up 1500 8C:F5:20:52:41:53 eth2 (eth2) (null)/0 ethernet up 1500 8C:F5:20:52:41:53 eth3 (eth3) (null)/0 ethernet down 1500 00:26:B9:CF:50:5F eth4 (eth4) (null)/0 ethernet down 1500 00:26:B9:CF:50:5F eth5 (eth5) (null)/0 ethernet up 1500 8C:F5:20:52:41:53 eth6 (eth6) (null)/0 ethernet up 1500 8C:F5:20:52:41:53 eth7 (eth7) (null)/0 ethernet down 1500 00:26:B9:CF:50:5F eth8 (eth8) (null)/0 ethernet up 1500 8C:F5:20:52:41:53 eth9 (eth9) (null)/0 ethernet up 1500 8C:F5:20:52:41:53 eth10 (eth10) 169.254.89.175/16 ethernet up 1500 00:50:56:C0:00:01 eth11 (eth11) 169.254.176.88/16 ethernet up 1500 00:50:56:C0:00:08 eth12 (eth12) (null)/0 ethernet down 1500 F0:7B:CB:8F:71:B7 eth13 (eth13) (null)/0 ethernet down 1500 F0:7B:CB:8F:71:B7 eth14 (eth14) (null)/0 ethernet down 1500 F0:7B:CB:8F:71:B7 eth15 (eth15) (null)/0 ethernet down 0 00:02:76:1E:E4:F6 ppp0 (ppp0) (null)/0 other up 1494 ppp1 (ppp1) (null)/0 other down 0 lo0 (lo0) 127.0.0.1/8 loopback up 1500 eth16 (eth16) 192.168.1.133/24 ethernet up 1500 F0:7B:CB:8F:71:B7 eth17 (eth17) (null)/0 ethernet up 1500 F0:7B:CB:8F:71:B7 eth18 (eth18) (null)/0 ethernet up 1500 F0:7B:CB:8F:71:B7 eth19 (eth19) (null)/0 ethernet up 1500 F0:7B:CB:8F:71:B7 eth20 (eth20) (null)/0 ethernet up 1500 F0:7B:CB:8F:71:B7 eth0 (eth0) (null)/0 point2point up 4091 eth1 (eth1) (null)/0 point2point down 1480 eth2 (eth2) (null)/0 point2point up 1460 eth3 (eth3) (null)/0 point2point up 1464 eth4 (eth4) (null)/0 point2point down 1280 eth5 (eth5) (null)/0 point2point down 1280 eth6 (eth6) (null)/0 point2point down 1280 eth7 (eth7) (null)/0 point2point down 1280 To me, this indicates that eth16 would be the correct adapter. The story gets even more interesting when you factor in Wireshark's behavior. While I know getting promiscuous mode to work with a factory installed wireless card is a pipe dream, I have confirmed that wireless packet capturing on my own wireless card with Wireshark DOES indeed work with all other traffic, except for Nmap traffic (without -sT). Does this point to a problem with Nmap->Winpcap interaction? The last weirdness I can add to the mystery is that although Wireshark flawlessly detects non-promiscuous traffic relevant to my wireless interface, Wireshark shows the wireless interface name as "Microsoft", whereas my ethernet controller shows up more normally as "Atheros L1C etc...". To be continued, I suppose... Christo On Fri, Feb 4, 2011 at 1:34 PM, Rob Nicholls <robert () robnicholls co uk> wrote:Hi Christo, I'm glad you had more luck with wired! WinPcap on Windows has quite a few limitations, so it's possible that this is why you're having less success using the wireless
interface.
TheWinPcapFAQ states: Wireless adapters: these adapters may present problems, because they arenotproperly supported by the Windows Kernel. Some of them are not detected, other don't support promiscuous mode. In the best case, WinPcap is able to see an Ethernet emulation and not the real transiting packets: this means that the 802.11 frames are transformed into fake Ethernet frames before being captured, and that control frames are not received When you use -sT you're performing a Connect scan, and on Windows thisusesthe native operating system to send them (if you use --unprivileged it'll only use the OS to do the scans, which prevents many Nmap features from working properly) so Nmap doesn't have to work out which interface to useasit doesn't use WinPcap to send the packets (and this is why -e isn't necessary here). If you do a --packet-trace you'll see the difference in Nmap's output between a SYN scan using WinPcap (lots of details about flags and ids) andaConnect scan through the OS (it pretty much just says "Operation now in progress"). The fact -sT works for you suggests to me that the problem is related to WinPcap or your wireless card, although it's possible that Nmap is failing to detect your wireless device properly. I suspect you don'tneedto use -Pn when doing a Connect scan with the wireless card. I assume eth16 appeared to correspond with your wireless card when you ran "nmap --iflist"? Did you happen to spot any other interfaces that had something like <none> against the WINDEVICE? There have been issues in the past where the wrong interface was determined, or the correct interface couldn't be correctly tied to the right WINDEVICE, but David's solved most of these problems. I couldn't quickly spot any traffic sent to scanme.nmap.org, so either you weren't capturing from the right network adaptor or (much more likely) the packets were never sent by Nmap/WinPcap using that adaptor (it's possible they were sent to another adaptor, that might not exist/show up in Wireshark). Rob -----Original Message----- From: Christian Savalas [mailto:csavalas () gmail com] Sent: 04 February 2011 20:22 To: Rob Nicholls Subject: Re: Windows 7 Hi again, It's really ironic that after a year of tooling with this I would discover new information a few minutes after finally sendig you guys amessage!AfterI hit send, I realized I hadn't tried it on a wired ethernet connectionfortwo revisions. Lo and Behold, it works... Cool! And on the wireless side, I discovered that the addition of the -sT switch with -Pn does indeed produce the expected results, but I may aswelluse Superscanner for that ;) I should have mentioned in my first message that all other Windows nettoolslike ping, tracert work just fine on any address, using the wireless interface. And I have indeed visited scanme.nmap.org with a browser. What's odd is that nmap works fully with ethernet, only partially(tcpip.sysstyle -sT) with wireless. Does this point to the winpcap library? I would think so, but then again, Wireshark appears to capture packets. I got excited about your suggestion to specify the interface explicitly,butthen I remembered what I discovered about the scan working with the -sT switch, with no explicit selection of interface. Needless to say, I did try it, with no different results. The command: "nmap -d -Pn -e eth16 scanme.nmap.org" yields the resulting output: --------------------------------- --------------------------------- Winpcap present, dynamic linked to: WinPcap version 4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b (20091008) Starting Nmap 5.50 ( http://nmap.org ) at 2011-02-04 11:50 PacificStandardTime PORTS: Using top 1000 ports found open (TCP:1000, UDP:0, SCTP:0) --------------- Timing report --------------- hostgroups: min 1, max 100000 rtt-timeouts: init 1000, min 100, max 10000 max-scan-delay: TCP 1000, UDP 1000, SCTP 1000 parallelism: min 0, max 0 max-retries: 10, host-timeout: 0 min-rate: 0, max-rate: 0 --------------------------------------------- mass_rdns: Using DNS server 192.168.1.1 mass_rdns: Using DNS server 192.168.1.1 mass_rdns: Using DNS server 192.168.1.1 Initiating Parallel DNS resolution of 1 host. at 11:50 mass_rdns: 0.02s 0/1 [#: 3, OK: 0, NX: 0, DR: 0, SF: 0, TR: 1] Completed Parallel DNS resolution of 1 host. at 11:50, 0.01s elapsed DNS resolution of 1 IPs took 0.02s. Mode: Async [#: 3, OK: 1, NX: 0, DR: 0, SF: 0, TR: 1, CN: 0] Initiating SYN Stealth Scan at 11:50 Scanning scanme.nmap.org (64.13.134.52) [1000 ports] Packet capture filter (device eth16): dst host 192.168.1.133 and (icmp or ((tcp or udp or sctp) and (src host 64.13.134.52))) SYN Stealth Scan Timing: About 14.50% done; ETC: 11:53 (0:03:03 remaining) SYN Stealth Scan Timing: About 29.50% done; ETC: 11:53 (0:02:26 remaining) " " Completed SYN Stealth Scan at 11:53, 203.00s elapsed (1000 total ports) Overall sending rates: 9.85 packets / s, 433.50 bytes / s. Nmap scan report for scanme.nmap.org (64.13.134.52) Host is up, received user-set. All 1000 scanned ports on scanme.nmap.org (64.13.134.52) are filtered because of 1000 no-responses Read from C:\Program Files (x86)\Nmap: nmap-payloads nmap-services. Nmap done: 1 IP address (1 host up) scanned in 203.38 seconds Raw packets sent: 2000 (88.000KB) | Rcvd: 0 (0B) --------------------------------- --------------------------------- As you can see, the host is declared up, with no open ports. And now with -Pn removed from the command (nmap -d -e eth16 scanme.nmap.org), I am left with this: --------------------------------- --------------------------------- Winpcap present, dynamic linked to: WinPcap version 4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b (20091008) Starting Nmap 5.50 ( http://nmap.org ) at 2011-02-04 11:56 PacificStandardTime PORTS: Using top 1000 ports found open (TCP:1000, UDP:0, SCTP:0) --------------- Timing report --------------- hostgroups: min 1, max 100000 rtt-timeouts: init 1000, min 100, max 10000 max-scan-delay: TCP 1000, UDP 1000, SCTP 1000 parallelism: min 0, max 0 max-retries: 10, host-timeout: 0 min-rate: 0, max-rate: 0 --------------------------------------------- Initiating Ping Scan at 11:56 Scanning scanme.nmap.org (64.13.134.52) [4 ports] Packet capture filter (device eth16): dst host 192.168.1.133 and (icmp or ((tcp or udp or sctp) and (src host 64.13.134.52))) Completed Ping Scan at 11:56, 4.39s elapsed (1 total hosts) Overall sending rates: 1.82 packets / s, 69.28 bytes / s. mass_rdns: Using DNS server 192.168.1.1 mass_rdns: Using DNS server 192.168.1.1 mass_rdns: Using DNS server 192.168.1.1 Nmap scan report for scanme.nmap.org (64.13.134.52) [host down, received no-response] Read from C:\Program Files (x86)\Nmap: nmap-payloads nmap-services. Note: Host seems down. If it is really up, but blocking our ping probes,try-Pn Nmap done: 1 IP address (0 hosts up) scanned in 4.75 seconds Raw packets sent: 8 (304B) | Rcvd: 0 (0B) --------------------------------- --------------------------------- So strange, because the output seems to have resolved the domain to the ip 64.13.134.52, and, beyond that, "ping" works from the commandprompt.Lastly, I have tried capturing packets with Wireshark while running thescanwith AND without -Pn, but I am by no means an expert on packet
analysing.
Iattached the two logs for you, just in case it would help. From myuntrainedeye, I honestly don't see any NMap traffic. I sincerely appreciate you getting back to me so soon, and I hope to hear from you with good news! All the best, Christo On Fri, Feb 4, 2011 at 1:58 AM, Rob Nicholls <robert () robnicholls co uk> wrote:Hi Christo On Fri, 4 Feb 2011 01:01:18 -0800, Christian Savalas wrote:Despite this, regardless of which address I scan, (even scanme.nmap.org) I am told that 0 hosts are up.If you add -Pn to the Nmap commands you're running, Nmap will assume the host is up and should attempt to scan the host. Are you able to use Windows' built in "ping" utility to ping a remote host over the internet? e.g.ping scanme.nmap.orgPinging scanme.nmap.org [64.13.134.52] with 32 bytes of data: Reply from 64.13.134.52: bytes=32 time=145ms TTL=50 Reply from 64.13.134.52: bytes=32 time=145ms TTL=50 Reply from 64.13.134.52: bytes=32 time=145ms TTL=50 Reply from 64.13.134.52: bytes=32 time=145ms TTL=50 This is one of the checks that Nmap tries to determine if a host is up. If you don't get a response then it's possible that your ISP is filtering ICMP traffic. Are you able to view http://scanme.nmap.org using your browser? You should get a white page with a message from Fyodor in black text. If you can see this, then you can access port 80/TCP. This is another port that Nmap will try in order to determine whether a host is
up.
If you can't see the web page then something bad is happening. Have you tried running Wireshark at the same time as an Nmap scan? This would let you see if packets are sent from or returned to your host. I'd be surprised if Nmap is failing to identify the returned packets, but this might happen if you have teamed NICs, for example. If you add -d to the Nmap command you'll see some debug information, including a line like: Packet capture filter (device eth7): dst host xx.xx.xx.xx and (icmp or ((tcp or udp or sctp) and (src host xx.xx.xx.xx))) If you run "nmap --iflist" you should see a list of interfaces (androutes).It's possible that the correct NIC isn't picked up by Nmap and it's trying to send packets over the wrong interface (and getting nothing back). You can use -e to state the correct interface to use,
e.g.
nmap scanme.nmap.org -e eth7Starting Nmap 5.51SVN ( http://nmap.org ) at 2011-02-04 09:57 GMT Standard Time Nmap scan report for scanme.nmap.org (64.13.134.52) Host is up (0.15s latency). Not shown: 993 filtered ports PORT STATE SERVICE 22/tcp open ssh 25/tcp closed smtp 53/tcp open domain 70/tcp closed gopher 80/tcp open http 113/tcp closed auth 31337/tcp closed Elite Nmap done: 1 IP address (1 host up) scanned in 10.00 seconds Rob-- Christian Savalas Marina Pointe Tech Support 13600 Marina Pointe Drive Marina Del Rey, CA 90292 +1 (310) 343-2000 (cell)-- Christian Savalas Marina Pointe Tech Support 13600 Marina Pointe Drive Marina Del Rey, CA 90292 +1 (310) 343-2000 (cell) _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/-- Christian Savalas Marina Pointe Tech Support 13600 Marina Pointe Drive Marina Del Rey, CA 90292 +1 (310) 343-2000 (cell) _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
-- Christian Savalas Marina Pointe Tech Support 13600 Marina Pointe Drive Marina Del Rey, CA 90292 +1 (310) 343-2000 (cell) _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Windows 7 Christian Savalas (Feb 04)
- Re: Windows 7 Rob Nicholls (Feb 04)
- Message not available
- Re: Windows 7 Christian Savalas (Feb 04)
- Message not available
- Message not available
- Message not available
- Re: Windows 7 Christian Savalas (Feb 04)
- RE: Windows 7 Rob Nicholls (Feb 04)
- Re: Windows 7 Christian Savalas (Feb 04)
- RE: Windows 7 Rob Nicholls (Feb 04)
- Re: Windows 7 Christian Savalas (Feb 04)
- Re: Windows 7 Christian Savalas (Feb 04)
- RE: Windows 7 Rob Nicholls (Feb 04)
- Re: Windows 7 David Fifield (Feb 09)
- Re: Windows 7 Christian Savalas (Feb 10)
- Re: Windows 7 David Fifield (Feb 10)
- Re: Windows 7 Christian Savalas (Feb 10)
- Re: Windows 7 David Fifield (Feb 10)
- Re: Windows 7 Christian Savalas (Feb 10)
- Re: Windows 7 Rob Nicholls (Feb 04)
- Re: Windows 7 David Fifield (Feb 10)
- Re: Windows 7 Christian Savalas (Feb 11)
- Re: Windows 7 Christian Savalas (Feb 11)
- Re: Windows 7 David Fifield (Feb 11)