mptcp: new DATA_FIN retrans tests #181
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The MPTCP CI recently caught an issue with the mptcp_connect.sh test, where one subtest timeout. When this happens, 'ss -Mt' reports: - listener: - tcp ESTAB - mptcp LAST-ACK - connector: - tcp ESTAB - mptcp FIN-WAIT-2 As spotted by Paolo, all bytes have been exchanged, the last data packet has been received 60 seconds ago. So it looks like one data-fin didn't get retransmitted. In this case, both sides have the connection closed by the userspace: data-fin have been sent to be in such MPTCP states. The listener sent a data-fin, and is waiting for an ACK. The connector side is waiting for a data-fin. That's what the two new tests are checking: - Is the data-fin retransmitted as expected? - Is the data-fin ACK retransmitted when received with a delay? These tests pass with the current MPTCP tree. Link: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/19047087376 Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
We were suspecting this case not to be supported, but it is apparently. After having closed the connection, some data are injected with the FIN. It is still possible to read them after the close(). Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Member
Author
|
Just added a few new tests: they pass on the |
To make sure data are not exchanged after a data-fin, and see if it is possible to read data after the shutdown(). Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
matttbe
force-pushed
the
dss-fin-retrans-last-ack-fin-wait2
branch
from
b14f78c to
99fe905
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The MPTCP CI recently caught an issue with the mptcp_connect.sh test, where one subtest timeout.
When this happens, 'ss -Mt' reports:
listener:
connector:
As spotted by Paolo, all bytes have been exchanged, the last data packet has been received 60 seconds ago. So it looks like one data-fin didn't get retransmitted.
In this case, both sides have the connection closed by the userspace: data-fin have been sent to be in such MPTCP states. The listener sent a data-fin, and is waiting for an ACK. The connector side is waiting for a data-fin.
That's what the two new tests are checking:
Is the data-fin retransmitted as expected?
Is the data-fin ACK retransmitted when received with a delay?
These tests pass with the current MPTCP tree.
Link: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/19047087376