On Mon, 28 Sep 2026 13:31:20 +0300
Aris Konstantoulas
[...]
Don't consider a duplicate ACK as a fast re-transmit trigger if the only outstanding sequence number is the FIN, and leave it to the timer. Fast re-transmit of data is unaffected, with or without a FIN queued after it.
Thanks for the investigation and for the patch, I'll review it in a bit! Just a couple of quick (hopefully helpful) remarks for now:
[...]
- Open question: I haven't established how a real flow first reaches the state where the peer ACKs exactly up to, but not past, our FIN.
If I recall correctly, a while ago, I managed to make this happen with a Linux kernel as peer, under memory pressure, with the receiver updating the remaining buffer estimation right after processing a large segment (the last data segment) that's assembled from smaller segments. You would need a slow userspace receiver as well (maybe reading exactly one byte after accepting the connection and then nothing else... something like that). In any case, I don't think it really matters to find a "natural" reproducer of this case, I wouldn't go crazy with it, your patch looks obviously correct to me anyway.
[...] This patch breaks the loop in either case, but not that possible entry path. I'm happy to look into it further, possibly as part of bug 125.
Wow, yes, if you could also tackle bug #125, or even a part of it, that would be very warmly appreciated! -- Stefano