This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 176465 - IPv6: 'netstat -A inet6 -n' truncates most global IPv6 addresses
IPv6: 'netstat -A inet6 -n' truncates most global IPv6 addresses
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: net-tools (Show other bugs)
4.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Radek Vokal
Ben Levenson
:
Depends On:
Blocks: 181409
  Show dependency treegraph
 
Reported: 2005-12-22 23:22 EST by Steve Bonneville
Modified: 2011-12-06 14:01 EST (History)
0 users

See Also:
Fixed In Version: RHBA-2006-0360
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-10 17:17:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
net-tools-1.60-nestat_stop_trim.patch (842 bytes, patch)
2006-02-10 04:58 EST, Radek Vokal
no flags Details | Diff

  None (edit)
Description Steve Bonneville 2005-12-22 23:22:55 EST
Description of problem:

The /bin/netstat command when used to view active connections in numeric mode
limits the 'Local Address' and 'Foreign Address' fields to no more than 27
characters.  The port number used for each end of the connection overwrites the
name/IP shown in the field, further limiting the maximum length of the name/IP
address which can be displayed.

This makes the 'netstat -A inet6 -n' command nearly useless, since the
non-network part of a global-scope IPv6 address is almost always lost:

[user@host ~]$ netstat -A inet6 -n
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State
tcp        0      0 ::1:33926                   2002:4819:8549:1234:20d::22
ESTABLISHED
tcp        0      0 2002:4819:8549:1234:2:33924 2002:4819:8549:1234:20d::22   
TIME_WAIT
tcp        0      0 2002:4819:8549:1234:20d::22 ::1:33926                  
ESTABLISHED

These fields should expand as necessary to allow at least 45 characters each (32
nibbles + 7 colons for a maximal IPv6 address plus 6 for a colon and five digit
port number).  Otherwise, this bug can make it impossible to distinguish two
IPv6 addresses on the same subnet in the output of netstat.  In the worst-case
scenario, an address containing an early :: sequence could get truncated into a
different string that could be misinterpreted as a valid, if shorter, IPv6 address.

This same fixed-field bug also affects names, of course; ideally, it'd be nice
if the fields could expand on demand to a maximum width of 255 characters for
the maximal length of a fully-qualified DNS domain name.  But if the -n option
displayed unambiguous results (as it does for IPv4 addresses), hostname
truncation might be considered less critical.

Version-Release number of selected component (if applicable):
net-tools-1.60-37.EL4.6
Comment 1 Radek Vokal 2006-02-10 04:32:01 EST
Adding to proposed list. This will break the "pseudo-tabular" style of the output. 
Comment 2 Radek Vokal 2006-02-10 04:58:45 EST
Created attachment 124482 [details]
net-tools-1.60-nestat_stop_trim.patch

Proposed patch
Comment 3 Steve Bonneville 2006-02-19 23:41:13 EST
A similar change was made to /bin/ls to support user/group names longer than
eight characters some time ago that was designed not to break the pseudo-tabular
output of ls.  Instead, if a large-sized username or groupname field is needed
it widens that column of the output throughout.  I haven't looked at how that
was implemented, though, and I expect it's a more complicated solution.
Comment 4 Radek Vokal 2006-04-10 03:09:54 EDT
Ok, should we agree on some solution? My personal favourite one is new option.
I've introduced -T (--trim) option in rawhide net-tools, which stops the
trimming on demand. Than there is my patch in comment #2 , quick fix which is
rather ugly one and than you propose the two line output, which I think is nice,
but not parseable. So are there any complains about adding new option?
Comment 5 Bob Johnson 2006-04-11 11:49:45 EDT
This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 4.4 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 4.4 release.
Comment 6 Steve Bonneville 2006-04-11 12:19:45 EDT
I'm not sure what you mean by my proposal of "two-line output".  All I was
proposing was that we'd do something like /bin/ls does for the -l option; for
example, compare the size of the username field for 'ls -l /etc' (6 chars on
my RHEL4U3 system, longest username is 'amanda') with 'ls -l /usr/bin' (4 chars
on my RHEL4U3 system, longest username is 'root').

Yes, we lose the fixed-field-size assumption, which is unfortunate but
survivable.  Yes, the coding is probably more complicated, since we need to know
the size of the longest string before we start displaying output.  But parsing
this output isn't horrific or that different from what already works, and this
has some advantages:

  1) We can still parse fields by looking for whitespace; awk is good at this,
for one example.
  2) We still know that one line is one piece of information, since we don't
have a newline until the end of the row; really long lines display wrapped on
narrow terminals.  This already happens, though, since the default width seems
to require at least 87 characters, even without netstat -e.
  3) We could set a minimum field size which is the same as the current fixed
size for each column, and only expand as necessary.
  4) We can still have an option to enable/disable the trimming/expanding
behavior based on whatever seems to make the most sense.
  5) We get to keep something that looks like the current tabular output, where
the columns stay lined up even with trimming stopped.

I do like the idea of an option to control this behavior, so we don't break
existing scripts that may make fixed-field assumptions.

On the other hand, I'd just be happy to see some way for us to display this
information properly, even if it isn't the most elegant solution or even a final
solution. :)  Thanks for your work on this.
Comment 7 Radek Vokal 2006-04-18 08:12:05 EDT
Ok, I will stick with new option (--trim) which just stops trimming, but doesn't
present the data in tabular output. Your solution would be nicer but .. maybe
I'll do this for FC6 :) 
Comment 11 Red Hat Bugzilla 2006-08-10 17:17:59 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0360.html

Note You need to log in before you can comment on or make changes to this bug.