Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 6645] Patch to add support for Friendly Names for interfaces on Windows

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6645

--- Comment #15 from Guy Harris <guy@xxxxxxxxxxxx> 2012-09-25 12:20:29 PDT ---
(In reply to comment #14)
> Looking at the MSDN link you provided, I think Microsoft have used the term
> "friendly name" in two ways.

Yup.

> 1. The NDIS OID_GEN_FRIENDLY_NAME method is about the "friendly name" for the
> Miniport driver - the examples in the MSDN article match what winpcap already
> gives us as the description.

On my XP machine, the OID fetch fails; on my Win7 machine, it succeeds, but
just returns a UTF-16 version of the vendor description.

> 2. AdapterAddresses returned by GetAdaptersAddresses() provides access to the
> friendlyname for the adapter which matches the interface name in
> "start->run->ncpa.cpl" - e.g. "Local Area Connection".
> 
> MSDN documentation for more recent API functions such as
> ConvertInterfaceLuidToAlias() appear to be refering to "Local Area Connection"
> as the interface alias name.
> 
> The wireshark gui should be able to display both the interface alias name and
> the vendor description as available in places such as the Interface Details
> dialog.
> 
> Assuming there is agreement that it should be able to display both, any
> thoughts on/refinement to the following approach:
> 0. Retrieve the interface alias names with the method I outlined in comment 7.
> 1. Extend the if_info_t type to include char * interface_alias; in addition to
> name and description.

I'd call that "friendly_name", reflecting what it's intended to be rather than
what some Windows APIs call it.

> Where description = vendor description/miniport driver
> name as returned by winpcap.
> 2. Extend dumpcap so it returns both the interface alias and vendor description 
> when programmatically queried by the wireshark gui for the interface list.

Yes.  On Windows, return both, if available; on UN*X, return the description,
as returned by libpcap, as the friendly name (in those cases where it's
returned on UN*X, it'll be a friendly name, rather than a vendor description).

> 3. Change dumpcap so it uses alias in place of description if an alias is
> known.  areas this would apply to include commands such as "dumpcap -D" and
> "dumpcap -i"

Yes, or perhaps show both.

> 4. Change dumpcap so if an alias is known, it will use that as the basis for
> the autogenerated filename in place of the GUID based filename.

Yes (even on UN*X).

> 5. Extend the GUI/interface details to show the alias and vendor description in
> the Interface Details dialog

Yes.

> 6. Change the gui to use the interface alias in place of the vendor description
> if it is available (best approach for this is something to discuss based on a
> review of the existing code)

Yes.

> 7. Possibly change the code to no longer show the GUID on the front page of the
> gui when the alias is known - wireshark should down play the guid in user
> interfaces when it isn't needed to uniquely identify an interface.  The GUID
> remains in the gui in places such as interface detail.

Network Monitor doesn't seem to display the GUID at all, so de-emphasizing it
in the UI where possible is probably a good idea.

> 8. Further options will open up such as recording the interface alias name in
> the pcapng capture data.

pcap-NG should add an if_friendly_name option, with if_description reserved for
a vendor description.

> All of the above would only have an impact on the behaviour of windows builds
> but OS specific code could be minimised through the simple extension of the
> if_info_t type.
> 
> Keeping the initial scope tight, I am thinking numbers 0 through 3 are an
> initial patch we can build on.
> 
> Thoughts?
> 
> - Mike

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