Red Hat Bugzilla – Bug 176465
IPv6: 'netstat -A inet6 -n' truncates most global IPv6 addresses
Last modified: 2011-12-06 14:01:17 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
tcp 0 0 2002:4819:8549:1234:2:33924 2002:4819:8549:1234:20d::22
tcp 0 0 2002:4819:8549:1234:20d::22 ::1:33926
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):
Adding to proposed list. This will break the "pseudo-tabular" style of the output.
Created attachment 124482 [details]
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.
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?
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.
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.
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 :)
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.