Kees Cook: You are correct that the client and server get in a retransmission loop that gets longer and longer delays. Unfortunately for the client, it means the client does not get the data it is waiting for (if the protocol is the client needing data from the server). Eventually either the client, or a hub / switch / etc. along the way, tends to eventually send an RSYN, causing the connection to get closed out and terminated prematurely. Yes, the client continues to ack the server and waits for the next (needed) packet that never comes.
At this time I do not have a way to exercise the bug that I can make public. I will say that it significantly helps if the client turns off the SACK (Selective Acknowledgement) TCP option when you want to exercise the bug. The mailing list report used a large TCP window size on the client end. I hit it with a small TCP window size (and poor handling of out-of-order packets) on the client end. -- TCP stack bug related to F-RTO https://bugs.launchpad.net/bugs/567394 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
