This tcpdump filter lets you isolate the most critical control packets in a TCP conversation: the SYN, RST, and FIN flags, which signal the start, abrupt termination, and graceful closure of a connection, respectively.

sudo tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0'

Let’s see this in action. Imagine you’re troubleshooting a web server that’s suddenly refusing connections. You suspect a connection teardown issue. Running the tcpdump command on the server’s interface, you might see output like this:

14:35:12.123456 IP 192.168.1.100.54321 > 192.168.1.200.80: Flags [S], seq 1234567890, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 12345678 ecr 0], length 0
14:35:12.123500 IP 192.168.1.200.80 > 192.168.1.100.54321: Flags [S.], seq 987654321, ack 1234567891, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 87654321 ecr 12345678], length 0
14:35:12.123550 IP 192.168.1.100.54321 > 192.168.1.200.80: Flags [.], ack 987654322, win 65535, options [nop,nop,TS val 12345679 ecr 87654321], length 0
14:35:15.500000 IP 192.168.1.100.54321 > 192.168.1.200.80: Flags [F.], seq 1234567891, ack 987654322, win 65535, options [nop,nop,TS val 12345999 ecr 87654321], length 0
14:35:15.500050 IP 192.168.1.200.80 > 192.168.1.100.54321: Flags [R], seq 0, win 0, length 0

In this snippet, you see a [S] (SYN) from the client, a [S.] (SYN-ACK) from the server, and then a [.] (ACK) from the client. This is the standard three-way handshake. However, the server then sends a [R] (RST) flag, abruptly terminating the connection instead of a graceful [F.] (FIN-ACK) close. This RST is the smoking gun.

The tcpdump filter works by examining the TCP header. The tcp[tcpflags] expression accesses the byte that contains the TCP control flags. This byte is then bitwise ANDed (&) with a mask that isolates the bits corresponding to the SYN, FIN, and RST flags. The tcp-syn, tcp-fin, and tcp-rst are predefined masks in tcpdump that represent these specific flags. If the result of this bitwise AND operation is not zero (!= 0), it means at least one of these flags was set in the packet, and tcpdump captures it.

This filter is invaluable for understanding connection establishment, termination anomalies, and identifying sudden drops. It helps distinguish between a connection that never started, one that was cleanly closed, or one that was forcibly terminated.

When troubleshooting, you’re often looking for patterns. A SYN packet without a corresponding SYN-ACK indicates a problem reaching the server or the server’s inability to accept new connections. A FIN packet followed by no ACK might suggest a client that’s not properly acknowledging the closure. The presence of an unexpected RST is a strong indicator of an error condition, security policy denial, or a process crash on one of the endpoints.

Let’s break down the components of a TCP flag:

  • SYN (Synchronize): The first packet in a TCP connection. It requests a connection to a specific port on another host.
  • ACK (Acknowledge): Confirms receipt of a packet. It’s used in response to data packets and as part of the handshake and termination.
  • FIN (Finish): Indicates that the sender has no more data to send and wishes to close the connection gracefully.
  • RST (Reset): Abruptly terminates a connection. This can happen if a packet arrives for a connection that doesn’t exist, or if a host wants to immediately drop a connection.

The filter tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0 essentially says: "Show me any TCP packet where the SYN, FIN, or RST bits are set."

You can also combine these flags with other tcpdump filters. For example, to see only RST packets from a specific IP address to a specific port:

sudo tcpdump 'tcp[tcpflags] & tcp-rst != 0 and src host 192.168.1.100 and dst port 80'

This allows for granular analysis. You can narrow down the scope to specific IPs, ports, or even connection states.

One common scenario where this filter shines is when clients report "connection refused" errors. While this often points to the port not being open or a firewall blocking access, it can also be caused by the server sending an immediate RST in response to a SYN. This filter would reveal that RST packet, pinpointing that the server did receive the SYN but actively rejected the connection.

Another use case is debugging a "half-open" connection. If a connection appears to be active but no data is flowing, and neither side seems to be initiating closure, checking for unexpected RST packets can reveal if one side is silently dropping the connection.

The tcpdump utility itself is a powerful network analysis tool, and understanding its filtering capabilities, especially for TCP control flags, is fundamental for network troubleshooting. This specific filter is a well-worn path for many network engineers when diagnosing connection issues.

If you fix the RST issue by, say, correcting a misconfigured firewall rule that was blocking established connections, the next error you’ll likely encounter is related to the TCP window size or sequence numbers.

Want structured learning?

Take the full Tcpdump course →