0

rst during hand shake

This finally turns out to be a Linux kernel bug which is not fixed yet by 2023/12/18. (See https://lore.kernel.org/lkml/[email protected])

---------------------------Original questions below------------------------------

Hi, We are suffering from very rare case, where the server send unexpected RST during 3 way handshake. There are two things i don't understand. (1) 238 is a PUSH and ACK sequence, while 240 is a pure ACK, they are with the same seqNo and ackNo, aren't they duplicated in ACK ?

(2) why the RST in 242 is send. It seemds the server(172.30.30.93) side is in SYN-RECEIVED state (it received SYN and send back SYN/ACK) , the RFC793 doc says maybe security reason or invalid ack. i'm sure it's not security reason, because the 8bit service field is not set. how can i tell if it's a valid ack?

3
  • 1
    Have you noticed the TCP checksum failures?
    – Zac67
    Commented Nov 23, 2023 at 14:49
  • Yes, this may be related to nic offloading configuration. I think they are not the cause, because I see many such checksum incorrect in normaly closed connections.
    – Milimili
    Commented Nov 30, 2023 at 3:43
  • Thanks for your update: since this seems to be a host issue, please post your latest addition to your question as new answer and accept it. Alternatively, please consider the other answer as it pointed in the same direction. If you don't ultimately accept an answer your question will keep popping up here forever.
    – Zac67
    Commented Dec 18, 2023 at 13:28

1 Answer 1

0

The packet in #238 (assuming it's part of the socket connection) showing only HTTP GET is a TCP segment, sending the HTTP request as payload. The subsequent ACK sends the sequence number ..6360, following up from the initial SYN's ..6359.

Since the segment with HTTP GET obviously needed to increase the SEQ, the ACK segment #240 is invalid and results in a RST. The client/initiator is malfunctioning.

I'd also investigate the TCP checksum errors on #236 and #244, and why the error in #236 seems to be ignored by the client/initiator.

The IP service type field (actually 6-bit DSCP - ToS was obsoleted in 1998) is completely irrelevant here or for security.

2
  • thank you for your answer. This is captured on the serverside, is it possible #240 is send by client before #238, because #240 seems to be the lask ACK of a 3-way handshake, does the order of packet a cause of the reset?(this may be a silly question, please pardon me being a rookie on net stack) I do see other request with ack before [push, ack] ends normaly with return 200 and tcp close normaly.
    – Milimili
    Commented Nov 30, 2023 at 3:14
  • With out-of-order segments, it's relevant which SEQ the HTTP GET segment used.
    – Zac67
    Commented Nov 30, 2023 at 7:18

Not the answer you're looking for? Browse other questions tagged or ask your own question.