Documentation/networking/mptcp-sysctl.rst | 18 +++++++++++++++++- net/mptcp/ctrl.c | 25 +++++++++++++++++++------ 2 files changed, 36 insertions(+), 7 deletions(-)
Recently, I found a network having weird behaviours with MPTCP packets:
- The first connection to a server had a successful 3WHS, then MPTCP
options got stripped off.
- The next one had the first SYN (with or without MPTCP) and 5
retransmissions dropped, before being apparently intercepted and
proxied to the end server.
- (The next ones were sometimes intercepted, sometimes not, or dropped
at the beginning. I'm trying to find out which kind of "optimiser" is
causing this.)
The result of this was a blackhole being "wrongly" detected, and no ways
to force connections with quite a few SYN drops to finally use MPTCP at
the end.
In this series, we have:
- A small fix for the doc.
- A new sysctl to change the number of SYN retransmitted with MPTCP
options before falling back to TCP. The modification looks simple
enough to still be sent to netdev before the closure I think.
- A fix to only turn on the blackhole protection only when the first SYN
retransmitted without MPTCP option is accepted, instead of any after.
The blackhole feature was supposed to do that from the beginning, but
a check was wrongly placed. I think we should consider this as a fix,
even if there are also risks of not detecting a blackhole if the first
SYN retransmitted without MPTCP is dropped by accident. But that seems
more unlikely for an "MPTCP firewall blackhole", and I guess not all
future MPTCP connections will behave exactly like that. It sounds then
safer to reduce the possibilities of enabling the blackhole protection
by accident, and apply this patch.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Matthieu Baerts (NGI0) (3):
doc: mptcp: sysctl: blackhole_timeout is per-netns
mptcp: sysctl: add syn_retrans_before_tcp_fallback
mptcp: blackhole only if 1st SYN retrans w/o MPC is accepted
Documentation/networking/mptcp-sysctl.rst | 18 +++++++++++++++++-
net/mptcp/ctrl.c | 25 +++++++++++++++++++------
2 files changed, 36 insertions(+), 7 deletions(-)
---
base-commit: 9336324d1aec351496e048ec5b6bbda07944ad16
change-id: 20250114-mpc-no-blackhole-526a61ea0334
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
On Tue, 14 Jan 2025, Matthieu Baerts (NGI0) wrote: > Recently, I found a network having weird behaviours with MPTCP packets: > > - The first connection to a server had a successful 3WHS, then MPTCP > options got stripped off. > > - The next one had the first SYN (with or without MPTCP) and 5 > retransmissions dropped, before being apparently intercepted and > proxied to the end server. > > - (The next ones were sometimes intercepted, sometimes not, or dropped > at the beginning. I'm trying to find out which kind of "optimiser" is > causing this.) > > The result of this was a blackhole being "wrongly" detected, and no ways > to force connections with quite a few SYN drops to finally use MPTCP at > the end. > > In this series, we have: > > - A small fix for the doc. > > - A new sysctl to change the number of SYN retransmitted with MPTCP > options before falling back to TCP. The modification looks simple > enough to still be sent to netdev before the closure I think. > Hi Matthieu - Patches 1 and 2 LGTM: Reviewed-by: Mat Martineau <martineau@kernel.org> > - A fix to only turn on the blackhole protection only when the first SYN > retransmitted without MPTCP option is accepted, instead of any after. > The blackhole feature was supposed to do that from the beginning, but > a check was wrongly placed. I think we should consider this as a fix, > even if there are also risks of not detecting a blackhole if the first > SYN retransmitted without MPTCP is dropped by accident. But that seems > more unlikely for an "MPTCP firewall blackhole", and I guess not all > future MPTCP connections will behave exactly like that. It sounds then > safer to reduce the possibilities of enabling the blackhole protection > by accident, and apply this patch. I have one comment on patch 3, see my reply there. - Mat > > Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> > --- > Matthieu Baerts (NGI0) (3): > doc: mptcp: sysctl: blackhole_timeout is per-netns > mptcp: sysctl: add syn_retrans_before_tcp_fallback > mptcp: blackhole only if 1st SYN retrans w/o MPC is accepted > > Documentation/networking/mptcp-sysctl.rst | 18 +++++++++++++++++- > net/mptcp/ctrl.c | 25 +++++++++++++++++++------ > 2 files changed, 36 insertions(+), 7 deletions(-) > --- > base-commit: 9336324d1aec351496e048ec5b6bbda07944ad16 > change-id: 20250114-mpc-no-blackhole-526a61ea0334 > > Best regards, > -- > Matthieu Baerts (NGI0) <matttbe@kernel.org> > > >
H Mat, On 17/01/2025 01:13, Mat Martineau wrote: > On Tue, 14 Jan 2025, Matthieu Baerts (NGI0) wrote: > >> Recently, I found a network having weird behaviours with MPTCP packets: >> >> - The first connection to a server had a successful 3WHS, then MPTCP >> options got stripped off. >> >> - The next one had the first SYN (with or without MPTCP) and 5 >> retransmissions dropped, before being apparently intercepted and >> proxied to the end server. >> >> - (The next ones were sometimes intercepted, sometimes not, or dropped >> at the beginning. I'm trying to find out which kind of "optimiser" is >> causing this.) >> >> The result of this was a blackhole being "wrongly" detected, and no ways >> to force connections with quite a few SYN drops to finally use MPTCP at >> the end. >> >> In this series, we have: >> >> - A small fix for the doc. >> >> - A new sysctl to change the number of SYN retransmitted with MPTCP >> options before falling back to TCP. The modification looks simple >> enough to still be sent to netdev before the closure I think. >> > > Hi Matthieu - > > Patches 1 and 2 LGTM: > > Reviewed-by: Mat Martineau <martineau@kernel.org> Thank you for the review! I already applied these two patches: New patches for t/upstream-net and t/upstream: - 34dc1c307f30: doc: mptcp: sysctl: blackhole_timeout is per-netns - Results: 1b76b0bd2522..551c1dba2a68 (export-net) - Results: 2a6dfa001e66..2d16bea74b90 (export) New patches for t/upstream: - 5fb87b001602: mptcp: sysctl: add syn_retrans_before_tcp_fallback - Results: 2d16bea74b90..b7be33140cc3 (export) Tests are now in progress: - export-net: https://github.com/multipath-tcp/mptcp_net-next/commit/70769bbce0f766c3583cb1caa791722685884f19/checks - export: https://github.com/multipath-tcp/mptcp_net-next/commit/caa6490e85f954f97ad955a2496c1b1297efee89/checks Cheers, Matt -- Sponsored by the NGI0 Core fund.
Hi Matthieu,
Thank you for your modifications, that's great!
Our CI did some validations and here is its report:
- KVM Validation: normal: Success! ✅
- KVM Validation: debug: Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Unstable: 1 failed test(s): bpftest_test_progs_mptcp 🔴
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/12773481101
Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/f4011cb563e8
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=925349
If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:
$ cd [kernel source code]
$ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
--pull always mptcp/mptcp-upstream-virtme-docker:latest \
auto-normal
For more details:
https://github.com/multipath-tcp/mptcp-upstream-virtme-docker
Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)
Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)
© 2016 - 2025 Red Hat, Inc.