0

Several sources (one being my colleague and the other being TCP/IP Illustrated by Stevens) indicate that there should be a RST sent after the TCP retransmission attempts have been exhausted. I have not been able to find something that would mandate this in TCP protocol RFCs, however, this does sound reasonable to me. I've experimented with 2 Linux VMs (kernel v4.4 and v5.10) by setting sysctl tcp_reties2 parameter to 3, starting a data transfer and then disconnecting the second VMs eth "cable" and neither of two send a RST after the last unsuccessful retransmission. Calling close() on the socket with SO_LINGER set to 0 after the retransmissions have been exhausted did not work either (I figure this is because the socket is already in disconnected state by that time). Is there some way to make Linux send a RST in this case?

Zvej
  • 1
  • 1
  • Can you quote specifically from TCP/IP Illustrated? I don't see anything in the RFC about this from a quick look. – Michael Hampton Feb 02 '21 at 11:26
  • *Lines 7-18 are 12 retransmissions of that segment, and line 19 is when the sending TCP finally gives up and sends a reset* - This is from page 299 of the first edition – Zvej Feb 02 '21 at 13:38
  • That doesn't really say that it's required, just that it happened in one illustrated case. – Michael Hampton Feb 02 '21 at 13:54
  • I agree. Just came across another example, this time from Microsoft docmentation here https://docs.microsoft.com/en-us/windows/client-management/troubleshoot-tcpip-connectivity, under Packet Drops it says: *When one TCP peer is sending out TCP packets for which there is no response received from the other end, the TCP peer would end up retransmitting the data and when there is no response received, it would end the session by sending an ACK RESET (this means that the application acknowledges whatever data is exchanged so far, but because of packet drop, the connection is closed).* – Zvej Feb 02 '21 at 15:41
  • That is also an implementation detail, not requirement by RFC. – Tero Kilkanen Feb 02 '21 at 16:46
  • Agreed, as stated in the question, it seems that RFC does not explicitly specify what should happen on the wire after the stack gives up on retransmitting. I guess this is an implementation detail that can't be changed through sysctl or socket options – Zvej Feb 02 '21 at 17:06
  • I'll keep this unanswered in the hope that someone knows/can come up with a way to make Linux stack send RST after retransmissions fail – Zvej Feb 05 '21 at 16:30

0 Answers0