Wireshark-dev: Re: [Wireshark-dev] Problem with Intel® Wireless WiFi Link 4965AGN card
----- Original Message -----
From: "Guy Harris" <guy@xxxxxxxxxxxx>
To: "Developer support list for Wireshark" <wireshark-dev@xxxxxxxxxxxxx>
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
Wireshark-dev@xxxxxxxxxxxxx
https://wireshark.org/mailman/listinfo/wireshark-dev
