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: add remote_deny_join_id0 info on passive connections. A fix
  for v5.14.

- Patch 2: 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 3: a validation for the previous commit.

- Patch 4: record the deny_join_id0 info when TFO is used. A fix for
  v6.2.

- Patch 5: not related to deny-join-id0, but it fixes errors messages in
  the sockopt selftests, not to create confusions. A fix for v6.5.

Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Geliang Tang (1):
      selftests: mptcp: sockopt: fix error messages

Matthieu Baerts (NGI0) (4):
      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                            |  7 +++++++
 net/mptcp/subflow.c                               |  4 ++++
 tools/testing/selftests/net/mptcp/mptcp_sockopt.c | 16 ++++++++++------
 tools/testing/selftests/net/mptcp/pm_nl_ctl.c     |  7 +++++++
 tools/testing/selftests/net/mptcp/userspace_pm.sh | 14 +++++++++++---
 9 files changed, 48 insertions(+), 16 deletions(-)
---
base-commit: 2690cb089502b80b905f2abdafd1bf2d54e1abef
change-id: 20250912-net-mptcp-pm-uspace-deny_join_id0-b6111e4e7e69

Best regards,
-- 
Matthieu Baerts (NGI0) <matttbe@kernel.org>

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Fri, 12 Sep 2025 14:52:19 +0200 you 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 is the summary with links:
  - [net,1/5] mptcp: set remote_deny_join_id0 on SYN recv
    https://git.kernel.org/netdev/net/c/96939cec9940
  - [net,2/5] mptcp: pm: nl: announce deny-join-id0 flag
    https://git.kernel.org/netdev/net/c/2293c57484ae
  - [net,3/5] selftests: mptcp: userspace pm: validate deny-join-id0 flag
    https://git.kernel.org/netdev/net/c/24733e193a0d
  - [net,4/5] mptcp: tfo: record 'deny join id0' info
    https://git.kernel.org/netdev/net/c/92da495cb657
  - [net,5/5] selftests: mptcp: sockopt: fix error messages
    https://git.kernel.org/netdev/net/c/b86418beade1

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html