tcpdump: handshake, reset, and a SYN that nobody answers

Three patterns worth naming

A finished handshake is SYN, SYN-ACK, ACK. After that, length greater than zero means application bytes. TLS bytes are still unreadable. You can say the path carried a session, and you can say when it started.

A reset is Flags [R] or Flags [R.]. Note which address sent it. A reset from the server during the handshake often means the port is closed or the service refused the socket. A reset from the client after data, as in the previous lesson, means the client gave up on a session that had already started. Silence is different again: SYN from the client, and no line back. In this capture, nobody answered. That can be a filter, a down host, or a capture that could not see the return path.

Where the capture sat

tcpdump sees one interface. If the lab web tier's NIC sees the SYN leave and never sees the SYN-ACK, the reply may still exist on another link. Say that plainly in the ticket: this interface did not observe a reply. Do not write that the server was down until the server's own capture or its log says so.

Retransmitted SYNs show up as repeated Flags [S] from the same source port, with growing gaps in the timestamps. That is the client waiting. -tttt makes the gap obvious. Three SYNs over several seconds, still with no SYN-ACK, are a stronger version of silence, not a new protocol.

Flags [F.] is a graceful close. Data can still be in flight before the last ACK.
A RST and a FIN answer different questions. RST aborts. FIN starts an orderly close.
Repeated SYN lines with the same source port are retransmits from one attempt.
A new source port is a new attempt, even if the destination is the same.

A worked defensive case

Two lab symptoms arrive the same afternoon. The files VM's health check from 10.8.0.20 to 10.8.0.40 port 443 shows S, S., and then application data. The inventory page's check from 10.8.0.20 to 10.8.0.50 port 8443 shows three Flags [S] lines from port 41002 and nothing back.

You file two notes. The files path completed a handshake, so the outage story moves to the application. The inventory path produced no reply on this NIC. You ask the lab owner whether 10.8.0.50 is up and whether the return route passes this interface. You do not aim a new capture at the rest of the building to settle it.

Where this is documented

TCP's handshake and abort rules are in RFC 9293. tcpdump's job is to print the bits it saw. The meaning of a missing reply depends on where the sensor sat.

Use a host-only lab network, or a capture the owner already handed you. These commands read that file or record a single lab host. They are not a scan of the public internet.

Commands

Health-check port that should complete a handshake

tcpdump -nn -tttt -r /lab/evidence.pcap 'host 10.8.0.20 and host 10.8.0.40 and tcp port 443'

A second lab host whose replies are missing on this NIC

tcpdump -nn -tttt -r /lab/evidence.pcap 'host 10.8.0.20 and host 10.8.0.50 and tcp port 8443'

Diagram

What the next line is allowed to conclude

Three shapes in a lab capture

Handshake, then data
S, S., ACK, then length greater than zero. The path carried a session. Read the application log at the timestamp.
Reset from a named host
Flags [R] or [R.] names the aborter. A server RST at the handshake and a client RST after data are different tickets.
SYN and silence
Only Flags [S], often repeated. This interface saw no reply. Confirm the host and the return path before you call it down.

Check yourself

1. 10.8.0.20 sends three Flags [S] packets to 10.8.0.50 port 8443 from source port 41002. Nothing else matches. What did this capture show?

2. A line reads IP 10.8.0.40.443 > 10.8.0.20.51422: Flags [R.]. Who sent the reset?

3. The files conversation shows S, S., ACK, and then length 517. Where does the ticket go next?