Linux commands for testing connectivity and transfer rates

There are quite a few tools that can help test your connectivity on the Linux command line. In this post, we’ll look at a series of commands that can help estimate your connection speed, test whether you can reach other systems, analyze connection delays, and determine whether particular services are available.

ping

The ping command is the simplest and most often used command for doing basic connectivity testing. It sends out packets called echo requests and are packets that request a response. The command looks for the responses and displays them along with how long each response took and then reports what percentage of the requests were answered.

Response times will largely depend on how many routers the requests need to cross and whether your network is congested. Pinging a local system might look like this. Note the small number of milliseconds required for each response and the 0% packet loss.

$ ping 192.168.0.11
PING 192.168.0.11 (192.168.0.11) 56(84) bytes of data.
64 bytes from 192.168.0.11: icmp_seq=1 ttl=64 time=4.36 ms
64 bytes from 192.168.0.11: icmp_seq=2 ttl=64 time=5.86 ms
64 bytes from 192.168.0.11: icmp_seq=3 ttl=64 time=2.87 ms
^C
--- 192.168.0.11 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 2.867/4.361/5.859/1.221 ms

On Linux systems, the pings will continue until you type ^c to stop them. Some systems, including Windows, issue four pings and then stop on their own. A remote system will take considerably longer to respond. Zero packet loss is always a good sign and even when you’re pinging a remote system will generally be what you should expect to see unless there is a problem.

A ping command provides an easy way to check network connectivity for a home network. Send requests to a publicly accessible system and you should expect 0% packet loss. If you’re experiencing problems, a ping command is likely to show significant packet loss.

$ ping 180.65.0.22
PING 180.65.0.22 (180.65.0.22) 56(84) bytes of data.
64 bytes from 180.65.0.22: icmp_seq=1 ttl=46 time=362 ms
64 bytes from 180.65.0.22: icmp_seq=2 ttl=46 time=305 ms
64 bytes from 180.65.0.22: icmp_seq=3 ttl=46 time=276 ms
64 bytes from 180.65.0.22: icmp_seq=4 ttl=46 time=257 ms
^C
--- 180.65.0.22 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 257.172/300.119/362.431/39.775 ms

traceroute

Traceroute is a much more complex command as it runs a series of checks to see how long each hop between routers takes and reports it back. If the overall check takes a long time, it might be that one or two of the hops is congested. It the reported results descend into a sequence of asterisks, the last router reached is not able to respond to the packet type being used (UDP by default on Linux systems).

The traceroute command uses a clever technique to time each hop. It uses a time to live (TTL) setting that is decremented with each hop to ensure that each router along the route will at some point send back an error message. This allows traceroute to report on the duration of time between each hop.

Here’s an example of using traceroute to reach a local system (a single hop and a quick response):

$ traceroute 192.168.0.11
traceroute to 192.168.0.11 (192.168.0.11), 30 hops max, 60 byte packets
 1  192.168.0.11 (192.168.0.11)  9.228 ms  12.797 ms  12.782 ms

This next traceroute command tries to reach a remote system, but is unable to report on each hop (those showing asterisks) because the routers at some hops don’t respond to the type of packet used. This is not unusual.

The default maximum number of hops for traceroute is 30. Notice that this setting is displayed in the first line of output. It can be changed using the -m argument (e.g., traceroute -m 50 distant.org).

$ traceroute www.amazon.com
traceroute to www.amazon.com (99.84.218.165), 30 hops max, 60 byte packets
 1  router (192.168.0.1)  1.586 ms  3.842 ms  4.074 ms
 2  10.226.32.1 (10.226.32.1)  27.342 ms  28.485 ms  29.529 ms
 3  10.17.1.25 (10.17.1.25)  30.769 ms  31.584 ms  32.379 ms
 4  10.17.0.221 (10.17.0.221)  33.126 ms  34.390 ms  35.284 ms
 5  10.17.0.226 (10.17.0.226)  37.000 ms  38.837 ms  40.808 ms
 6  204.111.0.145 (204.111.0.145)  44.083 ms  42.671 ms  42.582 ms
 7  99.82.178.164 (99.82.178.164)  44.254 ms  30.422 ms  31.666 ms
 8  * * *
 9  * * *
