diff options
author | Jakub Kicinski <kuba@kernel.org> | 2025-09-15 18:12:08 -0700 |
---|---|---|
committer | Jakub Kicinski <kuba@kernel.org> | 2025-09-15 18:12:08 -0700 |
commit | 97499e281823cbe622addad348779b889e99226e (patch) | |
tree | af2f1968c2648d8c30a3fca890824517e316f04d /scripts/gdb/linux/vmalloc.py | |
parent | 33a09c64c2f5a25e88636bf177c0971d5b688bfe (diff) | |
parent | b86418beade11d45540a2d20c4ec1128849b6c27 (diff) |
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 <kuba@kernel.org>
Diffstat (limited to 'scripts/gdb/linux/vmalloc.py')
0 files changed, 0 insertions, 0 deletions