skip to content

A client tcpdump shows one SYN to port 443 sent three times unanswered; how does that look different from a refused connection?

level: middleimportance: must knowfreq 34%

answer

  1. same source port, same seq
  2. gaps that grow
  3. the reset's ack points at the SYN
  4. silence is about this capture point

basics

~20 s

Three [S] lines with the same source port and seq are one SYN retransmitted because nothing reached this capture point in reply. A refused attempt is one [S] answered within a round trip by [R.] acking the SYN's seq plus one.

solid answer

~50 s

Identical `[S]` lines — same source port, same `seq`, gaps that grow from about one second to two on a typical Linux client — are one connection attempt being retransmitted, not three attempts; no `[S.]`, `[R.]` or ICMP error reached the interface tcpdump was watching. A **refused** attempt looks completely different: a single `[S]`, then within one round trip `Flags [R.], seq 0, ack <SYN seq + 1>, win 0, length 0`; the ack value ties the reset to that exact SYN, and the client stops at once. A firewall that rejects rather than drops may instead send an ICMP line such as `host ... unreachable - admin prohibited filter`, visible only if the capture expression lets ICMP through. Silence proves only what reached the client's capture point, so the next step is a simultaneous capture on the server side.

go deeper

for a junior

Recall that repeated identical [S] lines mean no reply arrived and that a quick [R.] after [S] means the attempt was actively refused.

for a middle

Explain how the matching seq and source port identify a retransmission, and how the reset's ack value ties it to one specific SYN.

for a senior

Say what silence proves at this capture point, ask for a simultaneous server-side capture, and check the reset's TTL and whether the filter hid ICMP.

for a principal

Make two-point captures with dated timestamps the default evidence for connectivity incidents, so teams stop arguing over one-sided traces.

## Two captures handed over in an interview The classic exercise is a handful of client-side lines and the question "why did the connection fail?". Two patterns cover most answers. **Pattern A — unanswered SYN:** ``` 10:42:07.118204 IP 192.0.2.10.51514 > 198.51.100.20.443: Flags [S], seq 1584207323, win 64240, options [mss 1460,sackOK,TS val 3196613497 ecr 0,nop,wscale 7], length 0 10:42:08.141862 IP 192.0.2.10.51514 > 198.51.100.20.443: Flags [S], seq 1584207323, win 64240, options [mss 1460,sackOK,TS val 3196614521 ecr 0,nop,wscale 7], length 0 10:42:10.189853 IP 192.0.2.10.51514 > 198.51.100.20.443: Flags [S], seq 1584207323, win 64240, options [mss 1460,sackOK,TS val 3196616569 ecr 0,nop,wscale 7], length 0 ``` **Pattern B — refused:** ``` 10:44:31.502117 IP 192.0.2.10.51516 > 198.51.100.21.8443: Flags [S], seq 902114470, win 64240, options [mss 1460,sackOK,TS val 3196757881 ecr 0,nop,wscale 7], length 0 10:44:31.504098 IP 198.51.100.21.8443 > 192.0.2.10.51516: Flags [R.], seq 0, ack 902114471, win 0, length 0 ``` ## Reading pattern A - **Same source port, same `seq`.** A new connection attempt would pick a new initial sequence number and usually a new port. Identical values mean the TCP stack is resending the same SYN. - **Growing gaps.** About one second, then about two: the retransmission timer backing off. Why it doubles belongs to TCP's retransmission rules; on the line it is the signature of "nothing came back". - **The timestamp option is what changes.** `TS val` advances between copies because it carries the sender's clock. - **Nothing in the other direction.** No `[S.]`, no `[R.]`, no ICMP error. ## Reading pattern B - **One SYN, one answer, two milliseconds apart.** The reply came back within a round trip. - **`[R.]`** — reset with the ACK bit. - **`seq 0, ack 902114471`** — tcpdump prints these raw because the reset is the first ACK-bearing segment of the conversation. The ack is the SYN's `seq` plus one, which proves the reset answers this exact SYN. - **`win 0, length 0`** — a reset carries no window and no data. What each response means for the port, closed versus filtered, is the TCP handshake's subject; the capture shows only which response arrived. ## What the application sees The two patterns also explain the different errors users report. Pattern A ends only when the client's stack gives up after its last retransmission, or when the application's own timeout fires first, so the caller sees a **timeout** after several seconds. Pattern B ends at the reset, so the caller sees an immediate **refusal**. When a ticket says "connection timed out", expect pattern A in the capture; when it says "connection refused", expect pattern B. If the capture disagrees with the error message, suspect that it was taken at a different point, on a different interface, or at a different time from the failure. ## A third pattern, and how a filter hides it A firewall configured to reject rather than drop may answer with ICMP: ``` IP 198.51.100.1 > 192.0.2.10: ICMP host 198.51.100.20 unreachable - admin prohibited filter, length 68 ``` or `ICMP 198.51.100.20 tcp port 443 unreachable`. These are not TCP packets. A capture expression of `tcp port 443` never matches them, so the client capture looks exactly like pattern A while the answer was on the wire. Widen the expression to include ICMP when chasing a failing connect. ## What silence proves, and the next capture Pattern A proves one thing: nothing in reply reached the client's capture point. It does not say whether the SYN reached the server. Capture on both ends at the same time, with `-n` and dated `-tttt` timestamps so the lines can be lined up: | Server-side capture shows | Reading | |---|---| | no SYN at all | lost or dropped on the way in | | SYN arrives, `[S.]` leaves | the reply is lost on the way back | | SYN arrives, nothing leaves | dropped on the server host, or nothing listening and resets suppressed | | SYN arrives, `[R.]` leaves | the client should see pattern B; if not, the reset was lost on the way back | Two cautions about the server row with a SYN and no reply: 1. On a typical Linux host tcpdump sees inbound packets before the host firewall decides, so a visible SYN does not prove the listener received it. 2. A reset can come from a device in the path rather than the server. With `-v`, compare the reset's `ttl` with the server's normal replies; a very different TTL suggests a different sender. Deciding which network layer failed, once the capture has located the loss, is a wider diagnostic ladder; the capture's job is to say exactly which packet stopped appearing, and where.

  • The [R.] arrives, but with -v its ttl is far from the TTL on the server's normal replies; what does that suggest?
    That the reset may not come from the server. A firewall or other device in the path can answer a SYN with a reset itself, and a different hop count shows as a different TTL. Capture on the server: if the SYN never arrives there, the reset was generated in between.
  • Why might a client capture show neither a reply nor an ICMP error when a firewall is in fact rejecting the SYN?
    If the capture expression matches only `tcp port 443`, the ICMP unreachable message does not match it — it is ICMP, not TCP — so tcpdump never prints it, and the capture looks like plain silence. Include ICMP in the expression when chasing a connect that fails.
  • The server-side capture shows the SYN arriving and [S.] leaving, yet the client never sees it; where do you look?
    On the return path between the two capture points. The SYN-ACK left the server's interface and did not reach the client's, so something between them dropped it — for example a stateful device that saw only one direction of the flow because the routing is asymmetric.

saying these in an interview costs you the question

  • Three identical [S] lines are three separate connection attempts.
  • No reply in a client capture proves the server is down.
  • An [R.] reply always comes from the server itself.
  • A tcp port 443 capture still shows ICMP errors about port 443.
  • A SYN in the server's capture proves the application received it.