Page MenuHomeFreeBSD

Fix TCP Fast Open for TCP RACK
ClosedPublic

Authored by tuexen on Aug 26 2018, 9:10 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 20 2023, 3:00 AM
Unknown Object (File)
Nov 15 2023, 7:53 AM
Unknown Object (File)
Nov 7 2023, 1:07 AM
Unknown Object (File)
Nov 6 2023, 6:10 PM
Unknown Object (File)
Nov 6 2023, 7:12 AM
Unknown Object (File)
Oct 6 2023, 12:05 AM
Unknown Object (File)
Oct 5 2023, 5:09 PM
Unknown Object (File)
Oct 5 2023, 6:05 AM
Subscribers

Details

Summary

TCP Fast Open does not work currently in combination with TCP RACK. This patch fixes the RACK specific bugs for TCP Fast Open:

  • Fix a bug where the SYN handling during established state was applied to a front state.
  • Move a check for retransmission after the timer handling which was suppressing timer based retransmissions.
  • Fix an off-by one byte in the sequence number of retransmissions.
  • Apply fixes corresponding to r336934.
Test Plan

Run the following packetdrill scripts:

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

sys/netinet/tcp_stacks/rack.c
5403 ↗(On Diff #47317)

So no challenge ack is now sent. Is that going to cause a
problem with respect to RFC5961?

sys/netinet/tcp_stacks/rack.c
5403 ↗(On Diff #47317)

RFC 5961 requires this "in the synchronized" states. rfc793 states on page 32, for example:

If the receiving TCP is in a  non-synchronized state (i.e., SYN-SENT,
SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset.
If the TCP is in one of the synchronized states (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it
aborts the connection and informs its user.

The code taken out is in rack_do_syn_recv(), so this is not in a synchronized state as required by RFC 5961.

So I think it is fine to take it out.

This revision is now accepted and ready to land.Aug 28 2018, 5:00 AM
This revision was automatically updated to reflect the committed changes.