----- Original Message ----- From: "Guy Harris" <[EMAIL PROTECTED]> To: "Developer support list for Wireshark" <[email protected]> Sent: Tuesday, September 09, 2008 4:49 PM Subject: Re: [Wireshark-dev] Problem with Intel® Wireless WiFi Link 4965AGN card
> > On Sep 9, 2008, at 3:24 PM, Gianluca Varenni wrote: > >> Short story: the wireless adapter is probably one of the two >> "Microsoft" >> ones. > > As opposed to the "MS Tunnel Interface Driver"; *that* name goes back > to at least 2005: > > http://thud.ethereal.com/lists/ethereal-users/200511/msg00119.html > > i.e., long before Vista and the native Wi-Fi stuff. Google also found > > http://www.pcreview.co.uk/forums/thread-223683.php > > from which I infer that the "MS Tunnel Interface" might be for 6to4: > > http://en.wikipedia.org/wiki/6to4 > > and/or Teredo: > > http://en.wikipedia.org/wiki/Teredo_tunneling > > and/or "Automatic" tunnelling: > > http://msdn.microsoft.com/en-us/library/ms737544(VS.85).aspx > > which all are for various forms of tunneling IPv6 through non-IPv6- > capable equipment/networks. > > I.e., the "MS Tunnel Interface Driver" might have nothing to do with > Wi-Fi, and might appear on, for example, Ethernet-only machines. > >> Long story: starting from Vista, wireless drivers can be old style >> (NDIS >> 5.x) working exactly like in Windows 2000/XP, or native Wifi drivers >> (NDIS6). In this case the driver is lightweight and delivers 802.11 >> frames >> to an intermediate driver (developed by MS) that converts 802.11 >> frames into >> cooked 802.3 frames that can be managed by the upper protocols like >> the >> TCP/IP stack. This intermediate driver is also responsible for >> managing >> association/disassociation, BSSID scans and such. And this >> intermediate >> driver is also responsible for filtering the requests coming from >> the upper >> protocols (like WinPcap) for the underlying device description, and >> always >> returning "Microsoft" instead of e.g. "Intel Wireless 4965 Adapter". >> >> I haven't looked if there is a possible workaround to the problem, >> yet. > > The problem being that you can't get the name of the adapter, so you > just have these two mysterious "Microsoft" adapters, one or more of > which might support capturing on Wi-Fi networks (possibly even in > promiscuous mode), and the names don't let the user know that they > correspond to the wireless adapter? In the way that we obtain the wireless adapters descriptions, yes. I have no clear idea why the Microsoft intermediate driver returns "Microsoft" instead of forwarding the request down to the miniport driver, my only guess is that the IM driver could possibly support adapter aggregation/virtual adapters, hence you cannot return the description of the physical adapter at all times. But I would expect that it returns the normal adapter description when the IM driver acts as a 1:1 filter (i.e. in the normal case). This morning I will send an e-mail to some mailing lists, and I see if I have some insight on it. As to solutions regarding the problem, I think it's either possible to use WMI to get the right description, or eventually use the connection names given by Windows, like "Wireless Network Connection". Have a nice day GV > _______________________________________________ > Wireshark-dev mailing list > [email protected] > https://wireshark.org/mailman/listinfo/wireshark-dev _______________________________________________ Wireshark-dev mailing list [email protected] https://wireshark.org/mailman/listinfo/wireshark-dev
