Re: Windows 7

[Christian Savalas <csavalas () gmail com>]

Would this cause the same problem on other Windows 7 machines with the
default virtual wireless adapter enabled?

Christo

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:
> > >
> > > http://nmap.org/dist/nmap-5.51SVN-debug4-win32.zip
> > >
> > > 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
> \Device\NPF_{EED...}.
>
> 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)
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/