Search code examples
tcp

TCP sequence and ack values for TCP SYN and TCP RST

I'm sending a few TCP SYN packets to get TCP RST's back. In order to identify each probe, I include a counter in the TCP sequence field. I noticed the following:

  • when the sequence numbers in SYN probes are 0, 1, 2, 3..., RST messages have ack=1, 2, 3, 4..., that is ack=syn_seq+1:

12:17:27.181993 IP X.X.X.X.10104 > Y.Y.Y.10114: Flags [S], seq 0, win 8192, length 0 12:17:27.182008 IP Y.Y.Y.Y.10114 > X.X.X.X.10104: Flags [R.], seq 0, ack 1, win 0, length 0 12:17:27.683148 IP X.X.X.X.10104 > Y.Y.Y.Y.10114: Flags [S], seq 1, win 8192, length 0 12:17:27.683156 IP Y.Y.Y.Y.10114 > X.X.X.X.10104: Flags [R.], seq 0, ack 2, win 0, length 0 12:17:28.184140 IP X.X.X.X.10104 > Y.Y.Y.Y.10114: Flags [S], seq 2, win 8192, length 0 12:17:28.184147 IP Y.Y.Y.Y.10114 > X.X.X.X.10104: Flags [R.], seq 0, ack 3, win 0, length 0 12:17:28.684993 IP X.X.X.X.10104 > Y.Y.Y.Y.10114: Flags [S], seq 3, win 8192, length 0 12:17:28.685000 IP Y.Y.Y.Y.10114 > X.X.X.X.10104: Flags [R.], seq 0, ack 4, win 0, length 0

  • on the other hand, when my probes start with a seq > 1, the first rst will have ack=syn_seq+1 as usual, but then the following rst's will have ack=2,3,4... regardless of the sequence value of the probes:

12:11:25.274636 IP X.X.X.X.59150 > Y.Y.Y.Y.59160: Flags [S], seq 299, win 8192, length 0 12:11:25.274649 IP Y.Y.Y.Y.59160 > X.X.X.X.59150: Flags [R.], seq 0, ack 300, win 0, length 0 12:11:25.775218 IP X.X.X.X.59150 > Y.Y.Y.Y.59160: Flags [S], seq 300, win 8192, length 0 12:11:25.775226 IP Y.Y.Y.Y.59160 > X.X.X.X.59150: Flags [R.], seq 0, ack 2, win 0, length 0 12:11:26.276324 IP X.X.X.X.59150 > Y.Y.Y.Y.59160: Flags [S], seq 301, win 8192, length 0 12:11:26.276332 IP Y.Y.Y.Y.59160 > X.X.X.X.59150: Flags [R.], seq 0, ack 3, win 0, length 0 12:11:26.776940 IP X.X.X.X.59150 > Y.Y.Y.Y.59160: Flags [S], seq 302, win 8192, length 0 12:11:26.776948 IP Y.Y.Y.Y.59160 > X.X.X.X.59150: Flags [R.], seq 0, ack 4, win 0, length 0

Is this the expected behaviour?

Solution

  • Ok, there was actually no real problem. When I inspected the packets with Wireshark and looked at the real bits in the packet, the ack value of each RST packet was set to seq_of_syn + 1, as usual.

    tcpdump was simply using a relative ack number in the output. That's all.