Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 5615] New: less filtering of ipv6 addresses in local host

Date: Mon, 24 Jan 2011 21:07:49 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5615

           Summary: less filtering of ipv6 addresses in local host file
           Product: Wireshark
           Version: 1.2.7
          Platform: x86-64
        OS/Version: Ubuntu
            Status: NEW
          Severity: Enhancement
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: sffroelich@xxxxxxxxx


Build Information:
wireshark 1.2.7

Copyright 1998-2010 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled with GTK+ 2.20.0, with GLib 2.24.0, with libpcap 1.0.0, with libz
1.2.3.3, with POSIX capabilities (Linux), with libpcre 7.8, with SMI 0.4.8,
with
c-ares 1.7.0, with Lua 5.1, with GnuTLS 2.8.5, with Gcrypt 1.4.4, with MIT
Kerberos, with GeoIP, with PortAudio V19-devel (built Feb 18 2010 23:31:11),
without AirPcap.

Running on Linux 2.6.32-26-generic, with libpcap version 1.0.0, GnuTLS 2.8.5,
Gcrypt 1.4.4.

Built using gcc 4.4.3.
--
i would like to request the removal of the name-resolving function's filtering
of IPv6 addresses - read from an optional local hosts file - that today filters
out link-scope and multicast addresses. this will allow the Wireshark
investigator a convenient way to identify the sender/destination host of
certain captured packets in Wireshark's presentation screen. 

The current filtering has been preserved, for over a decade, by function
get_hostname6(), concerned about the ambiguity (of link-scoped addresses
without interface identifiers) or impossibility (of multicast addresses used as
source address. while these are legitimate concerns in a routing environment,
it is overly restrictive as applied to a diagnostic or troubleshooting tool,
such as Wireshark - the presented packet has already been captured, and the
investigator is concerned primarily with identifying the authoring machine -
more than which interface on that machine it came from.

the same 'freedom' should be allowed for IPv4 - the host file used by Wireshark
should allow free-form, friendly strings to be used (as replacement labels) -
replacing the raw layer-3 IP address in the Wireshark presentation.

such an enhancement will help speed the understanding of the what the
investigator is looking at, when troubleshooting packets.

Wireshark is already the most useful in my arsenal - This enhancement will make
it even better.

Thanks for your consideration.   - steve@xxxxxx

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