Wireshark-bugs: [Wireshark-bugs] [Bug 6645] Patch to add support for Windows Friendly Interface
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Mon, 24 Sep 2012 22:18:02 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6645

--- Comment #9 from Guy Harris <guy@xxxxxxxxxxxx> 2012-09-24 22:18:00 PDT ---
On the general note of "why do some devices have the singularly useless name
"Microsoft"?", which is annoying me on general principles:

It looks as if WinPcap gets the list of adapters from
HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}
in the Registry.  Looking under there on my Windows 7 virtual machine, I'm
seeing

    0000: DriverDesc "WAN Miniport (SSTP)", ProviderName "Microsoft"
    0001: DriverDesc "WAN Miniport (IKEv2)", ProviderName "Microsoft"
    0003, 0004: more tunnely "WAN Miniport" things;
    0005: DriverDesc "WAN Miniport (Network Monitor)", ProviderName "Microsoft"
    0006: DriverDesc "WAN Miniport (IPv6)", ProviderName "Microsoft"
    0007: DriverDesc "Intel(R) PRO/1000 MT Network Connection", ProviderName
"Microsoft"
    0008: DriverDesc "WAN Miniport (IP)", ProviderName "Microsoft"
    0009: DriverDesc "Microsoft ISATAP Adapter", ProviderName "Microsoft"
    0010: DriverDesc "RAS Async Adapter", ProviderName "Microsoft"
    0011: DriverDesc "Microsoft Teredo Tunneling Adapter", ProviderName
"Microsoft"

I guess the ProviderName is "who provides the *driver*", not "who provides the
*adapter*", although the adapter in question is implemented in a pile of code
in some file under /Applications/VMware Fusion.app, as well as the OS X BPF
code.

The OID OID_GEN_VENDOR_DESCRIPTION:

   
http://msdn.microsoft.com/en-us/library/windows/hardware/ff569649(v=vs.85).aspx

appears to be what WinPcap uses to get the description; it doesn't dig them
directly out of the Registry.  Maybe it's somehow returning the ProviderName
rather than the DriverDesc for some adapters; this might be a driver botch.

If you can, could you fire up the Registry Editor and open up
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}?
 Then, for each of the 4-digit numbers under that key:

    open it up;

    click on the "Linkage" item under it;

    see whether the "Export" item in the right-hand pane contains
498AC5A6-38EE-46FE-9213-3C072CA0B447 (it might be
\Device\{498AC5A6-38EE-46FE-9213-3C072CA0B447}, for example);

    if it does, click on the 4-digit number above "Linkage" and see whether the
right-hand pane has a DriverDesc item and/or a ProviderName item and indicate
what both of them are.

I wonder whether it has no DriverDesc - if not, perhaps NDIS supplies the
ProviderName as an attempt to "fake" a vendor description - or whether it has
one but it's something stupid like "Microsoft"?

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.