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 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
Adding to proposed list. This will break the "pseudo-tabular" style of the output.
Created attachment 124482 [details] net-tools-1.60-nestat_stop_trim.patch Proposed patch
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. http://rhn.redhat.com/errata/RHBA-2006-0360.html