Weekly pcap puzzle. Here is the capture — what broke? Reveal, root cause, and the prompt that solves it.
Same DNS server, same subnet, same patches — one user's lookups fail and yours do not. The capture, three hypotheses, the reveal, and the Claude prompt that finds it in one shot.
14:22:01 10.0.4.42 → resolver UDP/53 query 14:22:01 resolver → 10.0.4.42 TC=1 (truncated) 14:22:01 10.0.4.42 → resolver TCP/53 [SYN] 14:22:04 10.0.4.42 → resolver TCP/53 [SYN] retry [!] root cause: host blocks TCP/53
A TCP session completes the handshake, pushes exactly one byte, gets the ACK — then the next segment vanishes and the connection hangs forever. The same two hosts work fine for everyone on the LAN. The capture, three hypotheses, and the Claude prompt that names it in one shot.
$ ssh app01 # hangs after connect [ok] SYN / SYN-ACK / ACK [ok] 1-byte push ACKed [!!] 1460B [DF] retrans ×5, no ACK tell: MTU black hole → clamp MSS
A server is reachable for thirty seconds, then gone for thirty, in a near-perfect cycle. Reboots and cable swaps do nothing. The ARP table holds the answer: two MAC addresses are fighting over one IP. The capture, three hypotheses, and the Claude prompt that ends the war.
$ ping 10.0.4.50 # up...down...up arp -a → 10.0.4.50: 00-1a-2b-3c-4d-5e then… 00-50-56-9a-11-22 same IP! tell: duplicate IP — last ARP wins
A new server answers ping perfectly in both directions, but every TCP connection dies right after the SYN. ICMP is happy; the handshake never finishes. The capture, three hypotheses, and the Claude prompt that finds the firewall you forgot was in the path.
$ ping 10.20.5.10 # 0% loss $ curl :443 # hangs SYN → out via fw-A SYN-ACK ← via fw-B → no state → DROP tell: asymmetric routing + stateful fw
Half the laptops on a floor pull a normal lease; the other half land on 169.254 with no internet. Everyone is hunting a rogue DHCP server. The switch counters say the real server is being silenced by the very feature meant to protect it. Three hypotheses and the Claude prompt that calls it.
ipconfig → 169.254.18.44 (APIPA) next switch → 10.30.3.x fine snooping drops (untrusted): 4012↑ uplink Gi1/0/48 Trusted: NO tell: you blocked your own DHCP
A switch-to-switch uplink screams at 90+ Mb/s in one direction and crawls at barely 2 Mb/s in the other — same cable, same ports, no QoS in sight. Everyone suspects a failing cable. The interface counters on the two ends disagree in a very specific way. Three hypotheses and the Claude prompt that names the culprit in one line.
iperf A→B 93.6 Mb/s ✓ iperf B→A 2.44 Mb/s ✗ core-sw Gi1/0/48 Full-duplex acc-sw07 Gi1/0/1 Half + late-collisions tell: duplex mismatch — half side can't talk