Americas

  • United States
sandra_henrystocker
Unix Dweeb

10 Linux commands for testing connectivity and transfer rates

How-To
Mar 04, 202512 mins

These commands can verify connection speeds, analyze delays, and test whether other systems are reachable.

Female Developer Thinking and Typing on Computer, Surrounded by Big Screens Showing Coding Language. Professional Programmer Working in an Office, Running Coding Tests. Futuristic Programming
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.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.

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 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.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, however,  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

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-0500
Keys: 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 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 a popular website:

$ ncat -z -v 205.251.242.103 80
Ncat: 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 -t
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 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:https
ESTAB 0 64 192.168.0.19:ssh 192.168.0.8:62656
LISTEN 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: wlp1s0
IP address is: 192.168.0.19
MAC address is: ec:0e:c4:24:7d:bf
12.5Kb 25.0Kb 37.5Kb 50.0Kb 62.5Kb
qqqqqqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqq
239.255.255.250 => 192.168.0.2 0b 0b 0b
<= 0b 12.2Kb 6.12Kb
239.255.255.250 => _gateway 0b 0b 0b
<= 0b 5.62Kb 2.81Kb
fedora => 192.168.0.8 2.19Kb 1.98Kb 2.26Kb
<= 184b 184b 244b
fedora => ns.shentel.net 0b 66b 31b
<= 0b 108b 70b
fedora => 216.72.190.35.bc.googleusercontent.com 0b 0b 39b
<= 0b 0b 21b





qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
TX: cum: 5.92KB peak: 4.47Kb rates: 4.47Kb 3.02Kb 2.96Kb
RX: 23.3KB 61.6Kb 392b 550b 11.7Kb
TOTAL: 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 | column
Features 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: off
tcp-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: off
netns-local: on [fixed] macsec-hw-offload: off [fixed]
tx-gso-robust: off [fixed] rx-udp-gro-forwarding: off
tx-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.

sandra_henrystocker

Sandra Henry-Stocker has been administering Unix systems for more than 30 years. She describes herself as "USL" (Unix as a second language) but remembers enough English to write books and buy groceries. She lives in the mountains in Virginia where, when not working with or writing about Unix, she's chasing the bears away from her bird feeders.

The opinions expressed in this blog are those of Sandra Henry-Stocker and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.

More from this author