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.\nping\nThe 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.\n\nResponse 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.\n$ ping 192.168.0.11\nPING 192.168.0.11 (192.168.0.11) 56(84) bytes of data.\n64 bytes from 192.168.0.11: icmp_seq=1 ttl=64 time=4.36 ms\n64 bytes from 192.168.0.11: icmp_seq=2 ttl=64 time=5.86 ms\n64 bytes from 192.168.0.11: icmp_seq=3 ttl=64 time=2.87 ms\n^C\n--- 192.168.0.11 ping statistics ---\n3 packets transmitted, 3 received, 0% packet loss, time 2003ms\nrtt min\/avg\/max\/mdev = 2.867\/4.361\/5.859\/1.221 ms\n\nOn 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.\nA 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.\u00a0If you're experiencing problems, a ping command is likely to show significant packet loss.\n$ ping 18.104.22.168\nPING 22.214.171.124 (126.96.36.199) 56(84) bytes of data.\n64 bytes from 188.8.131.52: icmp_seq=1 ttl=46 time=362 ms\n64 bytes from 184.108.40.206: icmp_seq=2 ttl=46 time=305 ms\n64 bytes from 220.127.116.11: icmp_seq=3 ttl=46 time=276 ms\n64 bytes from 18.104.22.168: icmp_seq=4 ttl=46 time=257 ms\n^C\n--- 22.214.171.124 ping statistics ---\n4 packets transmitted, 4 received, 0% packet loss, time 3002ms\nrtt min\/avg\/max\/mdev = 257.172\/300.119\/362.431\/39.775 ms\n\ntraceroute\nTraceroute 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).\nThe 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\u00a0to report on the duration of time between each hop.\nHere's an example of using traceroute to reach a local system (a single hop and a quick response):\n$ traceroute 192.168.0.11\ntraceroute to 192.168.0.11 (192.168.0.11), 30 hops max, 60 byte packets\n 1 192.168.0.11 (192.168.0.11) 9.228 ms 12.797 ms 12.782 ms\n\nThis 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.\nThe 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).\n$ traceroute www.amazon.com\ntraceroute to www.amazon.com (126.96.36.199), 30 hops max, 60 byte packets\n 1 router (192.168.0.1) 1.586 ms 3.842 ms 4.074 ms\n 2 10.226.32.1 (10.226.32.1) 27.342 ms 28.485 ms 29.529 ms\n 3 10.17.1.25 (10.17.1.25) 30.769 ms 31.584 ms 32.379 ms\n 4 10.17.0.221 (10.17.0.221) 33.126 ms 34.390 ms 35.284 ms\n 5 10.17.0.226 (10.17.0.226) 37.000 ms 38.837 ms 40.808 ms\n 6 188.8.131.52 (184.108.40.206) 44.083 ms 42.671 ms 42.582 ms\n 7 220.127.116.11 (18.104.22.168) 44.254 ms 30.422 ms 31.666 ms\n 8 * * *\n 9 * * *\n10 * * *\n11 22.214.171.124 (126.96.36.199) 41.548 ms 188.8.131.52 (184.108.40.206) 41.808 ms 220.127.116.11 (18.104.22.168) 43.326 ms\n12 * * *\n13 * * *\n14 * * *\n15 * * *\n16 * * *\n17 server-99-84-218-165.iad79.r.cloudfront.net (22.214.171.124) 44.862 ms 44.746 ms 44.713 ms\n\nncat\nThe ncat command is a many-featured network utility for\u00a0writing 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\u00a0(the network mapper).\nBy 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.\n$ nc -z -v 192.168.0.11 22\nNcat: Version 7.80 ( https:\/\/nmap.org\/ncat )\nNcat: Connected to 192.168.0.11:22.\nNcat: 0 bytes sent, 0 bytes received in 0.02 seconds.\n\nThe 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.\n$ nc -z -v 192.168.0.11 80\nNcat: Version 7.80 ( https:\/\/nmap.org\/ncat )\nNcat: Connection refused.\n\nWe get a predictably different response when we check on Amazon:\n$ nc -z -v 126.96.36.199 80\nNcat: Version 7.80 ( https:\/\/nmap.org\/ncat )\nNcat: Connected to 188.8.131.52:80.\nNcat: 0 bytes sent, 0 bytes received in 0.48 seconds.\n\nAs you likely noticed, the ncat command can be called using nc or ncat.\nspeedtest\nThe 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.\u00a0\nNote 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\u00a0tool will highlight any differences. In the test below, the download speed is nearly nine times the upload speed.\n$ speedtest\n\n Speedtest by Ookla\n\n Server: Winchester Wireless - Winchester, VA (id = 21859)\n ISP: Shentel Communications\n Latency: 25.86 ms (0.96 ms jitter)\n Download: 10.34 Mbps (data used: 10.7 MB)\n Upload: 1.00 Mbps (data used: 1.1 MB)\nPacket Loss: 0.0%\n Result URL: https:\/\/www.speedtest.net\/result\/c\/bb2e002a-d686-4f9c-8f36-f93fbcc9b752\n\nCommand results will differ somewhat from one test to the next.\nYou can also use speedtest through a browser by going to\u00a0. (Note: Downloaded free copies of speedtest are intended for personal non-commercial use. Consult the EULA (usage agreement) for details.)\nfast\nYou 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.\n$ fast\n$\u00a0\u00a0 10.08 Mbps\nThe fast tool can be installed using these commands:\n$ wget https:\/\/github.com\/ddo\/fast\/releases\/download\/v0.0.4\/fast_linux_amd64\n$ sudo install fast_linux_amd64 \/usr\/local\/bin\/fast\n$ which fast\n\/usr\/local\/bin\/fast\n\nnethogs\nThe 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.\nNetHogs version 0.8.6\n\u00a0\u00a0\u00a0 PID USER\u00a0\u00a0\u00a0\u00a0 PROGRAM\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 DEV\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 SENT\u00a0\u00a0\u00a0\u00a0\u00a0 RECEIVED\n\u00a0127832 nemo\u00a0\u00a0\u00a0\u00a0 \/usr\/lib\/firefox\/firefox \u00a0\u00a0enp0s2\u00a0\u00a0\u00a0\u00a0 11.120\u00a0\u00a0\u00a0 \u00a0432.207 KB\/sec\n\u00a0413216 shs\u00a0\u00a0\u00a0\u00a0\u00a0 sshd: shs@pts\/1\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 enp0s2\u00a0\u00a0\u00a0\u00a0\u00a0 0.246\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0.059 KB\/sec\n\u00a0\u00a0\u00a0 696 root\u00a0\u00a0\u00a0\u00a0 \/usr\/sbin\/NetworkManager\u00a0\u00a0 enp0s2\u00a0\u00a0\u00a0\u00a0\u00a0 0.000\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0.000 KB\/sec\n\u00a0\u00a0\u00a0\u00a0\u00a0 ? root\u00a0\u00a0\u00a0\u00a0 unknown TCP\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0.000\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0.000 KB\/sec\n\n\u00a0 TOTAL\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0.246\u00a0\u00a0\u00a0\u00a0 432.266 KB\/sec\n\nIn the output shown, the process using the bulk of the bandwidth is quite obvious.\nWrap-up\nMany 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.