[screen-devel] [bug #63096] IPV6 utmp entry shorthand address should include least significant bytes

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?63096>

                 Summary: IPV6 utmp entry shorthand address should include
least significant bytes
                 Project: GNU Screen
               Submitter: None
               Submitted: Fri 23 Sep 2022 02:40:53 PM UTC
                Category: Feature Request
                Severity: 3 - Normal
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
                 Release: 4.8.0
         Discussion Lock: Any
           Fixed Release: None
         Planned Release: None
           Work Required: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Fri 23 Sep 2022 02:40:53 PM UTC By: Anonymous
When gnu-screen writes into utmp the IPv6 address of connected ptys, it looks
like:

user     pts/0        Sep 23 07:18 (2602:512a:b522:551e:3f90:1da6:437c:3a49)
user     pts/1        Aug 21 08:42 (2602:S.0)
user     pts/2        Aug 21 08:42 (2602:S.1)
user     pts/4        Sep 16 17:02 (2602:S.2)

when there's IPv6 addresses that can't be reverse resolved.  The prefix 2602::
could mean a LOT of different hosts.  The suggestion is to use the least
significant digits of the IPV6 address (...3a49:S.0), or perhaps
(2602...3a49:S.x) in the utmp entries.

Note that the shorthand was probably meant for chopping up fully resolved
names and not unresolvable IPV6 numeric IP addresses.  The current handling,
if it effectively were used for IPv4, would show as (127:S.0) for 127.0.0.1
which again is a lot of hosts, and would venture that using even (127...1:S.0)
or (...1:S.0) would be more useful to people debugging connections, where one
could look in the kernel IP connection tables to find the remote address.







    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63096>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/