Updated 8 hours ago
A packet capture isn't a wall of data. It's a recording of conversations—and like any conversation, you can hear when something's wrong.
The skill isn't memorizing protocol details. It's pattern recognition. Once you know what healthy communication looks like, the anomalies announce themselves.
The Handshake: How Connections Begin
Every TCP connection starts with three packets. The client sends SYN: "May I connect?" The server responds SYN-ACK: "Yes, and may I respond?" The client confirms with ACK: "Yes."
Three packets, and a relationship begins.
When you see SYN without SYN-ACK, the server isn't answering. It's down, unreachable, or blocked. When you see SYN-ACK followed by RST instead of ACK, something on the client side rejected the connection—a firewall, a crashed application, a change of heart.
RST from the server in response to SYN means active refusal: nothing is listening on that port. The server heard the knock and said "wrong door."
The Goodbye: How Connections End
Graceful closures use four packets. One side sends FIN: "I'm done sending." The other ACKs that FIN. Then sends its own FIN: "I'm done too." The first side ACKs. The conversation ends politely.
RST is different. RST is hanging up mid-sentence. No goodbye, no acknowledgment—just gone. A few RST packets are normal. Many RST packets mean something is breaking connections unexpectedly: applications crashing, firewalls intervening, or protocol-level failures.
Retransmissions: The Sound of Packet Loss
When packets vanish or acknowledgments don't return, TCP tries again. In the capture, retransmissions appear as duplicate sequence numbers—the same data sent twice.
Wireshark flags these automatically. A few retransmissions are normal on any network. High retransmission rates mean serious trouble: congestion, faulty hardware, or unstable links.
The timing tells you more. Quick retransmissions (milliseconds) suggest local issues. Longer delays mean TCP waited for its timeout—complete packet loss, not just slow acknowledgment.
Flow Control: When Receivers Can't Keep Up
Every TCP packet advertises a window size: how much more data the receiver can accept. A window of zero means "stop sending—my buffer is full."
This is normal flow control. The sender pauses, waits for the receiver to catch up, and resumes when the window opens again.
Frequent zero windows mean the receiver can't process data fast enough. The bottleneck isn't the network—it's the endpoint. The application isn't reading from its TCP buffer quickly enough, or the CPU can't keep up with the data rate.
DNS: The Questions Before the Conversation
Before most connections, there's a DNS query. Client asks the DNS server: "What's the IP for this domain?" Server answers with the address—or an error.
Multiple queries for the same domain suggest caching failures. Long gaps between query and response reveal slow DNS. NXDOMAIN responses mean the domain doesn't exist. SERVFAIL means the DNS server itself is having problems.
Applications often retry failed DNS queries several times before giving up. You'll see the same question asked repeatedly, each time met with the same error.
HTTP: Watching the Web Work
HTTP rides on TCP. After the three-way handshake, you'll see requests and responses as TCP payload.
Requests show the method (GET, POST, PUT, DELETE), the path, and headers. Responses show status codes: 200 is success, 301/302 redirect, 404 not found, 500 server error.
Large responses split across multiple packets. Wireshark's "Follow TCP Stream" reassembles them into readable form—essential when the HTML or JSON you need spans dozens of packets.
TLS: The Encrypted Envelope
HTTPS adds TLS encryption after the TCP handshake. You'll see Client Hello ("here's what I support"), Server Hello ("let's use this"), certificate exchange, and key negotiation.
Once TLS completes, everything is encrypted. Without the session keys, you see only opaque bytes. The conversation continues, but you can't read it.
Failed TLS handshakes appear as alerts: certificate problems, version mismatches, cipher disagreements. The connection never establishes, and you can see exactly where it broke.
Timing: What Delays Reveal
Timestamps expose performance. The gap between request and response shows round-trip time plus server processing. The gap between first and last response byte shows transfer duration.
Patterns in timing tell stories. Regular intervals mean polling. Bursts followed by silence mean batch processing. Gradually lengthening delays mean growing queues or resource exhaustion.
Compare related packets. In HTTP, time to first byte reveals server latency. Time to last byte reveals bandwidth constraints.
Scanning and Attacks: The Patterns of Malice
Port scans appear as connection attempts to many ports on the same host—sequential (1, 2, 3...) or targeted (80, 443, 22, 3389). SYN scans send SYN without completing handshakes. Connect scans complete handshakes then immediately close.
Denial of service attacks generate overwhelming packet rates or volumes. Many connections from one source, thousands of UDP packets to random ports, traffic patterns that make no sense as legitimate communication.
Starting with Statistics
Don't begin by reading individual packets. Start with aggregate views.
Protocol hierarchy shows what percentage of traffic belongs to each protocol. Conversations lists all endpoint pairs and their traffic volumes. I/O graphs reveal patterns over time—spikes, baselines, anomalies.
Expert Information automatically flags problems: retransmissions, resets, zero windows, checksum errors. These automated insights surface issues buried in thousands of packets.
The Traps
Captures might start mid-connection. You'll see data packets without the handshake, flagged as "[TCP Previous segment not captured]." Don't assume the first packet in your capture is actually first.
Wireshark shows relative sequence numbers starting at zero for readability. Actual sequence numbers are large random values. Know which you're looking at.
Checksum offloading can show invalid checksums in captures even when transmitted packets are correct. The network adapter calculates checksums after the capture software sees the packet. Invalid checksums in captures from your own machine are usually this artifact, not actual corruption.
Frequently Asked Questions About Reading Packet Captures
Was this page helpful?