Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: Windows 7
From: Christian Savalas <csavalas () gmail com>
Date: Fri, 11 Feb 2011 00:27:11 -0800


This isn't directly related, but this programmer seems to be having
difficulty with the virtual wifi adapter as well, only remedied by
disabling it manually...

On Fri, Feb 11, 2011 at 12:20 AM, Christian Savalas <csavalas () gmail com> wrote:
Would this cause the same problem on other Windows 7 machines with the
default virtual wireless adapter enabled?


On Thu, Feb 10, 2011 at 9:34 PM, David Fifield <david () bamsoftware com> wrote:
On Thu, Feb 10, 2011 at 02:19:03AM -0800, Christian Savalas wrote:
I attached four files. Two of the files (scanwithfix and
iflistwithfix) are results of iflist and a scan with the fix that Rob
helped me figure out. The other two are the results with both adapters
enabled. Hope it helps, and let me know if I can assist further.

On Wed, Feb 9, 2011 at 10:39 PM, David Fifield <david () bamsoftware com> wrote:
On Fri, Feb 04, 2011 at 04:05:59PM -0800, Christian Savalas wrote:
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!

Please try this test release:


I don't think this will solve the problem but it will give us some more
information. Try running both an --iflist and a port scan over your
wireless interface. Send in the --iflist results like before.

Here's what's going on:

intf_get_pcap_devname: enter; "eth13"
intf_get_pcap_devname: descr: "Broadcom Virtual Wireless Adapter-QoS Packet Scheduler-0000"
intf_get_pcap_devname: MAC: F0:7B:CB:8F:71:B7
intf_get_pcap_devname: iter 00FD49D8 "\Device\NPF_{AEC749F8-57B4-4542-AEF6-30539FC9FC87}"
intf_get_pcap_devname: iter MAC: F0:7B:CB:8F:71:B7
intf_get_pcap_devname: selected 00000000 -> 00FD49D8
intf_get_pcap_devname: iter descr "Broadcom Virtual Wireless Adapter"
intf_get_pcap_devname: close_adapter because descr wcscmp failed
intf_get_pcap_devname: close_adapter
intf_get_pcap_devname: iter 00FD4918 "\Device\NPF_{EED21227-E2CE-4EFF-A995-9C4110FF08D1}"
intf_get_pcap_devname: iter MAC: F0:7B:CB:8F:71:B7
intf_get_pcap_devname: selected remains 00FD49D8
intf_get_pcap_devname: close_adapter because PacketRequest(OID_GEN_FRIENDLY_NAME) failed: code 1 "Incorrect 
function. "
intf_get_pcap_devname: close_adapter

libdnet is applying two tests to match the name "eth13" to an NPF device
name. The first is a MAC address comparison, and the second is a
comparison of the interface "friendly name". If any interface matches
both of those, it will be selected, otherwise the first one that matches
the MAC address only will win. The virtual Broadcom device has the same
MAC as the physical device, F0:7B:CB:8F:71:B7, and it comes first in the
interface list so it has preference. What would normally make things
work is the "friendly name" of the physical device, but here it's not
being read for some reason ("Incorrect function"). eth13 ends up getting
matched with the incorrece \Device\NPF_{AEC...} instead of

I don't know offhand what to do about this. One potential solution is to
rewrite libdnet's code so that it gets its list of interfaces from
WinPcap instead of through the MIB and GetIfTable. That's a pretty
significant change though, with a lot of potential ramifications. In
your case, we've seen that libdnet finds like 19 Ethernet devices
(mostly tunnels or variations on a few physical devices), while WinPcap
finds only five total. I think it's worth trying, though it might break
things for other people.

David Fifield

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
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]