Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix MPTCP recipe #357

Merged
merged 3 commits into from
Jan 17, 2024
Merged

Fix MPTCP recipe #357

merged 3 commits into from
Jan 17, 2024

Conversation

Kuba314
Copy link
Contributor

@Kuba314 Kuba314 commented Jan 16, 2024

Description

This PR makes our MPTCP recipe actually test 2 flows. It also makes perf flows not bind on client ports, because currently there's a kernel bug which keeps ports open even after they're closed.

Tests

Tested manually, 2 subflows now work.

Reviews

@olichtne @jtluka

jtluka
jtluka previously approved these changes Jan 16, 2024
Copy link
Collaborator

@jtluka jtluka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Besides minor issue, looks ok

lnst/Recipes/ENRT/MPTCPRecipe.py Outdated Show resolved Hide resolved
rp_filter (reverse path filtering) is responsible for not allowing
responding to packets on a different interface than the packet appeared
on. It has to be disabled for MPTCP on IPv4.

IPv6 doesn't have rp_filter on sysfs, but firewalld or ip6tables might
configure it themselves. We do not run testing on machines where
firewalld is enabled, nor do we use ip6tables so no issues should
appear.
Apparently there's a difference between "adding an mptcp endpoint" and
"adding an mptcp endpoint to a device".

pyroute doesn't support dev in the `mptcp endpoint add` call so we have
to use a shell command. (svinota/pyroute2#782)
We are binding the client port to be consistent in multi-flow scenarios.
However, our mptcp scenario opens 2 additional ports and not one. Only
the first one binds to the specified client port, the second one is
random.

This would be fine, but there's a bug where mptcp doesn't close ports
immediately (RHEL-21492). This raises an "Address already in use" error
when the client attempts to bind the client port. We don't bind the
client port to mitigate this issue, but also because, as specified
before, it doesn't matter whether it's bound or not.
@olichtne olichtne merged commit 75a4160 into LNST-project:master Jan 17, 2024
3 checks passed
@Kuba314 Kuba314 deleted the mptcp branch January 17, 2024 13:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants