Skip to content

Chapter 12: Network Debugging


Metadata Card

AttributeContent
VolumeVol 4 — Computer Networking
ChapterChapter 12: Network Debugging
PrerequisitesChapter 1 (Layering Model), Chapter 3 (TCP), Chapter 4 (HTTP), Chapter 5 (HTTPS)
NextChapter 13 (IPv6 Basics), Chapter 14 (Network Performance)
Theory Depth(2/5)
Python Relevance≈60%; scapy packet construction, curl timing analysis scripts
Core ModelLayered troubleshooting model, debugging toolchain
Code~120 lines

Your Progress

"You've learned so many transmission spells and post road concepts — but what if they don't work? Portal array won't open, spell application is slow, connection refused — post road debugging is a required course for every communication mage. This chapter doesn't teach new transmission spells — only how to find problems using your spellcasting tools."

Layered Troubleshooting

LayerQuestionTool
1 Physical/LinkCable plugged in? WiFi connected?ip link, ifconfig, nmcli
2 NetworkCan I reach the destination? Route OK?ping, traceroute, mtr
3 TransportPort open? Connection state OK?ss, nmap, nc
4 DNSDomain resolves? IP correct?dig, nslookup, host
5 ApplicationWhat did HTTP return? TLS handshake OK?curl -v, openssl s_client, tcpdump

Golden rule: Check from bottom up. If the lower layer is broken, checking upper layers is pointless.

Key Tools

ping: Basic connectivity test. Tells you packet loss and RTT. BUT: ping works ≠ service works (ping uses ICMP, not TCP).

traceroute: Shows the path your packets take. Key use cases: high latency (find which hop spikes), abnormal routing path, packet loss location.

mtr = ping + traceroute (continuous). Shows loss and latency per hop over time.

dig: DNS diagnostic tool. Key info: status (NOERROR vs NXDOMAIN), ANSWER count, TTL, query time, which server replied.

curl -v: Shows the complete HTTP/TLS handshake. The -w flag outputs detailed timing breakdown.

tcpdump / Wireshark: Packet-level analysis. See every byte on the wire.

openssl s_client: Debug TLS handshake failures, view certificate chains.

Common Scenarios

SymptomLikely CauseWhere to Check
"Can't connect"Service not running / firewallss -tlnp, nmap
"Connection refused"Port not listening / firewall blocksnc -zv host port
"Connection timeout"Firewall drops / routing issue / server downmtr, check routing
"Slow"DNS slow / TCP handshake slow / TTFB highcurl -w timing breakdown
"TLS error"Certificate expired / wrong hostname / weak cipheropenssl s_client

Quick Diagnostic Pipeline

bash
# Layer 1: Physical
ip link show | grep "state UP" || echo " Network interface not up"

# Layer 2: Network
ping -c 3 8.8.8.8 || echo " Cannot reach internet"

# Layer 3: Transport
ss -tlnp | grep :443 || echo " Port 443 not listening"

# Layer 4: DNS
dig +short example.com || echo " DNS resolution failed"

# Layer 5: Application
curl -v --connect-timeout 3 https://example.com/ || echo " HTTP request failed"

Traveler's Notes

Network debugging isn't mysticism. It's a systematic layered approach. Every concept you've learned in the previous chapters becomes a real weapon here. The most important skill is knowing which layer to suspect, and which tool to use for each layer. When you approach a network problem systematically — physical → data link → network → transport → DNS → application — you'll find the root cause every time.

Built with VitePress | Software Systems Atlas