netstat -s prints out a lot of very detailed protocol statistics like number of TCP reset messages received or number of ICMP "echo request" messages sent or number of packets dropped because of a missing route.

When in Linux netstat is considered deprecated at nowadays, then is there an alternative?

Statistics provided by ss -s are superficial compared to the ones provided by netstat.

  • tcpdump seems to fill the same need – Thomas Dickey Jan 30 '16 at 13:18
  • 4
    netstat is deprecated. Use ss. – mikeserv Jan 30 '16 at 15:37
  • @ThomasDickey tcpdump allows one to capture live traffic, but does not store statistics in a way netstat -s shows. – Martin Jan 30 '16 at 20:13
  • 1
    Specifying the platform would probably be useful. You may want to examine sysctl output or the contents of various /proc/net/* nodes. – jcaron Feb 9 '16 at 0:01

netstat has indeed been deprecated by many distributions, though it's really much of the "net-tools" package (including ifconfig, route and arp) that has been deprecated in favour of the "iproute2" package. iproute2 has evolved along with the latest Linux networking features, and the traditional utilities have not.

The iproute2 equivalent that you want is the little known nstat, this provides the netstat -s counters, albeit in a slightly different form:

  • raw counter names from /proc are used, each prefixed with its class ("Udp", "Tcp", "TcpExt" etc)

  • netstat's long (and possibly localised) descriptions are not available

  • zero-value counters omitted by default

  • using consistent columnar output with the name and value in the first and second columns

  • third column shows the average over a configurable time window if you have started a background nstat (-d daemon mode), or 0.0 if not

    e.g. nstat prints "UdpInDatagrams NNN" not "Udp: InDatagrams", and not the verbose netstat version of "Udp: NNN packets received".

nstat also assumes you want incremental rather than absolute numbers, so the closest equivalent to netstat -s is /sbin/nstat -asz where the options are -a use absolute counters, -s don't keep history file, -z don't omit zero-value counters.

ss takes over the "socket" parts of netstat, but not its complete function as you have found out. (ss is actually better than netstat in many cases, two specific ones are the ability to use filter expressions and the optional capability to use the tcp_diag and inet_diag Linux kernel modules to access kernel socket data more directly than via /proc.)

Should you need to confirm the mapping for descriptive names, the net-tools source is the definitive reference: http://sourcecodebrowser.com/net-tools/1.60/statistics_8c_source.html

Doug Vitale provides a useful guide for finding the iproute2 equivalents of the older commands (it is unmaintained and slightly incomplete, it omits any reference to nstat which has been part of the iproute2 package since at least 2004 kernel 2.6.x time).

net-tools lives on however, and you should be able to find a package for your distribution (or compile it yourself).

| improve this answer | |

NETSTAT is considered deprecated at nowadays and others programs included in the net-tools like arp, ifconfig, iptunnel, nameif, netstat, and route.

The functionality provided by several of these utilities has been reproduced and improved in the new iproute2 suite, primarily by using its new ip command.

Examples for deprecated commands and their replacements:

  • arpip n (ip neighbor)
  • ifconfigip a (ip addr), ip link, ip -s (ip -stats)
  • iptunnelip tunnel
  • iwconfigiw
  • nameifip link, ifrename
  • netstatss, ip route (for netstat -r), ip -s link (for netstat -i), ip maddr (for netstat -g)

The netstat command reads various /proc files to gather information. However this approach falls weak when there are lots of connections to display. This makes it slower. The ss command gets its information directly from kernel space. The options used with the ss commands are very similar to netstat making it an easy replacement.

Statistics provided by ss are superficial but it is considered the better alternative to netstat


ss | less  # get all connections
ss -t      # get tcp connections not in listen mode (server programs)
ss -u      # get udp connections not in listen mode
ss -x      # get unix socket pipe connections
ss -ta     # get all tcp connections
ss -au     # get all udp connections
ss -nt     # all tcp without host name
ss -ltn    # listening tcp without host resolution
ss -ltp    # listening tcp with PID and name
ss -s      # prints statstics
ss -tn -o  # tcp connection with domain host and show keepalive timer
ss -tl4    # ip4 connections 
| improve this answer | |
  • 4
    This doesn't answer the question, the OP points out correctly that ss -s does not provide data that netstat -s provides. This also contains misinformation: /proc is the kernel interface for this and that's exactly how ss obtains much of the data: strace -e trace=file,read /sbin/ss -s . – mr.spuratic Feb 19 '16 at 17:59
  • 1
    The OP said not the entirely "ss are superficial", but "ss -s are superficial compared to the ones provided by netstat" (means comparing to netstat -s). And it's really the truth: e.g., from ss -s you can know nothing about TCP Retransmissions. – kenichi Dec 20 '18 at 10:41

You may want to check the contents of /proc/net/netstat:

TcpExt: SyncookiesSent SyncookiesRecv SyncookiesFailed EmbryonicRsts PruneCalled RcvPruned OfoPruned OutOfWindowIcmps LockDroppedIcmps ArpFilter TW TWRecycled TWKilled PAWSPassive PAWSActive PAWSEstab DelayedACKs DelayedACKLocked DelayedACKLost ListenOverflows ListenDrops TCPPrequeued TCPDirectCopyFromBacklog TCPDirectCopyFromPrequeue TCPPrequeueDropped TCPHPHits TCPHPHitsToUser TCPPureAcks TCPHPAcks TCPRenoRecovery TCPSackRecovery TCPSACKReneging TCPFACKReorder TCPSACKReorder TCPRenoReorder TCPTSReorder TCPFullUndo TCPPartialUndo TCPDSACKUndo TCPLossUndo TCPLostRetransmit TCPRenoFailures TCPSackFailures TCPLossFailures TCPFastRetrans TCPForwardRetrans TCPSlowStartRetrans TCPTimeouts TCPLossProbes TCPLossProbeRecovery TCPRenoRecoveryFail TCPSackRecoveryFail TCPSchedulerFailed TCPRcvCollapsed TCPDSACKOldSent TCPDSACKOfoSent TCPDSACKRecv TCPDSACKOfoRecv TCPAbortOnData TCPAbortOnClose TCPAbortOnMemory TCPAbortOnTimeout TCPAbortOnLinger TCPAbortFailed TCPMemoryPressures TCPSACKDiscard TCPDSACKIgnoredOld TCPDSACKIgnoredNoUndo TCPSpuriousRTOs TCPMD5NotFound TCPMD5Unexpected TCPSackShifted TCPSackMerged TCPSackShiftFallback TCPBacklogDrop TCPMinTTLDrop TCPDeferAcceptDrop IPReversePathFilter TCPTimeWaitOverflow TCPReqQFullDoCookies TCPReqQFullDrop TCPRetransFail TCPRcvCoalesce TCPOFOQueue TCPOFODrop TCPOFOMerge TCPChallengeACK TCPSYNChallenge TCPFastOpenActive TCPFastOpenPassive TCPFastOpenPassiveFail TCPFastOpenListenOverflow TCPFastOpenCookieReqd TCPSpuriousRtxHostQueues BusyPollRxPackets
TcpExt: 0 0 3310 41566 0 0 0 8 0 0 6402271 0 0 0 0 55 4280514 134510 38423 0 611 15354484 20413302 794718685 0 14094957 6423168 25905597 17269587 4 23681 29 50 20 0 25 43 25 19211 1800 131 0 93 93 25430 4864 18099 1199566 2300620 1280201 0 279 0 0 38507 607 2359841 19 98943 1769 0 5993 0 0 0 3 65 1310588 380 0 0 0 0 613504 190 0 12056356 0 0 0 0 3 735740 43633 0 606 3933 193 0 24 0 0 0 14 0
IpExt: InNoRoutes InTruncatedPkts InMcastPkts OutMcastPkts InBcastPkts OutBcastPkts InOctets OutOctets InMcastOctets OutMcastOctets InBcastOctets OutBcastOctets InCsumErrors InNoECTPkts InECT1Pkts InECT0Pkts InCEPkts
IpExt: 0 0 50492 0 18482301 0 68850196397 26546692767 3029352 0 2305454225 0 0 457718114 36 19480 2472

Not the most friendly format, but you get the idea.

Not sure it actually contains the specific items you're looking for, but they may be available elsewhere in /proc/net.

| improve this answer | |
  • 5
    here's a (single long line) script to format the output: awk '{for(i=1;i<=NF;i++)title[i] = $i; getline; print title[1]; for(i=2;i<=NF;i++)printf " %s: %s\n", title[i], $i }' /proc/net/netstat – meuh Feb 15 '16 at 11:43
  • 1
    /proc/net/snmp contains most of the data and /proc/net/netstat contains the rest. Sadly you'll need to read net-tools statistics.c source to determine all the name mappings, though most are quite obvious. – mr.spuratic Feb 19 '16 at 17:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.