Page MenuHomeFreeBSD

Fix SACK generation when dealing with SYN segments carrying user data
ClosedPublic

Authored by tuexen on Mar 22 2021, 1:05 PM.
Tags
None
Referenced Files
Unknown Object (File)
Oct 4 2024, 7:35 PM
Unknown Object (File)
Oct 4 2024, 7:03 AM
Unknown Object (File)
Oct 3 2024, 10:37 PM
Unknown Object (File)
Oct 2 2024, 5:42 AM
Unknown Object (File)
Oct 2 2024, 12:14 AM
Unknown Object (File)
Sep 29 2024, 10:42 PM
Unknown Object (File)
Sep 27 2024, 9:39 PM
Unknown Object (File)
Sep 21 2024, 12:31 AM

Details

Summary

When handling a SYN segment with user data in the SYN-SENT state, a DSACK is generated, which is incorrect. This patch fixes this.

Test Plan

Run the following tests from the TCP state event test suite:

  • state-event-engine/rcv-syn-fin-syn-sent/rcv-syn-fin-with-data-syn-sent-dropping-disabled-ipv4.pkt
  • state-event-engine/rcv-syn-fin-syn-sent/rcv-syn-fin-with-data-syn-sent-dropping-disabled-ipv6.pkt
  • state-event-engine/rcv-syn-syn-sent/rcv-syn-with-data-syn-sent-ipv4.pkt
  • state-event-engine/rcv-syn-syn-sent/rcv-syn-with-data-syn-sent-ipv6.pkt

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Thanks for updating the packetdrill scripts to match recent improvements too.

This revision is now accepted and ready to land.Mar 22 2021, 1:57 PM

Gave this a 2nd thought, but still think that the check if the session state has transitioned to established overall is the correct approach.

Or would there be any conceiveable paths, where either a DSACK or SACK could be triggerend from a data-SYN?

(Only a DSACK on the receipt of a duplicate data-SYN comes to mind, or when the data-SYN chances in size between the first observed / 2nd receipt. But in these cases, the session would be established too...)

This revision was automatically updated to reflect the committed changes.