ASome client SACKing the FIN bit may cause ans (iOS, macOS, dragonflyBSD) will
off-by-one accessSACK the FIN bit, due to a long dormant
bug in the tcp_sack_doack() acceptanceif it is sent during loss
check for incoming SACK blocksrecovery while loss may be still ongoing.
It is likely that the new PRR mechanism,One PR 254725 has been reported, where this may
by reducing self-inflihave come into play. In order to avoid any
unexpected packet lossinteractions due to SACKed FINs,
significantly increased the probabiliy to
elicit this misbehaviormake sure to send the FIN only, when all
data is acknowledged in full by the client.