Diagnosing the Network — ping, traceroute, ss, tcpdump

Every prior chapter built conceptual understanding. This chapter is the payoff — four real tools that make each of those concepts directly visible on a live system, and the workflow for combining them into an actual diagnosis rather than a guess.

ping — Testing Basic Reachability

ping <host> sends ICMP Echo Request packets and waits for an Echo Reply — a simple, direct test of reachability at the Network layer, using ICMP, which travels alongside IP itself (net1-3). Real output reports round-trip time (RTT) and packet loss percentage.

An honest limitation worth naming directly: ping confirms Network-layer reachability, nothing more. A "yes" from ping doesn't guarantee the actual service you care about — a web server on port 80, say — is reachable at all; many servers and firewalls block ICMP entirely while the real service works perfectly fine, and the reverse is also possible.

traceroute — Seeing the Actual Path

traceroute <host> (Linux/Mac) or tracert (Windows) reveals every router hop along the path to a destination — a direct, visible trace of net1-6's own routing chapter in action.

The mechanism is genuinely clever: it sends packets with increasing TTL (time-to-live) values, and each router along the path that decrements a packet's TTL to zero sends back an ICMP "time exceeded" message, revealing itself as one hop in the chain. The real diagnostic value: seeing exactly where along a path traffic stops, or slows dramatically — directly answering the "is this a routing problem or something else" question net1-6's own warn-box raised.

ss / netstat — Seeing Active Connections and Listening Ports

ss -tulpn on modern Linux (or the older netstat -tulpn) shows every listening port (net1-8's own subject) and every active connection, including its exact TCP state — ESTABLISHED, SYN_SENT, and the rest of net1-7's own handshake vocabulary.

Real diagnostic value: confirming whether a service is actually listening on the port expected, or whether a connection is genuinely stuck mid-handshake — directly revisiting net1-7's own warn-box about a silently dropped SYN-ACK.

tcpdump — Seeing the Actual Packets

tcpdump captures raw packets directly off a network interface — the deepest level of visibility available, showing the real encapsulation (net1-3's own headers) exactly as they exist on the wire.

A captured line shows source and destination IP:port, and TCP flags — SYN, ACK, and the rest — directly tying back to net1-7's own three-way handshake, now visible as literal packets instead of a diagram. This is the same underlying capability Wireshark offers through a GUI — tcpdump is the always-available, CLI-only version.

Putting It Together — A Real Troubleshooting Workflow

In order: ping first — is it reachable at all? traceroute next — if not, where does the path actually break down? ss — if this is the local machine, is the expected service even listening? tcpdump last — if everything above looks fine but something is still wrong, what's actually happening at the packet level?

This is exactly the layer-by-layer troubleshooting instinct net1-1 opened this entire course with, now made concrete and tool-based rather than abstract.

Where This Connects — wdt1 and cloud2-2

wdt1's own Network panel chapter shows exactly this kind of information — requests, status, timing — but from inside a browser's dev tools, scoped to a single page load. This chapter's tools work at the OS/network level, for any traffic at all, not just what one browser tab is doing. cloud2-2's own "Diagnosing Connectivity Issues" chapter — working through security groups, NACLs, route tables, and DNS — assumed exactly this level of tool familiarity and protocol knowledge; this chapter is the foundation that material was quietly built on.

Hands-On Exercises