Packet Capture & Troubleshooting Flow

Real-world analogy

What is it?

Packet capture turns ‘I think’ into ‘I observed.’ Used responsibly, it’s one of the single biggest differentiators between juniors who guess and juniors who win promotions.

Real-world relevance

An app team insists the firewall is dropping their API. You capture: SYN leaves the client, no response arrives. tracert dies two hops before the firewall. Not a firewall problem at all — a broken route. Evidence reframes the whole conversation.

Key points

• When to capture (and when not to) — Capture when: logs disagree with users, intermittent issues, vendor demands evidence, suspected performance issues. Don’t capture casually on production without approval — capture files contain sensitive data and network load.
• Wireshark basics — Pick the correct interface → capture with a filter (ip host 10.0.0.5 and port 443) → stop when you’ve seen the failure → save. Display filters narrow after capture; capture filters narrow during.
• Handshake you must recognize — TCP 3-way handshake: SYN → SYN/ACK → ACK. TLS handshake: ClientHello → ServerHello → certificates → keys → Finished. Missing pieces point to the layer at fault (network vs firewall vs TLS).
• Common patterns in captures — RST from firewall = policy drop. ICMP ‘unreachable’ = no route/ACL deny. Repeated SYNs with no SYN/ACK = path blocked before server. TLS alert = cert/name mismatch or cipher issue.
• tcpdump for servers — On Linux servers where Wireshark UI isn’t available: tcpdump -i eth0 -w capture.pcap host 10.0.0.5 and port 443. Copy to your laptop and open in Wireshark. Standard for senior-friendly evidence.
• Evidence-driven escalation — ‘Firewall team, here’s a 20-second pcap showing our SYN reaches 10.0.0.5:443 and we receive TCP RST within 2ms’ gets action in minutes. ‘App is broken, please help’ gets ignored for hours.
• Respect privacy and scope — Captures often contain credentials, tokens, personal data. Limit scope (host/port filters), store securely, share only with approved people, and delete after the case closes. In regulated environments, capture sensitivities are real.
• Baselines > snapshots — A single capture tells you what you saw. A baseline capture from a known-good time tells you what changed. If you can capture during peace, you’ll diagnose wars faster.

Code example

// Evidence-driven network triage

Step 1 — confirm layer symptoms
  ipconfig, ping, tracert, nslookup, Test-NetConnection

Step 2 — capture at the client
  Wireshark on client NIC
  Filter: ip host <server> and tcp port <port>

Step 3 — capture at the server or mirror port
  tcpdump -i <iface> host <client> and port <port> -w out.pcap

Step 4 — compare
  - SYN seen at client and at server?
  - SYN/ACK returned?
  - RST (who sent it — client, firewall, or server)?
  - TLS handshake complete?

Step 5 — escalate with evidence
  "Attached pcap shows SYN from 10.1.1.10 reaches 10.2.2.20:443,
   RST originates from the firewall pair per IP in capture at hop X.
   Please verify rule XYZ."

Line-by-line walkthrough

1. 1. Evidence-driven triage
2. 2. Step 1 — confirm layer symptoms
3. 3. Step 2 — client-side capture
4. 4. Client Wireshark filter
5. 5. Step 3 — server/mirror capture
6. 6. tcpdump on the server
7. 7. Step 4 — compare captures
8. 8. SYN observed at both ends?
9. 9. SYN/ACK returned?
10. 10. Who sent the RST
11. 11. TLS handshake completion
12. 12. Step 5 — escalate with evidence
13. 13. Example escalation message

Spot the bug

Ticket: 'HTTPS to portal fails intermittently.'
Junior reruns ping a few times, shrugs, and closes the ticket as 'no issue reproduced'.

Explain like I'm 5

Fun fact

Hands-on challenge

More resources

• Wireshark official site (Wireshark)
• tcpdump manual (tcpdump.org)
• Wireshark for beginners (Chris Greer)