Re: [PATCH mptcp-net v2 1/2] mptcp: pm: in-kernel: usable client side with C-flag

[Matthieu Baerts <matttbe@kernel.org>]

Hello,

On 16/09/2025 13:01, Matthieu Baerts (NGI0) wrote:
> When servers set the C-flag in their MP_CAPABLE to tell clients not to
> create subflows to the initial address and port, clients will likely not
> use their other endpoints. That's because the in-kernel path-manager
> uses the 'subflow' endpoints to create subflows only to the initial
> address and port.
> 
> If the limits have not been modified to accept ADD_ADDR, the client
> doesn't try to establish new subflows. If the limits accept ADD_ADDR,
> the routing routes will be used to select the source IP.
> 
> The C-flag is typically set when the server is operating behind a legacy
> Layer 4 load balancer, or using anycast IP address. Clients having their
> different 'subflow' endpoints setup, don't end up creating multiple
> subflows as expected, and causing some deployment issues.
> 
> A special case is then added here: when servers set the C-flag in the
> MPC and directly sends an ADD_ADDR, this single ADD_ADDR is accepted.
> The 'subflows' endpoints will then be used with this new remote IP and
> port. This exception is only allowed when the ADD_ADDR is sent
> immediately after the 3WHS, and makes the client switching to the 'fully
> established' mode. After that, 'select_local_address()' will not be able
> to find any subflows, because 'id_avail_bitmap' will be filled in
> mptcp_pm_create_subflow_or_signal_addr(), when switching to 'fully
> established' mode.
> 
> Fixes: df377be38725 ("mptcp: add deny_join_id0 in mptcp_options_received")
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/536
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> ---
> Notes:
> - I tried to find a simple solution that can hopefully be backported to
>   cover the 'CDN' use-case.
> - I tried to find a solution respecting the 'accepted add addr' limit,
>   but I don't see how to... That's why here I limit the exception a
>   maximum: when this limit is 0 (default case), only the first ADD_ADDR,
>   etc. Feel free to share what you think about that.
> - I have some additional code doing some cleanup, and I started to look
>   at #503, which is a bit linked to that.
> - v2: move conditions to new helper (Geliang) + rename var, squash comm.

(...)
> diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c
> index f30df8e884a0b3de9fb092e5774cafe08f6350ce..d7cd89fa6a11a1ea7703edbfbdf2bbe86a6a3054 100644
> --- a/net/mptcp/pm_kernel.c
> +++ b/net/mptcp/pm_kernel.c

(...)

> @@ -409,6 +411,10 @@ static unsigned int fill_local_addresses_vec(struct mptcp_sock *msk,
>  			locals[i].flags = entry->flags;
>  			locals[i].ifindex = entry->ifindex;
>  
> +			if (c_flag_case)

Small note: here, it should be:

  if (c_flag_case && (entry->flags & MPTCP_PM_ADDR_FLAG_SUBFLOW))

(but this doesn't change the global idea of this patch, I can apply it
when applying the patch)

> +				__clear_bit(locals[i].addr.id,
> +					    msk->pm.id_avail_bitmap);
> +
>  			/* Special case for ID0: set the correct ID */
>  			if (mptcp_addresses_equal(&locals[i].addr, &mpc_addr, locals[i].addr.port))
>  				locals[i].addr.id = 0;

(...)

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.