5

Background of the question: I am trying to sum up the total bandwidth, but ss -i cleverly converted numbers to more readable format like Kbps/s or Mbps/s, which is not accurate. So does ss -o with timers. I looked the source code and find the conversion is hardcoded. So I need raw number from somewhere.

From man ss

-D FILE
Do not display anything, just dump raw information about TCP sockets to FILE after applying filters. If FILE is - stdout is used.

I don't see the format documented anywhere. Also this raw dump is heavily depends on kernel I think.

  • 1
    I fear you'll have to look at kernel source and find out, what info NETLINK_INET_DIAG delivers. – yegorich Dec 13 '13 at 9:06
4
+100

Beyond what's available in the man page for ss I didn't find a whole lot of documentation about this tool. Worse there doesn't appear to be any guide or mention anywhere as to any details about what gets dumped out in the file when you use the -D switch.

I did find this document, SS Utility: Quick Intro, but it makes rally no meaningful mention of the -D switch. NOTE: This document appears t obe authored by the creator of ss, and the source for this document is maintained as part of the source tree.

Looking through the source tree (kernel.org or github), the function that does the work of writing this file out are contained within, but it's not that easy to tease out what's going on.

I ended up opening an issue on github asking this question over there to see if the developer can shed some light on this.

UPDATE #1

The author got back to my issue and stated that the file format is called netlink.

The file is in netlink format; ie. format the netlink message format used when iproute and related commands interact with kernel.

Details on the file format are covered in this RFC3549, titled: Linux Netlink as an IP Services Protocol. I also found this HOWTO titled: Generic Netlink HOW-TO based on Jamal's original doc, which may be helpful as well. A howto is also maintained on the linuxfoundation's website, titled: generic_netlink_howto.

The author also suggested using the library libmnl when attempting to parse files containing netlink information.

Look at libmnl as best way to handle/parse netlink.

Documentation on this library is kept here: libmnl Documentation. The project page for libmnl is kept under the netfilter.org site as a sub project. The web interface to its git repository is accessible as well.

  • thanks for the effort, but IMHO libmnl is used to parse the netlink message format, but where does the payload struct inside the netlink response come from? Edit: found a relevant question – est Dec 30 '13 at 4:24
  • @est - yes parsing these types of files isn't easy. I'd continue asking the author of ss. He might be able to help you further. It's in his best interests to get these details out, since it will make ss more usable, IMO. – slm Dec 30 '13 at 14:46
1

According to its manual page on a Linux system, ss(8) is "another utility to investigate sockets"; it's Linux-specific, part of iproute, but seems to be similar in concept to the more mainstream netstat.

This is a sample output from ss -i:

# ss -i | head
State      Recv-Q Send-Q      Local Address:Port          Peer Address:Port
ESTAB      0      0         173.xxx.xxx.xxx:46780         72.21.203.xx:www
         cubic wscale:6,7 rto:276 rtt:76/38 cwnd:10 send 1.5Mbps rcv_space:14600
ESTAB      0      0         173.xxx.xxx.xxx:35674        208.71.121.xx:www
         cubic rto:272 rtt:72/36 cwnd:10 send 1.6Mbps rcv_space:14600
ESTAB      0      0         173.xxx.xxx.xxx:33496       198.252.206.xx:https
         cubic wscale:9,7 rto:274 rtt:74.875/2.25 ato:40 cwnd:10 send 1.5Mbps rcv_rtt:524913 rcv_space:29456
ESTAB      0      0         173.xxx.xxx.xxx:49605       205.251.242.xx:www
         cubic wscale:6,7 rto:282 rtt:82.625/37.5 cwnd:10 send 1.4Mbps rcv_space:14600

As you can see, information about receive and send queue is available, just as with netstat, but ss goes further, and also provides additional info, all of which appears to revolve around the concept of TCP window scaling and buffer size of the socket, and around the concept of bandwidth-delay product.

So, this bandwidth that you're talking about is most likely calculated through the division of the send buffer size by rtt (round-trip time). Any such calculation is bound to be very coarse, imprecise and variable, so, when you see a value like 1.6Mbps, there's not much point to know more decimal points, since the whole number is simply a moving target in the first place.

  • 1
    Thank you! You are correct about the bandwidth. See ss.c source code But I still want to know more about the raw dump, like the timer. From my rough fuzz matching it appears to have full TCP_INFO struct. Which is very useful for network diagnoses. – est Dec 26 '13 at 1:48

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.