Capture and read packets

A packet capture shows what crossed an interface. Capture only traffic you own or are authorized to inspect, because packets may contain private application data.

A narrow filter keeps the evidence readable:

sudo tcpdump -ni any host 192.0.2.20 and port 443

Look for a DNS query and reply, TCP SYN and SYN-ACK, repeated retransmissions, resets, TLS alerts, or application responses. Missing packets are evidence too when compared with captures from both endpoints.

Wireshark can decode the same layers visually. Remember that capture offloading and encryption can affect what you see. Correlate packets with application and firewall logs.

Match requests to replies

Capture a small, bounded sample instead of recording everything:

sudo tcpdump -ni any -c 20 'icmp or port 53'

In another terminal, run one ping and one DNS lookup. Match each request with its reply. Notice the source, destination, protocol, and timing. Do not capture production traffic casually: packets can contain private addresses, names, tokens, and unencrypted application data.

Try it on your own machine:

dig +short flaviocopes.com
# 104.21.4.157

In the capture you should see a UDP query to your resolver on port 53, then a reply carrying the answer. A ping shows paired Echo Request and Echo Reply lines with the same sequence number. If you see requests with no replies, you know where the conversation stopped.

What to look for when something breaks

Repeated identical TCP segments usually mean retransmissions: the sender never got an acknowledgment. A lone RST after a SYN means nothing listened on that port. TLS alerts after a successful handshake point at certificates or cipher mismatch, not routing.

My advice is to capture only after you’ve classified the failing layer with simpler tools. Packet dumps are powerful, but they are also noisy. A filter that matches one host and one port keeps the evidence small enough to read in a few minutes.