From: Jakub Kicinski Date: Tue, 16 Sep 2025 01:12:08 +0000 (-0700) Subject: Merge branch 'mptcp-pm-nl-announce-deny-join-id0-flag' X-Git-Tag: v6.17-rc7~18^2~19 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=97499e281823cbe622addad348779b889e99226e;p=thirdparty%2Fkernel%2Fstable.git Merge branch 'mptcp-pm-nl-announce-deny-join-id0-flag' Matthieu Baerts says: ==================== mptcp: pm: nl: announce deny-join-id0 flag 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. ==================== Link: https://patch.msgid.link/20250912-net-mptcp-pm-uspace-deny_join_id0-v1-0-40171884ade8@kernel.org Signed-off-by: Jakub Kicinski --- 97499e281823cbe622addad348779b889e99226e