The Homelab Network Testing Toolkit: 7 Tools You Should Know

“My homelab feels slow” is a question without an answer. Where, exactly? Wi-Fi, switch backplane, NAS disk, ISP, peering, application server, container network? Each layer has its own diagnostic tool, and using the wrong one gives you nothing.

This is a working list of seven tools that, between them, cover most of what a homelab operator or small-office IT person ever needs to diagnose. None of them are obscure — most are free, several are pre-installed on Linux and macOS. The skill is knowing which one to reach for first.

1. iperf3 — for throughput between two endpoints

What it measures: raw bandwidth between two machines you control, over TCP or UDP, on any segment of your network.

When to use: any time the question is “how fast is this specific link?” Wi-Fi between the phone and a NAS, the 10 GbE trunk between two switches, the VPN tunnel between two sites, a freshly-cabled run between rooms. Speedtest can’t answer any of those — it only knows the ISP path.

Limits: doesn’t measure application-level behaviour. A clean iperf3 result doesn’t guarantee that SMB or NFS will be fast — those have their own overhead.

Where to get it: standard iperf3 binary on every Linux distro, Homebrew on macOS, and the iPerf3 Client & Server app on iOS, iPadOS, macOS, and Android for the GUI version. All wire-compatible with each other.

2. mtr — for latency and packet loss on a path

What it measures: every hop between you and a destination, with per-hop latency and packet loss. It’s traceroute + ping, continuously updating.

When to use: “the connection to X is slow” or “this remote site feels laggy.” mtr immediately tells you whether the slowness is your gateway, your ISP, your ISP’s upstream, the remote ISP, or the destination — and exactly which hop is dropping packets.

Limits: measures one-way path quality, not throughput. A path with 0% loss can still be bandwidth-limited.

Where to get it: mtr on Linux, brew install mtr on macOS. On Windows, use pathping or WinMTR.

3. SmokePing — for latency over time

What it measures: continuous ping data to multiple destinations, plotted over hours and days. Gives you a baseline of “normal” so you can recognise when something is abnormal.

When to use: if you find yourself thinking “the network was slow earlier today,” SmokePing is what tells you whether it really was, what time, and to which destination. It’s the difference between “I think it was bad” and “between 21:14 and 21:42 our path to Cloudflare lost 4% of packets.”

Limits: it’s infrastructure — you set it up once and let it run for weeks. It doesn’t help with one-off “right now” investigations; it builds the historical context.

Where to get it: smokeping package on Debian/Ubuntu, official tarball on oss.oetiker.ch/smokeping. Container images on Docker Hub for quick deployment.

4. ethtool — for what your NIC is actually doing

What it measures: link speed, duplex, error counters, queue counts, and offload settings on a physical network interface on Linux.

When to use: when iperf3 shows lower throughput than expected and you need to know if the NIC is the bottleneck. Common revelations: a “gigabit” port negotiated at 100 Mbps because of a damaged cable, a 10 GbE port stuck at 1 Gbps because the switch SFP isn’t recognised, CRC errors climbing on a flaky link.

Limits: Linux only. macOS has partial equivalents in ifconfig and system_profiler; Windows has Device Manager.

Where to get it: pre-installed on most Linux distros, otherwise sudo apt install ethtool.

5. tcpdump — for what packets are actually on the wire

What it measures: every packet flowing through a network interface, with arbitrary filtering (protocol, port, source/destination).

When to use: when application behaviour doesn’t match what you expect and you need to confirm the packets you think are being sent actually are. Why is this connection retrying? Why is the DNS lookup taking 5 seconds? Why does my container’s outbound traffic look weird? tcpdump shows the truth.

Limits: the learning curve is real. Reading raw packet captures is a skill. For most cases, capture with tcpdump and then read in Wireshark (next tool).

Where to get it: pre-installed on Linux and macOS. brew install tcpdump if you want the latest.

6. Wireshark — for understanding what you captured

