Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Hmm... Note that this section of code covers the incoming SACK blocks. Those that indicate positive reception of the associated sequence number by the remote side.
While it is rather uncommon (never observed this in the wild) for a tcp stack to SACK the FIN bit, nothing in the RFCs prevents that from happening.
This change would effectively decline acknowleding any SACK block which also includes the FIN - and cause spurious retransmissions of already received data (unless there is a cummulative ack - again including the FIN - quickly enough).
IIRC, i did run testcases with incoming SACK block which only covered the final data (snd_max-1), as well as the FIN bit (snd_max).
This issue we are currently having is, that rarely, snd_max is incremented repeatedly (probably while resending the FIN bit). Logically, the sequence space doesn't look like {<SYN>[data]<FIN>} but {<SYN>[data]<FIN><FIN><FIN>} with the base stack. It appears that these multiple FINs in the sequence space have been a problem for some time, but prior to SACK rescue retransmissions, never showed up negatively unless someone had managed to capture such a very rare and fleeting session where that happens... And then it would only be a fluke in a packet capture without data consistency impact.