Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 614931 - netstat -a does not report non listening sockets
netstat -a does not report non listening sockets
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: net-tools (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Jiri Popelka
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-15 11:11 EDT by Karel Volný
Modified: 2011-05-19 10:03 EDT (History)
6 users (show)

See Also:
Fixed In Version: net-tools-1.60-103.el6
Doc Type: Bug Fix
Doc Text:
Prior to this update, the manual page for the netstat utility stated that running the utility with the "-a" (or "--all") command line option allows a user to list both listening and non-listening sockets. Since this description was rather vague, this update extends the manual page to provide a clear explanation of which sockets are classified as non-listening.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-19 10:03:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0690 normal SHIPPED_LIVE net-tools bug fix update 2011-05-18 14:10:22 EDT

  None (edit)
Description Karel Volný 2010-07-15 11:11:29 EDT
Description of problem:
Reading netstat manpage:

-a, --all
       Show both listening and non-listening sockets.  With the --interfaces option, show interfaces that are not marked

But using portreserve to claim some tcp port, it does not show in the list.

Version-Release number of selected component (if applicable):
net-tools-1.60-102.el6

How reproducible:
always

Steps to Reproduce:
1. yum install net-tools portreserve
2. echo 12345 > /etc/portreserve/test
3. service portreserve start
4. netstat -n -a | grep 12345

Actual results:
udp        0      0 0.0.0.0:12345               0.0.0.0:*

Expected results:
tcp        0      0 0.0.0.0:12345               0.0.0.0:*
udp        0      0 0.0.0.0:12345               0.0.0.0:*

Additional info:
CCing twaugh - from what he says, portreserve really binds the port, just does not listen to it, and how do I understand the docs, the "-a" option should ensure that it gets listed anyways.
Comment 2 RHEL Product and Program Management 2010-07-15 11:38:43 EDT
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Comment 3 Jiri Popelka 2010-07-29 10:04:02 EDT
ss command shows the same.

# ss -u -a -n | grep 12345
UNCONN     0      0                         *:12345                    *:*

# ss -t -a -n | grep 12345
(shows nothing)


Additional info:
man 8 ss

DESCRIPTION
       ss is used to dump socket statistics. It allows showing information similar to netstat.  It can display more TCP and state informations than other tools.

OPTIONS
       -n, --numeric
              Do now try to resolve service names.
       -a, --all
              Display all sockets.
       -t, --tcp
              Display only TCP sockets.
       -u, --udp
              Display only UDP sockets.
Comment 4 Jiri Popelka 2010-10-11 13:02:51 EDT
(In reply to comment #0)
> Steps to Reproduce:
> 1. yum install net-tools portreserve
> 2. echo 12345 > /etc/portreserve/test
> 3. service portreserve start
> 4. netstat -n -a | grep 12345
netstat uses /proc/net/* to get the informations about active sockets.
12345 is 3039 in hexadecimal., When we try to 
'grep 3039 /proc/net/*' we find 00000000:3039 only in /proc/net/udp.

> portreserve really binds the port, just does not listen to it
When you create TCP connection you
either call bind()+listen() in case of server
or connect() in case of client.
When you have TCP socket and call bind() but not listen()
then it's not a valid (it's neither listening server nor established connection)
TCP connection and therefore it's not in /proc/net/tcp
and netstat doesn't show it.

It's in /proc/net/udp because there's no need to call listen() on UDP socket.

> and how do I understand the docs, the "-a" option should ensure that it gets listed anyways.
Yes but only if it's valid "server" or "established" (I use the netstat terminology).
# netstat | grep Active
Active Internet connections (w/o servers)
Active UNIX domain sockets (w/o servers)
# netstat -l | grep Active
Active Internet connections (only servers)
Active UNIX domain sockets (only servers)
# netstat -a | grep Active
Active Internet connections (servers and established)
Active UNIX domain sockets (servers and established)

Maybe we could improve the '-a' option documentation in man page.

- Show both listening and non-listening sockets.
+ Show both listening and non-listening (for TCP this means established connections) sockets.

(Your english is definitely better then my so if you have other idea how to improve the documentation, it's welcomed).
Comment 10 Jaromir Hradilek 2011-04-04 11:12:13 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Prior to this update, the manual page for the netstat utility stated that running the utility with the "-a" (or "--all") command line option allows a user to list both listening and non-listening sockets. Since this description was rather vague, this update extends the manual page to provide a clear explanation of which sockets are classified as non-listening.
Comment 11 errata-xmlrpc 2011-05-19 10:03:14 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 therefore 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-2011-0690.html

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