10  * * *
11  52.93.40.225 (52.93.40.225)  41.548 ms 52.93.40.223 (52.93.40.223)  41.808 ms 52.93.40.225 (52.93.40.225)  43.326 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  server-99-84-218-165.iad79.r.cloudfront.net (99.84.218.165)  44.862 ms  44.746 ms  44.713 ms

ncat

The ncat command is a many-featured network utility for writing data across networks from the command line but, in the form shown below, allows you to simply determine whether you can connect to a particular service. It was originally written for nmap (the network mapper).

By sending zero bytes (the -z setting) to a particular port on a remote system, we can determine whether the related service is available without actually having to make use of the connection.

$ nc -z -v 192.168.0.11 22
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.0.11:22.
Ncat: 0 bytes sent, 0 bytes received in 0.02 seconds.

The command above tells us that ssh is responding on the specified system, but doesn’t try to log in or run a remote command. Checking for a web site on the same system shows us the opposite (i.e., no web server running) for port 80.

$ nc -z -v 192.168.0.11 80
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Connection refused.

We get a predictably different response when we check on Amazon:

$ nc -z -v 99.84.218.165 80
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Connected to 99.84.218.165:80.
Ncat: 0 bytes sent, 0 bytes received in 0.48 seconds.

As you likely noticed, the ncat command can be called using nc or ncat.

speedtest

The speedtest tool tests the speed of your connectivity with your Internet provider. The FCC in this guide suggests that 12-25 Mbit/s is about average for home usage. 

Note that it is not at all uncommon for upload speeds to be considerably slower than download speeds. Internet providers understand that most people download considerably more data than they upload. The speedtest tool will highlight any differences. In the test below, the download speed is nearly nine times the upload speed.

$ speedtest

   Speedtest by Ookla

     Server: Winchester Wireless - Winchester, VA (id = 21859)
        ISP: Shentel Communications
    Latency:    25.86 ms   (0.96 ms jitter)
   Download:    10.34 Mbps (data used: 10.7 MB)
     Upload:     1.00 Mbps (data used: 1.1 MB)
Packet Loss:     0.0%
 Result URL: https://www.speedtest.net/result/c/bb2e002a-d686-4f9c-8f36-f93fbcc9b752

Command results will differ somewhat from one test to the next.

You can also use speedtest through a browser by going to . (Note: Downloaded free copies of speedtest are intended for personal non-commercial use. Consult the EULA (usage agreement) for details.)

fast

You can also install a tool called fast that checks your download speed a number of times and then reports an average. It displays download speed only and uses the Netflix speed-testing service.

$ fast
$   10.08 Mbps

The fast tool can be installed using these commands:

$ wget https://github.com/ddo/fast/releases/download/v0.0.4/fast_linux_amd64
$ sudo install fast_linux_amd64 /usr/local/bin/fast
$ which fast
/usr/local/bin/fast

nethogs

The nethogs command takes an entirely different approach from the commands explained above. It groups bandwidth usage by process to help you pinpoint particular processes that might be causing a slowdown in your network traffic. In other words, it helps you pinpoint the “net hogs”, so it is aptly named.

NetHogs version 0.8.6
    PID USER     PROGRAM                    DEV         SENT      RECEIVED
 127832 nemo     /usr/lib/firefox/firefox   enp0s2     11.120     432.207 KB/sec
 413216 shs      sshd: shs@pts/1            enp0s2      0.246       0.059 KB/sec
    696 root     /usr/sbin/NetworkManager   enp0s2      0.000       0.000 KB/sec
      ? root     unknown TCP                            0.000       0.000 KB/sec

  TOTAL                                                 0.246     432.266 KB/sec

In the output shown, the process using the bulk of the bandwidth is quite obvious.

Wrap-up

Many tools are available for testing connectivity and connection speeds on Linux systems. Those mentioned in this post are only some of them, but represent a range of tools that are both easy to use and informative.