Wireshark-bugs: [Wireshark-bugs] [Bug 6645] Patch to add support for Windows Friendly Interface
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6645
--- Comment #7 from Mike Garratt <wireshark@xxxxxxxxx> 2012-09-24 19:12:38 PDT ---
The original code was the only way I could find how to retrieve the information
using published APIs available to Windows XP and higher.
Your point regarding caching is valid even if a pretty rare corner case. I
don't like the delay, and think we can do something better.
I did some investigation into how ipconfig retrieves the interface friendly
names - on XP it appears to be using the following undocumented functions:
HrLanConnectionNameFromGuidOrPath() in netman.dll and falling back to
NhGetInterfaceNameFromGuid() in iphlpapi.dll (the DLL that hosts the slow
published function GetAdaptersAddresses() used by the original patches).
* HrLanConnectionNameFromGuidOrPath() is not a robust option, as netman.dll is
64bit on 64bit OS's, so a 32bit wireshark on a 64bit OS wouldn't be able to use
it.
* I have managed to get NhGetInterfaceNameFromGuid() and
NhGetGuidFromInterfaceName() working on both XP 32bit and Win7 x64.
For Vista+ and higher, I have got the following working
CLSIDFromString()->ConvertInterfaceGuidToLuid()->ConvertInterfaceLuidToAlias()
(all published api functions).
In short I think the best approach is to:
* Check the OS at run time,
= if Vista or higher leverage the published ConvertInterface* functions.
= if XP use the undocumented NhGet* functions.
This would allow the original patch to be simplified - no need to take the
~1second hit preloading the interface lookup hashtables.
Any objections ahead of time to using an unpublished API function on XP?
Any other thoughts on such an approach?
- Mike
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
