https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6645
Summary: Patch to add support for Windows Friendly Interface
Names
Product: Wireshark
Version: SVN
Platform: x86
OS/Version: Windows 7
Status: NEW
Severity: Enhancement
Priority: Medium
Component: Wireshark
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: wireshark@xxxxxxxxx
Created an attachment (id=7524)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=7524)
wireshark_windows_interface_friendly_names.patch
Build Information:
Any Windows Wireshark 1.7.x
--
Attached is a code submission that adds to Windows versions support for
Interface Friendly Names.
The bulk of the code is within capture_win_ifnames.* which defines two function
prototypes for external use.
1. const char *get_windows_interface_friendlyname(const char*
interface_devicename, gboolean return_devicename_if_unfound);
2. const char *get_windows_interface_devicename(const char*
interface_friendlyname_in_utf8, gboolean return_friendlyname_if_unfound);
Where a devicename is in the format
'\Device\NPF_{11111111-2222-3333-4444-555555555555}'
And a friendly name is of the style 'Local Area Connection'.
The friendlynames are processed in UTF8 - this has been tested by renaming some
of my OS interfaces to include characters from other languages. The unicode
characters successfully render in a command prompt (codepage set to 65001 +
lucid console font), Cygwin bash prompt and in the Wireshark GUI.
capture_win_ifnames.c includes the windows IP helper library (IPHLPAPI.lib)
using a pragma library include - unsure if this is considered bad form in the
wireshark world, feel free to change it.
Internally capture_win_ifnames.c stores the naming information in two hash
tables - for efficient lookups in either direction. These tables are
initialised and populated when one of the lookup functions are first used -
minimising code changes to other places in the source.
The lookup functions return 'const char *' strings. The if_info_new()
prototype and implementation has been changed to process 'const char *' input
(instead of 'char *'), this has no impact, as if_info_new() only g_strdup'd the
input.
No changes were required to the wireshark gui to benefit from the underlying
changes due to how it calls dumpcap to enumerate the interfaces etc - that
isn't to say that some of the screens in the wireshark gui wouldn't benefit
from being further refined to take advantage of the friendly name interface
details (i.e. do we need to show the devicename so prominently now?).
Dumpcap has had a few tweaks to take advantage of these new functions in the
following ways:
1. The "dumpcap -D" outputs the friendly names instead of the device names.
2. You can specify a friendly name as an interface - e.g. "dumpcap -i 'Local
Area Connection'" works - support for interface number and \Device\NPF_{GUID}
is still works.
3. The "Capturing on" text now shows the friendly name instead of the
devicename.
4. The name is quoted in single quotes.
5. stderr is flushed just before starting the capture loop.
Tshark has had two tweaks:
1. single quotes around the friendly interface name in the "Capturing on" text
- to be consistent with dumpcap.
2. stderr is flushed so the interface is immediately reported before waiting
for packets.
I have spent a reasonable amount of time testing the code to ensure the UTF8 is
working correctly. It all looks good to me on Windows 7 x64 - 32bit compile
though. An initial "concept hack" of the code was tested on WinXp and worked
well.
This is my first submission, and there may be places within the wireshark
ecosystem I am unaware of that that patch could impact, so it would be good if
some who know the wireshark codebase well gives the change some thought.
Hopefully the change can be included pretty quickly, even backporting it to the
1.6 series would be valuable to people if a new release is a long way off. I
actually wrote the above change due to getting frustrated having to depend on
IP address to identify 4 interfaces each with a device description of
"Microsoft".
Thanks,
- Mike
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
