Documentation/netlink/specs/mptcp_pm.yaml | 4 ++-- include/uapi/linux/mptcp.h | 2 ++ include/uapi/linux/mptcp_pm.h | 4 ++-- net/mptcp/options.c | 6 +++--- net/mptcp/pm_netlink.c | 9 ++++++++- net/mptcp/subflow.c | 4 ++++ tools/testing/selftests/net/mptcp/pm_nl_ctl.c | 7 +++++++ tools/testing/selftests/net/mptcp/userspace_pm.sh | 14 +++++++++++--- 8 files changed, 39 insertions(+), 11 deletions(-)
During the connection establishment, a peer can tell the other one that
it cannot establish new subflows to the initial IP address and port by
setting the 'C' flag [1]. Doing so makes sense when the sender is behind
a strict NAT, operating behind a legacy Layer 4 load balancer, or using
anycast IP address for example.
When this 'C' flag is set, the path-managers must then not try to
establish new subflows to the other peer's initial IP address and port.
The in-kernel PM has access to this info, but the userspace PM didn't,
not letting the userspace daemon able to respect the RFC8684.
Here are a few fixes related to this 'C' flag (aka 'deny-join-id0'):
- Patch 1: fix a small typo in if-idx type. A fix for v5.10.
- Patch 2: add remote_deny_join_id0 info on passive connections. A fix
for v5.14.
- Patch 3: let the userspace PM daemon know about the deny_join_id0
attribute, so when set, it can avoid creating new subflows to the
initial IP address and port. A fix for v5.19.
- Patch 4: a validation for the previous commit.
- Patch 5: record the deny_join_id0 info when TFO is used. A fix for
v6.2.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Changes in v2:
- Former patches 4-6 have been already applied
- Former patch 2 has been dropped (Christoph)
- Patch 1 is new, not linked to deny-join-id0
- Patch 3 replaces former patch 2, and was linked to former patch 7, but
now using 'flags' instead of a new dedicated attribute (Mat)
- Notes: changes for net-next, and the deprecation of server-flags will
be part of another series.
- Link to v1: https://lore.kernel.org/r/20250829-mptcp-pm-user-c-flag-v1-0-78b25dda7708@kernel.org
---
Matthieu Baerts (NGI0) (5):
mptcp: pm: netlink: fix if-idx type
mptcp: set remote_deny_join_id0 on SYN recv
mptcp: pm: nl: announce deny-join-id0 flag
selftests: mptcp: userspace pm: validate deny-join-id0 flag
mptcp: tfo: record 'deny join id0' info
Documentation/netlink/specs/mptcp_pm.yaml | 4 ++--
include/uapi/linux/mptcp.h | 2 ++
include/uapi/linux/mptcp_pm.h | 4 ++--
net/mptcp/options.c | 6 +++---
net/mptcp/pm_netlink.c | 9 ++++++++-
net/mptcp/subflow.c | 4 ++++
tools/testing/selftests/net/mptcp/pm_nl_ctl.c | 7 +++++++
tools/testing/selftests/net/mptcp/userspace_pm.sh | 14 +++++++++++---
8 files changed, 39 insertions(+), 11 deletions(-)
---
base-commit: 12e66f7051b4b535a990cd20c149d76a98ec68c3
change-id: 20250720-mptcp-pm-user-c-flag-a7d5d7a00c6f
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
On Tue, 9 Sep 2025, Matthieu Baerts (NGI0) wrote: > During the connection establishment, a peer can tell the other one that > it cannot establish new subflows to the initial IP address and port by > setting the 'C' flag [1]. Doing so makes sense when the sender is behind > a strict NAT, operating behind a legacy Layer 4 load balancer, or using > anycast IP address for example. > > When this 'C' flag is set, the path-managers must then not try to > establish new subflows to the other peer's initial IP address and port. > The in-kernel PM has access to this info, but the userspace PM didn't, > not letting the userspace daemon able to respect the RFC8684. > > Here are a few fixes related to this 'C' flag (aka 'deny-join-id0'): > > - Patch 1: fix a small typo in if-idx type. A fix for v5.10. > > - Patch 2: add remote_deny_join_id0 info on passive connections. A fix > for v5.14. > > - Patch 3: let the userspace PM daemon know about the deny_join_id0 > attribute, so when set, it can avoid creating new subflows to the > initial IP address and port. A fix for v5.19. > > - Patch 4: a validation for the previous commit. > > - Patch 5: record the deny_join_id0 info when TFO is used. A fix for > v6.2. > > Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> > --- > Changes in v2: > - Former patches 4-6 have been already applied > - Former patch 2 has been dropped (Christoph) > - Patch 1 is new, not linked to deny-join-id0 > - Patch 3 replaces former patch 2, and was linked to former patch 7, but > now using 'flags' instead of a new dedicated attribute (Mat) > - Notes: changes for net-next, and the deprecation of server-flags will > be part of another series. > - Link to v1: https://lore.kernel.org/r/20250829-mptcp-pm-user-c-flag-v1-0-78b25dda7708@kernel.org > Hi Matthieu - v2 full series LGTM, thanks for reworking to use the existing 'flags' attribute. Agree with the plans for net-next and deprecation of server-flags. Reviewed-by: Mat Martineau <martineau@kernel.org> > --- > Matthieu Baerts (NGI0) (5): > mptcp: pm: netlink: fix if-idx type > mptcp: set remote_deny_join_id0 on SYN recv > mptcp: pm: nl: announce deny-join-id0 flag > selftests: mptcp: userspace pm: validate deny-join-id0 flag > mptcp: tfo: record 'deny join id0' info > > Documentation/netlink/specs/mptcp_pm.yaml | 4 ++-- > include/uapi/linux/mptcp.h | 2 ++ > include/uapi/linux/mptcp_pm.h | 4 ++-- > net/mptcp/options.c | 6 +++--- > net/mptcp/pm_netlink.c | 9 ++++++++- > net/mptcp/subflow.c | 4 ++++ > tools/testing/selftests/net/mptcp/pm_nl_ctl.c | 7 +++++++ > tools/testing/selftests/net/mptcp/userspace_pm.sh | 14 +++++++++++--- > 8 files changed, 39 insertions(+), 11 deletions(-) > --- > base-commit: 12e66f7051b4b535a990cd20c149d76a98ec68c3 > change-id: 20250720-mptcp-pm-user-c-flag-a7d5d7a00c6f > > Best regards, > -- > Matthieu Baerts (NGI0) <matttbe@kernel.org> > > >
Hi Mat, On 10/09/2025 20:17, Mat Martineau wrote: > On Tue, 9 Sep 2025, Matthieu Baerts (NGI0) wrote: > >> During the connection establishment, a peer can tell the other one that >> it cannot establish new subflows to the initial IP address and port by >> setting the 'C' flag [1]. Doing so makes sense when the sender is behind >> a strict NAT, operating behind a legacy Layer 4 load balancer, or using >> anycast IP address for example. >> >> When this 'C' flag is set, the path-managers must then not try to >> establish new subflows to the other peer's initial IP address and port. >> The in-kernel PM has access to this info, but the userspace PM didn't, >> not letting the userspace daemon able to respect the RFC8684. >> >> Here are a few fixes related to this 'C' flag (aka 'deny-join-id0'): >> >> - Patch 1: fix a small typo in if-idx type. A fix for v5.10. >> >> - Patch 2: add remote_deny_join_id0 info on passive connections. A fix >> for v5.14. >> >> - Patch 3: let the userspace PM daemon know about the deny_join_id0 >> attribute, so when set, it can avoid creating new subflows to the >> initial IP address and port. A fix for v5.19. >> >> - Patch 4: a validation for the previous commit. >> >> - Patch 5: record the deny_join_id0 info when TFO is used. A fix for >> v6.2. >> >> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> >> --- >> Changes in v2: >> - Former patches 4-6 have been already applied >> - Former patch 2 has been dropped (Christoph) >> - Patch 1 is new, not linked to deny-join-id0 >> - Patch 3 replaces former patch 2, and was linked to former patch 7, but >> now using 'flags' instead of a new dedicated attribute (Mat) >> - Notes: changes for net-next, and the deprecation of server-flags will >> be part of another series. >> - Link to v1: https://lore.kernel.org/r/20250829-mptcp-pm-user-c-flag- >> v1-0-78b25dda7708@kernel.org >> > > Hi Matthieu - > > v2 full series LGTM, thanks for reworking to use the existing 'flags' > attribute. Agree with the plans for net-next and deprecation of server- > flags. > > Reviewed-by: Mat Martineau <martineau@kernel.org> Thank you for the review! Now in our tree (fixes for -net): New patches for t/upstream-net and t/upstream: - 0da1c0ce6ea6: mptcp: pm: netlink: fix if-idx type - 02cda1074a73: mptcp: set remote_deny_join_id0 on SYN recv - a09491ca4e0f: mptcp: pm: nl: announce deny-join-id0 flag - 6eae6b2bd22f: selftests: mptcp: userspace pm: validate deny-join-id0 flag - 401a4e407eaa: mptcp: tfo: record 'deny join id0' info - Results: c3bb5aa20b8e..28a9147c96c2 (export-net) - Results: 6ff9d54223e3..9d5b2844a3ca (export) Tests are now in progress: - export-net: https://github.com/multipath-tcp/mptcp_net-next/commit/1bb915f2a5144a56b8fa183b1141d05268ac0f97/checks - export: https://github.com/multipath-tcp/mptcp_net-next/commit/42b19ffa9551df01889230fa9e6228e61b18bffc/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: Critical: KMemLeak ❌
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/17586663636
Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/94bc72bd6390
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1000542
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)
Hello, On 09/09/2025 18:27, MPTCP CI wrote: > 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: Critical: KMemLeak ❌ It looks like this one is linked to: https://github.com/multipath-tcp/mptcp_net-next/issues/583 (and maybe a false positive?) Anyway, for this series, we can then read: KVM Validation: debug: Success! ✅ Cheers, Matt -- Sponsored by the NGI0 Core fund.
© 2016 - 2025 Red Hat, Inc.