A TCP connection begins with three packets and a set of options. Almost every connectivity problem announces itself in how that sequence fails: no reply, a reset, a stall after the handshake, or retransmissions that imply loss rather than refusal.

Learning to read those four patterns is most of packet-level troubleshooting.

The sequence, with the fields that matter

Packet Flags Key fields
1 SYN Client ISN, MSS, window scale, SACK permitted, timestamps
2 SYN-ACK Server ISN, its MSS, its window scale
3 ACK Acknowledges the server ISN; connection established

The MSS option is the largest segment each side will accept, and it is negotiated, not configured. The window scale multiplies the receive window, which is why a capture showing a tiny window may still be a fast connection.

The initial sequence numbers are random

An ISN that looks sequential across connections is a sign of a weak random number generator or a middlebox rewriting the handshake. It matters for security, and it is worth noticing.

Failure 1: SYN with no reply

client → server  SYN
(no response, retransmit at 1 s, 3 s, 7 s)

The packet left the client. Something between the client and the server either dropped it or could not return the answer.

Likely cause Where to look
Firewall drop (silent) Policy counters on each hop
No route back Routing table on the server's gateway
Server not listening ss -lntp on the server
Wrong destination address NAT and DNS answers

A firewall that rejects produces a reset instead. A firewall that drops produces this silence. The difference is a configuration choice, and it is why one host "refuses" and another "times out."

Failure 2: SYN-ACK sent, no ACK

client → server  SYN
server → client  SYN-ACK
(no ACK; server retransmits)

The server answered and the client never completed. Two explanations: the SYN-ACK never reached the client (asymmetric return path, or a stateful device that never saw the SYN), or the client vanished.

This pattern is the signature of asymmetric routing. Capture at both ends: one side sees the request, the other sees the reply, and neither sees the conversation.

Failure 3: reset

client → server  SYN
server → client  RST, ACK

A reset is an active refusal. The port is closed, or a device is configured to reject rather than drop. It is fast and unambiguous, which makes it the friendliest failure.

RSTs in the middle of an established connection are different: an idle timeout on a stateful device, a load balancer dropping a backend, or an application closing abruptly. Look at the last successful data packet before the reset and the elapsed time — it usually matches a firewall session timeout.

Failure 4: handshake completes, then stalls

This is the hardest and the most common in the field.

  • MTU black hole. Small packets pass; the first full-size segment disappears. The handshake succeeds because it is small, and the connection hangs on the first large payload.
  • TLS failure after TCP. The TCP handshake is fine; the TLS ClientHello gets no response, or the certificate is rejected.
  • Application not responding. The connection is open and the server never sends data.

The discriminator is the first data packet: did it leave, did it arrive, was it acknowledged?

Four ways a connection fails, and what each one implies.

Timers tell you how long it has been broken

Retransmission timing is exponential: roughly 1 s, 3 s, 7 s, 15 s. If a capture shows retries stretching back minutes, the problem started long before the user called, which is useful when correlating with a change window.

Wireshark's tcp.analysis.flags filter surfaces retransmissions, duplicate ACKs, zero windows, and keepalives without reading every packet.

Worked example

A teacher cannot reach the gradebook. The capture at the server shows:

10:14:02.118  client → server  SYN
10:14:02.121  server → client  SYN-ACK
10:14:02.124  client → server  ACK
10:14:02.125  client → server  ClientHello (571 bytes)
10:14:03.130  client → server  retransmission (571 bytes)
10:14:05.132  client → server  retransmission
10:14:09.140  client → server  retransmission

The handshake is clean. The first large packet is not acknowledged and never answered. That is an MTU or policy problem on the path, not a server problem — and the handshake succeeding is exactly what made it look like an application bug.

What breaks in production

  • Reading a single capture as the whole truth. One side's view is half the conversation.
  • Confusing drop with reject. Timeouts and resets point at different configurations.
  • Ignoring the MSS option when a tunnel is in the path. 1460 vs 1360 explains a lot of stalls.
  • Blaming the server when the client never answered the SYN-ACK.
  • Missing the first packet because the capture started too late or the filter excluded it.

Checklist

  1. You capture both sides when the pattern is asymmetric.
  2. You distinguish silence (drop) from reset (reject).
  3. You check MSS and the first full-size segment on any tunnel path.
  4. You read retransmission timing to estimate how long the fault has existed.
  5. You filter with tcp.analysis.flags before reading packet by packet.

Next

TCP carries the traffic; DNS and DHCP decide whether it can start. Continue with DNS and DHCP in a Capture.

  • TCP
  • Wireshark
  • Troubleshooting
  • Retransmission