TCP Reset

RST: connection refused, connection destroyed

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸Watch a closed port answer a SYN with an RST
▸Decode the RST's carefully chosen seq and ack values
▸Distinguish 'refused' (RST) from 'filtered' (silence) — the port scanner's bread and butter

Before this lesson — it builds directly on:

The graceful shutdown you saw in the last lesson assumes both sides agree a connection exists. Sometimes that assumption is simply false: a packet arrives for a connection that was never opened, or that the other machine has already forgotten, or that points at a port where nothing is listening. There is no polite conversation to have — the receiver has no state to negotiate with. RST is the answer to that situation: one packet that says 'this connection does not exist, stop immediately', and it is neither acknowledged nor answered.

✗ Common misunderstanding: RST and FIN both just close the connection.

Why that's wrong: FIN is a graceful, acknowledged, half-duplex shutdown: 'I'm done sending, but I'll keep receiving.' RST is an immediate abort — unacknowledged, unanswerable, and it discards anything still in flight.

Correct model: FIN is saying goodbye; RST is hanging up mid-sentence. FIN takes four packets and preserves data; RST takes one and may lose data.

The packets prove it: Compare the termination trace (FIN, ACK, FIN, ACK, then TIME-WAIT) with the reset trace: one RST, both ends CLOSED instantly, nothing retransmitted.

Watch these fields in the lab: tcp.flags.rst

Think of FIN as saying goodbye and RST as hanging up mid-sentence. FIN takes four packets, is acknowledged at every step, closes one direction at a time, and guarantees that data already sent still gets delivered. RST takes one packet, is never acknowledged, closes everything at once, and throws away whatever was still in flight. They are not two flavours of the same thing — one preserves your data and the other doesn't.

Knocking on a door and being told nobody lives there, versus getting no answer

"nobody of that name here": → RST from a closed port
no answer at all: → a firewall silently discarding the SYN
how quickly the answer comes: → the round trip that distinguishes them

Where it breaks down: A person who answers the door has decided to. A RST is generated by the operating system before any application is involved, so it says nothing about whether the machine is otherwise healthy or whether the right service exists elsewhere on it.

✗ Common misunderstanding: RST and FIN both just close the connection.

Correct model: FIN is saying goodbye; RST is hanging up mid-sentence. FIN takes four packets and preserves data; RST takes one and may lose data.

The packets prove it: Compare the termination trace (FIN, ACK, FIN, ACK, then TIME-WAIT) with the reset trace: one RST, both ends CLOSED instantly, nothing retransmitted.

Watch these fields in the lab: tcp.flags.rst · tcp.flags.fin

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

Why is an RST never acknowledged?

A user reports a truncated download. The capture shows the connection ended with RST rather than FIN. What does that change about your investigation?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.