Nmap Development mailing list archives

Previous By Date Next
Previous By Thread Next

Re: Windows 7

From: Christian Savalas <csavalas () gmail com>
Date: Fri, 4 Feb 2011 16:20:54 -0800
Last thing! Out of curiousity, I tried running "nmap scanme.nmap.org"
and "nmap -e eth16 scanme.nmap.org" on both of the aforementioned
debug releases, with identical output. The output of debug1 is about
600 lines, so I've attached it as a text file. The output of debug2 is
below:

Starting Nmap 5.30BETA1-debug2 ( http://nmap.org ) at 2011-02-04 16:08
Pacific Standard Time
intf_get_pcap_devname: enter; "eth16"
intf_get_pcap_devname: descr: "DW1520 Wireless-N WLAN Half-Mini Card"
intf_get_pcap_devname: MAC: F0:7B:CB:8F:71:B7
eth_get_pcap_devname: iter "\Device\NPF_{47C778F5-8BAC-4C1C-A7BD-7CB05BBAE58B}"
intf_get_pcap_devname: iter MAC: 00:26:B9:CF:50:5F
intf_get_pcap_devname: close_adapter
eth_get_pcap_devname: iter "\Device\NPF_{AEC749F8-57B4-4542-AEF6-30539FC9FC87}"
intf_get_pcap_devname: iter MAC: F0:7B:CB:8F:71:B7
intf_get_pcap_devname: iter descr "Broadcom Virtual Wireless Adapter"
intf_get_pcap_devname: close_adapter
eth_get_pcap_devname: iter "\Device\NPF_{3992A8D8-5A06-4013-A821-9FA231E4A3C6}"
intf_get_pcap_devname: iter MAC: 00:50:56:C0:00:08
intf_get_pcap_devname: close_adapter
eth_get_pcap_devname: iter "\Device\NPF_{EED21227-E2CE-4EFF-A995-9C4110FF08D1}"
intf_get_pcap_devname: iter MAC: F0:7B:CB:8F:71:B7
intf_get_pcap_devname: close_adapter
eth_get_pcap_devname: iter "\Device\NPF_{BEC88542-20C3-4EA2-974F-A6823B0F0C5C}"
intf_get_pcap_devname: iter MAC: 00:50:56:C0:00:01
intf_get_pcap_devname: close_adapter
dnet: Failed to open device eth16
QUITTING!


I'm really curious now, especially considering that the card can be
utilized just fine in Wireshark, with the same installation of
Winpcap.

Cheers Rob,

Christo

On Fri, Feb 4, 2011 at 4:05 PM, Christian Savalas <csavalas () gmail com> wrote:

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 something

like:


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.
The

WinPcap

FAQ states:

Wireless adapters: these adapters may present problems, because they
are

not

properly 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
this

uses

the 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 use

as

it 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) and

a

Connect 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't

need

to 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 a

message!

After

I hit send, I realized I hadn't tried it on a wired ethernet
connection

for

two 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 as

well

use Superscanner for that ;)

I should have mentioned in my first message that all other Windows
net

tools

like 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.sys

style -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,

but

then 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 Pacific

Standard

Time

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 Pacific

Standard

Time

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 command

prompt.


Lastly, I have tried capturing packets with Wireshark while running
the

scan

with AND without -Pn, but I am by no means an expert on packet analysing.

I

attached the two logs for you, just in case it would help. From my

untrained

eye, 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.org


Pinging 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 (and

routes).

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 eth7


Starting 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)





-- 
Christian Savalas
Marina Pointe Tech Support
13600 Marina Pointe Drive
Marina Del Rey, CA 90292
+1 (310) 343-2000 (cell)

Attachment: NmapDebug1.txt
Description: 

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

Current thread: