Bug 236493 - netstat output is misleading when -W is not used
Summary: netstat output is misleading when -W is not used
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 11.2-RELEASE
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-12 16:51 UTC by Daniel DeLorme
Modified: 2019-03-18 16:53 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel DeLorme 2019-03-12 16:51:17 UTC
I was using netstat to troubleshoot some issues and got the following output:

# netstat -AanL
Current listen queue sizes (qlen/incqlen/maxqlen)
Tcpcb            Proto Listen                           Local Address     
fffff8003b86d410 tcp4  0/0/128                          192.168.255.37.420 
fffff800bddcd000 tcp4  0/0/128                          192.168.255.37.420 
fffff8015eaf1820 tcp4  0/0/128                          *.80               
fffff8004d87d000 tcp4  0/0/10                           127.0.0.1.25       
fffff8004d87d410 tcp4  0/0/128                          *.22               
fffff8004d87d820 tcp6  0/0/128                          *.22               
fffff8004d633000 tcp4  0/0/128                          192.168.255.37.112 

So I wasted hours looking for something on 192.168.255.37:420 when in fact it was just truncated:

# netstat -AanLW
Current listen queue sizes (qlen/incqlen/maxqlen)
Tcpcb            Proto Listen                           Local Address                                
fffff8003b86d410 tcp4  0/0/128                          192.168.255.37.4201                           
fffff800bddcd000 tcp4  0/0/128                          192.168.255.37.4200                           
fffff8015eaf1820 tcp4  0/0/128                          *.80                                          
fffff8004d87d000 tcp4  0/0/10                           127.0.0.1.25                                  
fffff8004d87d410 tcp4  0/0/128                          *.22                                          
fffff8004d87d820 tcp6  0/0/128                          *.22                                          
fffff8004d633000 tcp4  0/0/128                          192.168.255.37.11211                    

I can understand truncating a symbolic name, but truncating the port number like that (without any indication it was truncated) is *very* misleading. Same thing I imagine if you truncate an IP address (4 or 6) in a way that makes it look like the truncated data is a valid IP address.

Please either
a) never truncate numeric addresses and port numbers (-n implies -W)
b) indicate when a field is truncated (ex: 192.168.255.37.11* or 192.168.255*.11211)
Comment 1 Conrad Meyer freebsd_committer 2019-03-12 17:31:24 UTC
Does not seem to reproduce on CURRENT, FWIW.
Comment 2 Daniel DeLorme 2019-03-18 16:26:49 UTC
Oh right, my apologies, I forgot to include basic system info

# uname -imoprsvUK
FreeBSD 11.1-RELEASE-p10 FreeBSD 11.1-RELEASE-p10 #0: Tue May  8 05:21:56 UTC 2018     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64 amd64 GENERIC 1101001 1101001


@Conrad, I'd appreciate if you could paste here the output that does not seem to reproduce.
Comment 3 Conrad Meyer freebsd_committer 2019-03-18 16:41:18 UTC
Not sure what you're looking for as far as "not truncated."  E.g.,

$ netstat -AanL
Current listen queue sizes (qlen/incqlen/maxqlen)
Tcpcb            Proto Listen                           Local Address
fffffXXXXXXXXXXX tcp4  0/0/16                           *.YYYY
fffffXXXXXXXXXXX tcp4  0/0/100                          127.0.0.1.YYY
fffffXXXXXXXXXXX tcp4  0/0/100                          127.0.0.1.YYY
fffffXXXXXXXXXXX tcp4  0/0/128                          127.0.0.1.YYYY

Those YYY port numbers are all intact, not truncated...  If the terminal is too narrow to fit, the lines wrap rather than truncating.

FreeBSD 13.0-CURRENT #52 r343668+
Comment 4 Daniel DeLorme 2019-03-18 16:53:43 UTC
Ah, well yes, those IP+port numbers are not truncated because their total length is <= 18 chars. The problem would only be visible for addresses long enough to be truncated, as in my example.