These commands can verify connection speeds, analyze delays, and test whether other systems are reachable. Credit: Gorodenkoff / Shutterstock 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. This post provides intros and example output from these commands: ping traceroute mtr ncat speedtest fast nethogs ss iftop ethtool ping The ping command is the simplest and most often used command for doing basic connectivity testing. It sends out packets called “echo requests” — 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.11PING 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 ms64 bytes from 192.168.0.11: icmp_seq=2 ttl=64 time=5.86 ms64 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 2003msrtt 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.22PING 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 ms64 bytes from 180.65.0.22: icmp_seq=2 ttl=46 time=305 ms64 bytes from 180.65.0.22: icmp_seq=3 ttl=46 time=276 ms64 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 3002msrtt 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 are congested. If 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.11traceroute 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, however, using the -m argument (e.g., traceroute -m 50 distant.org). $ traceroute www.amazon.comtraceroute 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 ms12 * * *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 mtr The mtr (my traceroute) command combines the functionality of the ping and traceroute commands. In the example below, the mtr command is evaluating the connectivity between the local system and the default router. Notice that it reports on the percentage of packets lost and the number sent. fedora (192.168.0.19) -> 192.168.0.1 (192.168.0.1) 2025-02-21T14:16:27-0500Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. _gateway 0.0% 13 3.3 3.5 3.0 7.1 1.1 The fields reported by the mtr command include: Loss %: percentage of packets lost Snt: number of packets sent Last: Latency of last packet sent Avg: average latency of packets sent Best: fastest response Wrst: slowest response StDev: standard deviation Keep in mind that network latency is affected by several factors, including distance, bandwidth and network congestion levels. 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 22Ncat: 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 a popular website: $ ncat -z -v 205.251.242.103 80Ncat: Version 7.93 ( https://nmap.org/ncat )Ncat: Connected to 205.251.242.103:80.Ncat: 0 bytes sent, 0 bytes received in 0.10 seconds. NOTE: the ncat command can be called by typing nc or ncat. speedtest The speedtest tool tests the speed of your connectivity with your Internet provider. 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 https://www.speedtest.net/. Click GO and you will see a moving graphical display of your speed measurements. Related: How to use speedtest: 2-Minute Linux Tips fast You can also install a tool called fast that checks your download speed a number of times and then reports the average speed. It displays download speed only and uses the Netflix speed-testing service (Fast.com). $ 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. Related: Who’s hogging the network? Bandwidth usage on a Linux system ss The ss command (which stands for “Socket Statistics”) is a potent tool for inspecting and displaying detailed information about network sockets on a Linux system. When no options are used, it shows sockets which are not listening. With the -a option, ss will list all sockets, so expect a lot of output. With both the -a and -g options, you’ll see something like this: $ ss -a -tState Recv-Q Send-Q Local Address:Port Peer Address:Port ProcessLISTEN 0 4096 127.0.0.1:ipp 0.0.0.0:*LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:*LISTEN 0 4096 127.0.0.54:domain 0.0.0.0:*LISTEN 0 5 127.0.0.1:dey-sapi 0.0.0.0:*LISTEN 0 4096 0.0.0.0:hostmon 0.0.0.0:*LISTEN 0 4096 127.0.0.53%lo:domain 0.0.0.0:*LISTEN 0 5 127.0.0.1:44321 0.0.0.0:*TIME-WAIT 0 0 192.168.0.19:42928 109.61.91.195:httpsESTAB 0 64 192.168.0.19:ssh 192.168.0.8:62656LISTEN 0 5 [::1]:dey-sapi [::]:*LISTEN 0 128 [::]:ssh [::]:*LISTEN 0 4096 [::1]:ipp [::]:*LISTEN 0 4096 [::]:hostmon [::]:*LISTEN 0 5 [::1]:44321 [::]:* iftop The iftop command is a real-time network monitoring tool that displays network connections and their current bandwidth usage. Like nethogs, it can help you identify the connections using the most bandwidth. Here’s a sample of its output. Note that sudo privilege is required. $ sudo iftop[sudo] password for shs:interface: wlp1s0IP address is: 192.168.0.19MAC address is: ec:0e:c4:24:7d:bf 12.5Kb 25.0Kb 37.5Kb 50.0Kb 62.5Kbqqqqqqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqq239.255.255.250 => 192.168.0.2 0b 0b 0b <= 0b 12.2Kb 6.12Kb239.255.255.250 => _gateway 0b 0b 0b <= 0b 5.62Kb 2.81Kbfedora => 192.168.0.8 2.19Kb 1.98Kb 2.26Kb <= 184b 184b 244bfedora => ns.shentel.net 0b 66b 31b <= 0b 108b 70bfedora => 216.72.190.35.bc.googleusercontent.com 0b 0b 39b <= 0b 0b 21bqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqTX: cum: 5.92KB peak: 4.47Kb rates: 4.47Kb 3.02Kb 2.96KbRX: 23.3KB 61.6Kb 392b 550b 11.7KbTOTAL: 29.2KB 64.0Kb 4.85Kb 3.56Kb 14.6Kb ethtool The ethtool command provides a way to examine and control network interface controller (NIC) parameters on Linux systems. Sysadmins can use it to extract details for network interfaces, modify settings to optimize performance, and troubleshoot issues effectively. It’s an essential command for managing and optimizing network interfaces and provides extremely detailed output like that shown below. Note that “fixed” doesn’t mean “repaired”; it means that those settings cannot be changed. $ ethtool --show-features wlp1s0 | columnFeatures for wlp1s0: tx-ipxip6-segmentation: off [fixed]rx-checksumming: off [fixed] tx-udp_tnl-segmentation: off [fixed]tx-checksumming: off tx-udp_tnl-csum-segmentation: off [fixed] tx-checksum-ipv4: off [fixed] tx-gso-partial: off [fixed] tx-checksum-ip-generic: off [fixed] tx-tunnel-remcsum-segmentation: off [fixed] tx-checksum-ipv6: off [fixed] tx-sctp-segmentation: off [fixed] tx-checksum-fcoe-crc: off [fixed] tx-esp-segmentation: off [fixed] tx-checksum-sctp: off [fixed] tx-udp-segmentation: off [fixed]scatter-gather: off tx-gso-list: off [fixed] tx-scatter-gather: off [fixed] fcoe-mtu: off [fixed] tx-scatter-gather-fraglist: off [fixed] tx-nocache-copy: offtcp-segmentation-offload: off loopback: off [fixed] tx-tcp-segmentation: off [fixed] rx-fcs: off [fixed] tx-tcp-ecn-segmentation: off [fixed] rx-all: off [fixed] tx-tcp-mangleid-segmentation: off [fixed] tx-vlan-stag-hw-insert: off [fixed] tx-tcp6-segmentation: off [fixed] rx-vlan-stag-hw-parse: off [fixed]generic-segmentation-offload: off [requested on] rx-vlan-stag-filter: off [fixed]generic-receive-offload: on l2-fwd-offload: off [fixed]large-receive-offload: off [fixed] hw-tc-offload: off [fixed]rx-vlan-offload: off [fixed] esp-hw-offload: off [fixed]tx-vlan-offload: off [fixed] esp-tx-csum-hw-offload: off [fixed]ntuple-filters: off [fixed] rx-udp_tunnel-port-offload: off [fixed]receive-hashing: off [fixed] tls-hw-tx-offload: off [fixed]highdma: off [fixed] tls-hw-rx-offload: off [fixed]rx-vlan-filter: off [fixed] rx-gro-hw: off [fixed]vlan-challenged: off [fixed] tls-hw-record: off [fixed]tx-lockless: off [fixed] rx-gro-list: offnetns-local: on [fixed] macsec-hw-offload: off [fixed]tx-gso-robust: off [fixed] rx-udp-gro-forwarding: offtx-fcoe-segmentation: off [fixed] hsr-tag-ins-offload: off [fixed]tx-gre-segmentation: off [fixed] hsr-tag-rm-offload: off [fixed]tx-gre-csum-segmentation: off [fixed] hsr-fwd-offload: off [fixed]tx-ipxip4-segmentation: off [fixed] hsr-dup-offload: off [fixed] 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 they represent a range of tools that are both easy to use and informative. SUBSCRIBE TO OUR NEWSLETTER From our editors straight to your inbox Get started by entering your email address below. Please enter a valid email address Subscribe