This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

What should the sequence number of a TCP/RST packet be after a TCP/FIN

1
1

I'm troubleshooting an issue and it seems the receiver is not handling a RST packet. In this case the client sends a frame of data and then a frame with FIN set. The server responds with a couple of frames with data. This data trigger the client to send a RST. Should the sequence number of this RST be the same as the sequence number of the FIN? Or should it be increased by one, as the FIN takes one "phantom" byte?

In short:

(1)  C->S  seq=X     ack=Y    FIN
(2)  S->C  seq=Y     ack=X    data (len=10)
(3)  S->C  seq=Y+10  ack=X+1  FIN
(4)  C->S  seq=???            RST

Should the sequence number of the RST be X or X+1?

asked 12 Dec '11, 09:41

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k●9●57●245
accept rate: 20%

edited 12 Dec '11, 12:09

OK, a tracefile says more than a thousand words... So I stripped the tracefile and posted it on cloudshark.org

I need to determine if the client should sent the RST with a different SEQ number or the server should process the RST (which it seems not to do).

(12 Dec '11, 14:28) SYN-bit ♦♦

One Answer:

2

Besides that this is dependent on the FIN being inside the final data packet (piggybacked), in your case, where there seems to be no TCP data inside the client FIN, the no-data containing FIN packet counts as this one phantom byte.

So in your case the RST should have a sequence number +1 higher than inside the FIN if(!) the FIN got acked previously.

Edit on new thoughts based on cloudshark post: For what I see there let me summarize the key points:

  1. The RTT and delta compared tells me that the client should have recieved the last three frame sent by the server before the RST (frames 650-652)
  2. In frame 652 the server increments his ACK number, telling that he recieved the FIN packet from the client. And now it gets interesting:
  3. The Client sends just a RST without an ACK number being set (just 0 Bytes). That way the servers retransmission trigger kicks in because of unacknowldged data (RTO ~ 200ms and then doubleing up -> 400, 800, 1600 ... see frames 654 to end)
  4. The servers stack "should" react to the clients RST in frame 653, BUT due to the sequence number being 894 and the server having ACKed 895 this RST is ouf of the servers recieve window (you also see that it doesn't trigger a DUP Ack...) so my strong suggestion is that the server ignores the RST

Actually I would expect the servers stack behaviour to be normal for preventing RST spoofing attacks in some way. He is perfectly sticking to the specs at least from my point of view

answered 12 Dec '11, 11:45

Landi's gravatar image

Landi
2.3k●5●14●42
accept rate: 28%

edited 12 Dec '11, 15:33

1

I'm not sure if I understand you completely. Let me expand. This sequence of packets was captured at the server side. The RST in frame 4 is a response on the data in frame 2 (which acknowledges the data up to the FIN, but not including the phantom byte of the FIN).

The client has no knowledge yet of frame 3, so it only sees that the server expects data at sequence number X (the X of frame 2), that would vote for seq=X for the RST.

However, the client has indeed sent a FIN, which means the phantom byte should be taken into account, so seq=X+1 would be logical too.

(12 Dec '11, 12:31) SYN-bit ♦♦

OK, now it gets interesting: If the client did not get frame 3 already he could in theory use X or X+1 as seq.nr. depending on the stacks way of implementing RST connection teardowns. Can you edit the scenario and insert timings and RTT? Just curious...

Once he recieves the servers ACK for it's FIN bit having arrived at the server, the client would be forced to send X+1 as RST seq.nr.

(12 Dec '11, 13:35) Landi

Landi, thanks for helping out... see the update on the Q for a link to the tracefile.

(12 Dec '11, 14:29) SYN-bit ♦♦

see my comments on answer edit - too few space here ;)

(12 Dec '11, 15:32) Landi

I second Landi's analysis, especially step 4 - from my point of view the RST has a SeqNo that is 1 byte to low and is probably discarded as invalid (out of receive window).

(16 Dec '11, 16:30) Jasper ♦♦

OK. I do agree that the RST is out-of-window and therefor is not accepted by the server. However, looking at it some more, I think the seq with which the client was sending it was also right. It responded to the frame with an ack with the same value.

The reason the server retransmitted over and over again is that there is a loadbalancer in between which stopped forwarding the frames properly after seeing the first RST. If it would have forwarded the packets, there would have been a frame with the higher ack which would trigger a RST with an in-window seq.

Thanks for both your insights :-)

(17 Dec '11, 02:56) SYN-bit ♦♦
showing 5 of 6 show 1 more comments