Daire reported a few issues with MPTCP where some connections were stalled in different states. Paolo did a great job fixing them.
Patch 1 fixes bogus receive window shrinkage with multiple subflows. Due to a race condition and unlucky circumstances, that may lead to TCP-level window shrinkage, and the connection being stalled on the sender end.
Patch 2 is a preparation for patch 3 which processes pending subflow errors on close. Without that and under specific circumstances, the MPTCP-level socket might not switch to the CLOSE state and stall.
Patch 4 is also a preparation patch for the next one. Patch 5 fixes MPTCP connections not switching to the CLOSE state when all subflows have been closed but no DATA_FIN have been exchanged to explicitly close the MPTCP connection. Now connections in such state will switch to the CLOSE state after a timeout, still allowing the "make-after-break" feature but making sure connections don't stall forever. It will be possible to modify this timeout -- currently matching TCP TIMEWAIT value (60 seconds) -- in a future version.
Signed-off-by: Matthieu Baerts matthieu.baerts@tessares.net --- Paolo Abeni (5): mptcp: fix bogus receive window shrinkage with multiple subflows mptcp: move __mptcp_error_report in protocol.c mptcp: process pending subflow error on close mptcp: rename timer related helper to less confusing names mptcp: fix dangling connection hang-up
net/mptcp/options.c | 5 +- net/mptcp/protocol.c | 165 +++++++++++++++++++++++++++++++-------------------- net/mptcp/protocol.h | 24 +++++++- net/mptcp/subflow.c | 39 +----------- 4 files changed, 130 insertions(+), 103 deletions(-) --- base-commit: 615efed8b63f60ddd69c0b8f32f7783859034fc2 change-id: 20230915-upstream-net-20230915-mptcp-hanging-conn-0609338b1728
Best regards,