Network debugging tools

tcpdump, ss, mtr, nmap, iperf.

Network problems are among the hardest to diagnose because the evidence is on the wire, and a focused toolkit turns "the connection is weird" into specifics. The famous tools each answer a different layer: tcpdump captures actual packets, ss inventories sockets, mtr traces the path and its loss, nmap probes what is listening, and iperf measures raw throughput. Reach for the one that matches your question rather than guessing.

tcpdump — capture the packets

tcpdump is the definitive packet capture tool — it shows the actual traffic on an interface, filtered by host, port, or protocol. It is how you prove what is really being sent (is the request even leaving? is the reply coming back? is it a RST?), and it can write a .pcap file to open later in Wireshark for deep analysis. A capture filter keeps the volume sane; the classic form is "capture on this interface, this port, this host."

$ sudo tcpdump -i eth0 -nn port 443 and host 10.0.2.1
10:14:22 IP 10.0.1.5.51234 > 10.0.2.1.443: Flags [S], seq ...     # our SYN goes out
10:14:25 IP 10.0.1.5.51234 > 10.0.2.1.443: Flags [S], seq ...     # retransmit — no reply!
#   → the SYN is leaving but nothing answers: firewall drop or dead listener
$ sudo tcpdump -i eth0 -w capture.pcap port 443    # save to open in Wireshark later

ss, mtr, nmap — sockets, path, and ports

Three more cover the common questions. ss (from essentials, deeper here) shows sockets and their states — a pile stuck in SYN-SENT means your side cannot reach the peer; a pile in CLOSE-WAIT often means the app is not closing connections. mtr combines ping and traceroute into a live view of every hop and its packet loss, pinpointing where on the path traffic dies. nmap scans a host for open ports — the authoritative "what is actually reachable and listening?" from the outside, and a staple of both debugging and security review.

$ ss -tan state syn-sent            # our outbound connections stuck half-open
$ mtr -rwc 10 10.0.2.1               # report mode: each hop, latency, and % loss
  2. router.internal    0.0%   1.2ms
  5. 10.0.2.1          40.0%   ...    # 40% loss starts at hop 5 — there is the problem
$ nmap -Pn -p- 10.0.2.1              # every open TCP port on the host

iperf — measure throughput

When the question is "how fast is this link, really?", iperf3 measures it: run a server on one host and a client on the other, and it reports actual achievable bandwidth. This separates "the network is slow" from "the application is slow" — if iperf gets full line rate but your app crawls, the network is fine and the problem is above it. It is the definitive tool for benchmarking a path rather than inferring its speed from an application.

# on the server host:            on the client host:
$ iperf3 -s                      $ iperf3 -c server-host -t 10
#                                [ ID] Interval   Transfer   Bitrate
#                                [  5] 0-10s       11.0 GBytes  9.42 Gbit/s   <- near line rate