From: Mat Martineau <martineau@kernel.org>
To: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
Cc: mptcp@lists.linux.dev
Subject: Re: [PATCH RFC mptcp-net 7/7] mptcp: pm: nl: announce deny-join-id0 attribute
Date: Thu, 4 Sep 2025 17:54:16 -0700 (PDT) [thread overview]
Message-ID: <c0361d0e-bbe8-d04b-2afd-4f27c3d30546@kernel.org> (raw)
In-Reply-To: <20250829-mptcp-pm-user-c-flag-v1-7-78b25dda7708@kernel.org>
On Fri, 29 Aug 2025, Matthieu Baerts (NGI0) wrote:
> During the connection establishment, a peer can tell the other 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 subflow 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.
>
> When a new connection is created and established, the Netlink events
> will now contain a new deny-join-id0 attribute. When set to 1, it means
> no other subflow to the initial IP address and port -- which is part of
> the event -- can be established.
>
> Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.1-20.6 [1]
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/532
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> ---
> This patch is marked as an RFC, just so we can agree on the attribute
> type: should we use a new dedicated attribute, or start using flags? It
> even looks like we have defined a "flags" attribute, but it is currently
> not used. Using "flags" would allow us to save some bytes, and in this
> case, 'server-side' should have used "flags" too. The problem with the
> flags is that the userspace cannot tell if a new flag is unset because
> the kernel doesn't support it, or because it doesn't need to be set. But
> is it really an issue? If the kernel doesn't support it, the userspace
> will probably not know what to do anyway. So fine to use flags? Or not
> needed, because it is unlikely to add new attributes later on?
>
> If yes, I suggest:
Hi Matthieu -
I do prefer 'flags' for this. It is the "C flag" after all :)
> - switching 'flags' to u32 instead of u16 because it doesn't change
> anything, and it is currently not used
There is already iproute2 code that references the 16-bit flags, even if
it is just for 'ip mptcp monitor'. Better to not alter the existing
userspace API here, especially in a -net patch.
> - deprecating the 'server-side' attribute, and adding it in the flags
> (but keeping it for the moment, maybe we can remove it in a few
> versions?)
Good idea, can duplicate the information between the server-side attribute
and flag for now. Then update mptcpd to prefer the flag version and remove
from the kernel sometime after that.
> - adding deny-join-id0 as a flag: MPTCP_PM_EVENT_FLAG_DENY_JOIN_ID0
Sounds like a good plan!
- Mat
> If no, we can use what is proposed here.
>
> In any cases, I would like to add a test. I initially added one in
> userspace_pm.sh, but due to "mptcp: pm: userspace: respect deny_join_id0
> attr", it is no longer possible to set allow_join_initial_addr_port
> sysctl knob to 0 there, as the value is no longer ignored by the
> userspace PM. Probably best to add a test in mptcp_join.sh.
> ---
> Documentation/netlink/specs/mptcp_pm.yaml | 7 +++++--
> include/uapi/linux/mptcp_pm.h | 5 +++--
> net/mptcp/pm_netlink.c | 4 ++++
> 3 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/netlink/specs/mptcp_pm.yaml b/Documentation/netlink/specs/mptcp_pm.yaml
> index d15335684ec3d6256505f2b3887ce5818eb57462..0b53d8b5b4524b6026009cfa4510e7a6e141acf1 100644
> --- a/Documentation/netlink/specs/mptcp_pm.yaml
> +++ b/Documentation/netlink/specs/mptcp_pm.yaml
> @@ -28,13 +28,13 @@ definitions:
> traffic-patterns it can take a long time until the
> MPTCP_EVENT_ESTABLISHED is sent.
> Attributes: token, family, saddr4 | saddr6, daddr4 | daddr6, sport,
> - dport, server-side.
> + dport, server-side, deny-join-id0.
> -
> name: established
> doc: >-
> A MPTCP connection is established (can start new subflows).
> Attributes: token, family, saddr4 | saddr6, daddr4 | daddr6, sport,
> - dport, server-side.
> + dport, server-side, deny-join-id0.
> -
> name: closed
> doc: >-
> @@ -266,6 +266,9 @@ attribute-sets:
> -
> name: server-side
> type: u8
> + -
> + name: deny-join-id0
> + type: u8
>
> operations:
> list:
> diff --git a/include/uapi/linux/mptcp_pm.h b/include/uapi/linux/mptcp_pm.h
> index 6ac84b2f636ca22935c191c645449fb62b673899..6c751c488e51d6ab711607189041d5e2ea222e4e 100644
> --- a/include/uapi/linux/mptcp_pm.h
> +++ b/include/uapi/linux/mptcp_pm.h
> @@ -16,10 +16,10 @@
> * good time to allocate memory and send ADD_ADDR if needed. Depending on the
> * traffic-patterns it can take a long time until the MPTCP_EVENT_ESTABLISHED
> * is sent. Attributes: token, family, saddr4 | saddr6, daddr4 | daddr6,
> - * sport, dport, server-side.
> + * sport, dport, server-side, deny-join-id0.
> * @MPTCP_EVENT_ESTABLISHED: A MPTCP connection is established (can start new
> * subflows). Attributes: token, family, saddr4 | saddr6, daddr4 | daddr6,
> - * sport, dport, server-side.
> + * sport, dport, server-side, deny-join-id0.
> * @MPTCP_EVENT_CLOSED: A MPTCP connection has stopped. Attribute: token.
> * @MPTCP_EVENT_ANNOUNCED: A new address has been announced by the peer.
> * Attributes: token, rem_id, family, daddr4 | daddr6 [, dport].
> @@ -126,6 +126,7 @@ enum mptcp_event_attr {
> MPTCP_ATTR_RESET_REASON,
> MPTCP_ATTR_RESET_FLAGS,
> MPTCP_ATTR_SERVER_SIDE,
> + MPTCP_ATTR_DENY_JOIN_ID0,
>
> __MPTCP_ATTR_MAX
> };
> diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c
> index 50aaf259959aeaf36e7ab954c6f7957eaf2bc390..93455b63ef80395ff19f40d84cd28438a3578b98 100644
> --- a/net/mptcp/pm_netlink.c
> +++ b/net/mptcp/pm_netlink.c
> @@ -415,6 +415,10 @@ static int mptcp_event_created(struct sk_buff *skb,
> if (nla_put_u8(skb, MPTCP_ATTR_SERVER_SIDE, READ_ONCE(msk->pm.server_side)))
> return -EMSGSIZE;
>
> + if (nla_put_u8(skb, MPTCP_ATTR_DENY_JOIN_ID0,
> + READ_ONCE(msk->pm.remote_deny_join_id0)))
> + return -EMSGSIZE;
> +
> return mptcp_event_add_subflow(skb, ssk);
> }
>
>
> --
> 2.50.1
>
>
>
next prev parent reply other threads:[~2025-09-05 0:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-29 20:33 [PATCH mptcp-net 0/7] mptcp: pm: nl: announce deny-join-id0 attribute Matthieu Baerts (NGI0)
2025-08-29 20:33 ` [PATCH mptcp-net 1/7] mptcp: set remote_deny_join_id0 on SYN recv Matthieu Baerts (NGI0)
2025-08-29 20:33 ` [PATCH mptcp-net 2/7] mptcp: pm: userspace: respect deny_join_id0 attr Matthieu Baerts (NGI0)
2025-08-29 20:54 ` Christoph Paasch
2025-08-30 0:58 ` Mat Martineau
2025-09-01 10:08 ` Matthieu Baerts
2025-09-02 16:43 ` Christoph Paasch
2025-09-02 16:58 ` Matthieu Baerts
2025-08-29 20:33 ` [PATCH mptcp-net 3/7] mptcp: tfo: record 'deny join id0' info Matthieu Baerts (NGI0)
2025-09-06 14:05 ` Geliang Tang
2025-09-06 14:19 ` Matthieu Baerts
2025-09-10 3:56 ` Geliang Tang
2025-08-29 20:33 ` [PATCH mptcp-net 4/7] netlink: specs: mptcp: fix if-idx attribute type Matthieu Baerts (NGI0)
2025-09-06 14:16 ` Geliang Tang
2025-09-08 17:16 ` Matthieu Baerts
2025-09-06 14:18 ` Geliang Tang
2025-09-06 14:19 ` Geliang Tang
2025-08-29 20:33 ` [PATCH mptcp-net 5/7] doc: mptcp: net.mptcp.pm_type is deprecated Matthieu Baerts (NGI0)
2025-08-29 20:33 ` [PATCH mptcp-net 6/7] selftests: mptcp: shellcheck: support v0.11.0 Matthieu Baerts (NGI0)
2025-08-29 20:33 ` [PATCH RFC mptcp-net 7/7] mptcp: pm: nl: announce deny-join-id0 attribute Matthieu Baerts (NGI0)
2025-09-05 0:54 ` Mat Martineau [this message]
2025-09-08 17:17 ` Matthieu Baerts
2025-08-29 23:18 ` [PATCH mptcp-net 0/7] " MPTCP CI
2025-09-08 17:22 ` Matthieu Baerts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c0361d0e-bbe8-d04b-2afd-4f27c3d30546@kernel.org \
--to=martineau@kernel.org \
--cc=matttbe@kernel.org \
--cc=mptcp@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox