In a tcpdump TCP line, what do the flag fields [S], [S.], [P.], [F.], [R.] and a bare [.] each tell you?
answer
- one character per set control bit
- the dot is not 'nothing'
- S F R P, then the dot
- 'none' when no bit is set
basics
~20 sEach character is one TCP control bit that is set: S SYN, F FIN, P PSH, R RST, U URG, and a dot for ACK. So [S.] is SYN plus ACK, [P.] data with ACK, and [.] a bare acknowledgment.
solid answer
~50 stcpdump prints `Flags [...]` with one character for every control bit that is set: `S` SYN, `F` FIN, `R` RST, `P` PSH, `.` ACK, `U` URG, `E` ECE, `W` CWR and, since tcpdump 4.99.7, `e` for AE; with no bit set it prints `Flags [none]`. Read them as combinations: `[S]` opens a connection, `[S.]` is the SYN-ACK answering it, `[.]` is a pure acknowledgment, `[P.]` carries data with PSH and ACK, `[F.]` is a FIN that also acknowledges, and `[R.]` is a reset with the ACK bit set — the usual answer to a SYN for a port nobody listens on. `[R]` without the dot is a reset with no ACK bit. The field tells you which bits were on the segment at the capture point; what that means for the connection's state is TCP's business, not tcpdump's.
go deeper
Recall the character for each bit, especially that the dot is ACK, and be able to name a handshake from [S], [S.] and [.] without hesitation.
Explain why combinations print in a fixed order, recognise [FP.], [R] versus [R.] and Flags [none], and say which fields appear only when the segment carries data.
Read a pasted fragment by its flags column first and state which conclusions are about the capture point rather than the network, before reaching for sequence numbers.
Use flag-field reading as the shared vocabulary for incident write-ups, so teams describe captures precisely instead of paraphrasing what they think happened.
## Where the flag field sits in the line With no verbosity options, tcpdump prints one line per TCP segment. After the timestamp, the `IP` (or `IP6`) marker and the `source.port > destination.port:` pair, the first TCP field is always the flags: ``` 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:07.131877 IP 198.51.100.20.443 > 192.0.2.10.51514: Flags [S.], seq 2836418390, ack 1584207324, win 65160, options [mss 1460,sackOK,TS val 1033404826 ecr 3196613497,nop,wscale 7], length 0 10:42:07.131950 IP 192.0.2.10.51514 > 198.51.100.20.443: Flags [.], ack 1, win 502, options [nop,nop,TS val 3196613511 ecr 1033404826], length 0 10:42:07.132311 IP 192.0.2.10.51514 > 198.51.100.20.443: Flags [P.], seq 1:518, ack 1, win 502, options [nop,nop,TS val 3196613511 ecr 1033404826], length 517 ``` The **flag field** is the quickest way to orient yourself in a dozen lines handed over in an interview: it tells you which control bits the segment carried, and therefore roughly where in the life of the connection you are. The tcpdump manual page and its TCP printer agree that the field, the addresses and the IP type are always present; sequence, ack, window, options and length are printed only when they apply. ## The characters tcpdump builds the field from a fixed table and prints one character for every bit that is set, with no separator: | Character | Control bit | Typical sighting | |---|---|---| | `S` | SYN | first segment of a connection | | `F` | FIN | a side has finished sending | | `R` | RST | the connection is aborted or refused | | `P` | PSH | a segment carrying application data | | `.` | ACK | almost every segment after the first | | `U` | URG | rare; an `urg` value is printed too | | `E` | ECE | ECN negotiation or congestion echo | | `W` | CWR | ECN negotiation or window reduced | | `e` | AE | accurate ECN; printed since tcpdump 4.99.7 | If no bit is set at all, the field reads `Flags [none]` — not an empty pair of brackets and not a dot. ## Reading the common combinations The characters always come out in the table's order, F, S, R, P, dot, U, E, W, e, so the same combination always prints the same way: - **`[S]`** — a SYN with no ACK: the client's opening segment. - **`[S.]`** — SYN and ACK together: the SYN-ACK. The dot is the ACK bit, not punctuation. - **`[.]`** — ACK only: the third segment of the handshake, and every pure acknowledgment after it. - **`[P.]`** — PSH and ACK: a segment carrying data; its line also shows a `seq first:last` range and a non-zero `length`. - **`[F.]`** — FIN and ACK: one side has no more data to send. A FIN that also carries the last bytes with PSH set prints as `[FP.]`. - **`[R.]`** — RST and ACK: a reset that acknowledges something, typically the reply to a SYN for a closed port. - **`[R]`** — RST with no ACK bit: still an abort, just without an acknowledgment number. - **`[SEW]`** — a SYN that also sets ECE and CWR, which is how a client offers ECN; the answering SYN-ACK prints `[S.E]`. ## What the field cannot tell you 1. **It is the capture point's view.** A missing `[S.]` means no SYN-ACK reached the interface tcpdump was watching, not that the server never sent one. 2. **It is not the meaning.** Whether `[R.]` after `[S]` means a closed port, and how a FIN close proceeds through its states, belong to the TCP handshake and teardown material; tcpdump only reports the bits. 3. **`-q` hides it.** Quick output prints `tcp` and a payload length instead of the flag field, so a capture someone ran with `-q` cannot be read this way. ## How interviewers use it The usual exercise is a pasted fragment and the question "what happened here". A strong answer starts from the flags column: a `[S]` with no `[S.]` after it, an `[S]` answered by `[R.]`, a burst of `[P.]` lines that stop, or `[F.]` from one side only. Naming each line by its flags first, then reading the numbers, keeps the explanation honest and fast. A close read the same way: ``` IP 198.51.100.20.443 > 192.0.2.10.51514: Flags [P.], seq 1:3801, ack 518, win 506, length 3800 IP 198.51.100.20.443 > 192.0.2.10.51514: Flags [F.], seq 3801, ack 518, win 506, length 0 IP 192.0.2.10.51514 > 198.51.100.20.443: Flags [.], ack 3802, win 501, length 0 IP 192.0.2.10.51514 > 198.51.100.20.443: Flags [F.], seq 518, ack 3802, win 501, length 0 IP 198.51.100.20.443 > 192.0.2.10.51514: Flags [.], ack 519, win 506, length 0 ``` By flags alone: the server sends data, then its FIN; the client acknowledges, sends its own FIN, and the server acknowledges that. Notice that the FIN lines print a `seq` with no range, because they carry no payload, while the pure acknowledgments print no `seq` at all. Had the client answered the server's FIN with a single `[R.]` instead, the same reading would say the client aborted rather than closed — and why a stack does that is a question for the TCP teardown material, not for the capture.
- Why does a FIN that carries the last bytes of a response often print as [FP.] rather than [F.]?tcpdump prints a character for every bit that is set, in a fixed order — F, S, R, P, the dot, then U, E, W and e. A segment with FIN, PSH and ACK all set therefore shows `[FP.]`, and because it carries payload its line also has a `seq first:last` range and a non-zero `length`.
- A tcpdump line shows Flags [SEW]; what is that segment?A SYN that also has ECE and CWR set — the way a client offers Explicit Congestion Notification when opening a connection. A server that accepts usually answers with a SYN-ACK printed as `[S.E]`. What ECN does once negotiated is congestion-control material; tcpdump only reports the bits.
saying these in an interview costs you the question
- The dot in [S.] is just a separator, not a flag.
- Flags [.] means the segment had no flags set at all.
- [P.] marks a retransmitted or malformed segment.
- Every [R.] means a firewall blocked the connection.
- The order of letters shows the order bits were set.