What it measures: the same packets tcpdump captures, but with a GUI and protocol decoders that turn raw bytes into human-readable conversations. TCP handshakes, TLS negotiations, HTTP requests, DNS lookups, all visually annotated.

When to use: any time you’ve captured a .pcap with tcpdump and need to understand it. Especially good for “why did this TLS handshake fail?” or “what’s wrong with this DHCP exchange?”

Limits: GUI tool, so you don’t run it on a server — you capture with tcpdump, copy the file, open in Wireshark locally.

Where to get it: wireshark.org, free, runs on every OS. The tshark CLI variant is useful for scripted analysis.

7. fast.com / Cloudflare Speed Test — for the ISP question

What it measures: end-to-end throughput from your device to a public CDN (Netflix for fast.com, Cloudflare’s nearest edge for their tool). Pure ISP-path measurement.

When to use: the one question Speedtest-style tools answer: “is my ISP delivering its contracted bandwidth?” Use fast.com or Cloudflare’s test rather than Ookla Speedtest because the public-CDN endpoints are harder for ISPs to whitelist for throttling.

Limits: tells you nothing about your LAN, Wi-Fi, or any internal hop. Useful precisely when you’ve already used iperf3 to confirm the LAN is fine and you want to isolate the ISP.

Where to get it: fast.com or speed.cloudflare.com in a browser. No install.

A diagnostic decision tree

When something is “slow,” the order of tools is usually:

1. Is it the LAN or the WAN? Run iperf3 against a known-good local server. If the LAN is fine, the WAN is suspect. Move to step 2. If the LAN is bad, skip to step 5.
2. Is it our ISP or a remote site? Run mtr to the destination that’s slow. If packet loss starts at your ISP’s first hop, it’s the ISP. If it starts further out, the remote-side ISP or peering.
3. Is it bandwidth or latency? fast.com confirms ISP bandwidth. mtr confirms latency. If bandwidth is fine but the application is slow, the application is sensitive to latency, not throughput.
4. Is it consistent or intermittent? Check SmokePing’s last 24 hours. Intermittent issues that line up with peak hours mean ISP congestion; spike-and-clear patterns may be peering.
5. (LAN side) Is it the physical layer? ethtool on Linux. Check NIC speed, duplex, error counters. A bad cable causes weird errors that look like everything else.
6. Is it the application protocol? tcpdump → Wireshark. Capture, inspect, look for retransmissions, TLS handshake failures, unexpected redirects, retried DNS queries.

Most real-world problems get solved at step 1 or 2. The rest are for the harder cases that take a day instead of an hour.

Tools we deliberately left off this list

A few honourable mentions and why they didn’t make the cut:

• Ping by itself. Useful but redundant — mtr is a superset.
• netstat / ss. Critical for socket-level debugging, but not for “is the network slow” questions.
• NetSpot / Ekahau. Excellent for Wi-Fi heat-mapping, but expensive and specialised. iperf3 from a phone covers most of the same ground for verification purposes.
• Speedtest by Ookla. Replaced by fast.com / Cloudflare in this list because ISPs are known to optimise for Ookla specifically.
• iftop / nload / bmon. Real-time bandwidth visualisers — useful for spot-checking what’s saturating a link, not for “how fast is this link?”

If you’re missing them for your specific workflow, add them. The seven above are the minimum set most homelab operators end up reaching for repeatedly.

Where to start if you’re building this kit from scratch

Realistic order of adoption for someone with no current tools:

1. iperf3 — both as the standard CLI binary on at least one of your servers, and as the iPerf3 Client & Server app on the phone in your pocket. Single highest payoff for the smallest setup cost.
2. mtr — works out of the box, single command, immediately answers “is the slowness ours or theirs?”
3. SmokePing — set up once, runs forever. By the time the first weird incident happens, you’ll have the baseline data to diagnose it.
4. Wireshark + tcpdump — only when you’ve already exhausted the simpler tools. The learning curve is justified by the depth you get.

After that, ethtool and fast.com fill in the gaps. You’ll have the whole stack within a weekend’s worth of setup, and most outages will resolve in minutes instead of evenings.