From nobody Mon Sep 16 19:27:00 2024 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F2FF13777F for ; Fri, 21 Jun 2024 11:39:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718969967; cv=none; b=WuFf2NaWpQlzXF5E/3Jh+emw2cqAcH4LwsfwGCpxkKD65BG3FDlqF+pln3gy7sPqe2hUKHQLhf4dSAtkyDRXD9l1jirlkQZ6oLNPgpzFi4gAJeNDF+Ejgz5HZ8jAGZIiyIhbdKgPCtjkQz1iu3vMPtkCpyg6DV/bkowUQD4OrWU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718969967; c=relaxed/simple; bh=Y6VXgJW8GgtqI5kCBA/qVF/VuXTnQ1NUPzKFUkh7sRM=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=JPwX1tP6P9yQS0tSIsNFfqB+aGsTATodqRknKYCtSF1zW43pzp2kGlKWkDIlKl/oe+RGcnMaUARKUDkEsTAuy+mJXjPOjaqR+xR0XFIYWHKfyxT0P4dCDw7EL9Ls4Q3vZTB3adkZcGhkASoL/ajTgOIVxsF8VQ09yh4rYQptuGg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bgceCfSg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bgceCfSg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F4215C4AF09; Fri, 21 Jun 2024 11:39:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718969966; bh=Y6VXgJW8GgtqI5kCBA/qVF/VuXTnQ1NUPzKFUkh7sRM=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=bgceCfSg39lGkslEP61W+GTbM3rZKLzMF6z9qZDYUFhEotaxcCeasViAEtfxj0+me 0lxApBTw6WsyMLDi3tuRtkirDlp+YvJ/AkxrRA0xDzbMNZlL4SBOTe2lDwt3A3dYYG lSxnbIW6QfPHfeNszZVlW8PRldDRVPKRkfN1WBKfKm/nkHQPd6tDNSTEYvytQF0O6C 0aOP+IdMt81Ot1Xux3TQL650D/+T+/6yUrvjTIVVpgbYSuc0+ppvUtHovNctYcSTfJ /bc0dT9CEUNvb0JIl1vV1Xy0+021bKcYoRdJhNVqc++TTvJiKJDs8Kkm8IP+PcNgFO LM5z9OD6tY9OQ== From: "Matthieu Baerts (NGI0)" Date: Fri, 21 Jun 2024 13:39:07 +0200 Subject: [PATCH mptcp-next 1/4] mptcp: fully established after ADD_ADDR echo on MPJ Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20240621-mptcp-pm-avail-v1-1-b692d5eb89b5@kernel.org> References: <20240621-mptcp-pm-avail-v1-0-b692d5eb89b5@kernel.org> In-Reply-To: <20240621-mptcp-pm-avail-v1-0-b692d5eb89b5@kernel.org> To: mptcp@lists.linux.dev Cc: Paolo Abeni , "Matthieu Baerts (NGI0)" X-Mailer: b4 0.14.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1655; i=matttbe@kernel.org; h=from:subject:message-id; bh=Y6VXgJW8GgtqI5kCBA/qVF/VuXTnQ1NUPzKFUkh7sRM=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBmdWZsXO97qRQ2BltmnwNx/frP5e28XURLAe+DR czRpcfqnomJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZnVmbAAKCRD2t4JPQmmg c8RPD/9oW9zVr7eh10bppjyOPQIcN02JDpxiVgJS5jmQ63xi8eYfo+j8CHMe9AEw8gOx6UrV/r3 eZO8fL9cyFCSKj7P40A63dumH1iKQt4dkpsOVm+SHFvNyj5a7zHGdFx5X/opMImfFg5KrMywFQQ D9buWu1sG8/iKGoCznxiikhQsrSPYoc3dNpq9iYhc7wCLy7hEpjaxTDmwS9e53L2zahR5N60Shv lD3EuDW7VzmKuHlMipHmAwBouboGNX++HM31dXitaanehD+hdgUd8wctwXxc10P04UkpXQyRCnB zWtm85xyOBdLHO4meUVUPUQR3mSWBk8iwQ2ee0uVmDtQuOsKKr34dAOYfD2Ui15FXN5UV2Jglia t+whaNdU1s9a6eJdGvLxfzwZbVm6IHm+mW+95Zs0sf+Qrkrb/QKbwBmYlE8jyxSiPE1Wg3YmSFL o49TLgviks3B/ICfZDswI2wINKiWpWORE5smCRDhHNoVMscRadkMOoPDzE8SNCMCeHb+NwIzp9R dlmnGopa4hIjNGMnwuLV6Iv6nI289JA/CmvGry3q3n6u8JfVquwHNk8PZOQhlixapvXBT/z1MJl ao5A1pIp54UZmRpeOy4L85JHe74nlZIEn9p6aJkfA6skQuWlAMbDZE6nT721df7Bs0MgVWENUqx FraLkI+O3JuoS6g== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 Before this patch, receiving an ADD_ADDR echo on the just connected MP_JOIN subflow -- initiator side, after the MP_JOIN 3WHS -- was resulting in an MP_RESET. That's because only ACKs with a DSS or ADD_ADDRs without the echo bit were allowed. Not allowing the ADD_ADDR echo after an MP_CAPABLE 3WHS makes sense, as we are not supposed to send an ADD_ADDR before because it requires to be in full established mode first. For the MP_JOIN 3WHS, that's different: the ADD_ADDR can be sent on a previous subflow, and the ADD_ADDR echo can be received on the recently created one. The other peer will already be in fully established, so it is allowed to send that. We can then relax the conditions here to accept the ADD_ADDR echo for MPJ subflows. Fixes: 67b12f792d5e ("mptcp: full fully established support after ADD_ADDR") Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/options.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/mptcp/options.c b/net/mptcp/options.c index c0832df3b0a3..4ee2e3605f5b 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -958,7 +958,8 @@ static bool check_fully_established(struct mptcp_sock *= msk, struct sock *ssk, =20 if (subflow->remote_key_valid && (((mp_opt->suboptions & OPTION_MPTCP_DSS) && mp_opt->use_ack) || - ((mp_opt->suboptions & OPTION_MPTCP_ADD_ADDR) && !mp_opt->echo))) { + ((mp_opt->suboptions & OPTION_MPTCP_ADD_ADDR) && + (!mp_opt->echo || subflow->mp_join)))) { /* subflows are fully established as soon as we get any * additional ack, including ADD_ADDR. */ --=20 2.43.0 From nobody Mon Sep 16 19:27:00 2024 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 49216174EED for ; Fri, 21 Jun 2024 11:39:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718969968; cv=none; b=AuZ0SuWp3nms3/FI6U4WlmZcJoTURymQM/UM7wwwCnFPRaEeFE+qvGAEzHvCGH/Fe+QltV38jMuIlW3i0r/zI4pMT2U4SQQXXXTi5jqgBi6EK8rueHtUm0ZYTxN/muAmFy54ooqztOpmkYeRnqHvWgcZ+DRMPiO8exKBH+icmH8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718969968; c=relaxed/simple; bh=3cqSJ+rQBhqK/BunDk7NEDtDeXP1Y+n7Dy+gGOVdQdc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=buIPI3sYf4PjEEUV0dT60JuJTaC3Nm3aidMKMuX28LYcXkkbekLNBclSLc/SdSZkCNnjEBHglyPSNR4PvZYH82u39AhKkx+cOdHyQ+PbibVM8dEvyDOuBatjnIMiFgXeciSC2YtaF+X3DdFFV8QReloBkZO0/TBLTxak/WHDPKU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Rmuc4mET; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Rmuc4mET" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28769C3277B; Fri, 21 Jun 2024 11:39:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718969967; bh=3cqSJ+rQBhqK/BunDk7NEDtDeXP1Y+n7Dy+gGOVdQdc=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=Rmuc4mETp9FICY5ZzK+YWFVxUO7T2jc3YIjna3+8h7XjOQSGIBWzhuU56joXiMe8s w9XS8IYWhvqIgX6AS18BUr8eKCKdMm038/PdQnvWauWxJ+cNlVS5oc81xCjhataZg4 dSSvaPSLuVLOKg/IL4ct0iv9VVD8V9KSC+wxR5RKE9BspOzEPp5dk7GdWul5HnwWLH 6QntT5wDeJ+HQpZqoOOP1jBvR2rGBrkeDALUkpnhLi1rdjJryflEYbXwySzpdBXV7V R1fXaU+wkiyE0oCP98fo5HAYZvsWpWGAas1mEpMM+28hqEy2ma3HLMaXep0ZXIJkZA 5Rv7ysAXPVf3Q== From: "Matthieu Baerts (NGI0)" Date: Fri, 21 Jun 2024 13:39:08 +0200 Subject: [PATCH mptcp-next 2/4] mptcp: split id_avail_bitmap per target Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20240621-mptcp-pm-avail-v1-2-b692d5eb89b5@kernel.org> References: <20240621-mptcp-pm-avail-v1-0-b692d5eb89b5@kernel.org> In-Reply-To: <20240621-mptcp-pm-avail-v1-0-b692d5eb89b5@kernel.org> To: mptcp@lists.linux.dev Cc: Paolo Abeni , "Matthieu Baerts (NGI0)" X-Mailer: b4 0.14.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=6546; i=matttbe@kernel.org; h=from:subject:message-id; bh=3cqSJ+rQBhqK/BunDk7NEDtDeXP1Y+n7Dy+gGOVdQdc=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBmdWZsyr/bjiE8E4nKGvBrpYhfAgZDDdLoScQ9r 5faIXlKs1WJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZnVmbAAKCRD2t4JPQmmg c4zrEADuFk4t35236e619r7rhsf+EaK5VyB1nhzCsMnoyi9Ei/Zlg8gkf0A7CceG1sgUDFF6bAx ROeKFzr8ZV6/L3/a6n+71xiXdiG5WiuGhXiWl8wup63FBPG2qp/Lko5J/pdzRWU5wZ0/Qny4P1N UidfsihhsJEJc2vAOsyDjyQIYAgxuL74sg/VhMOWKN3fTf3DeObaFMA6k7qiTbYZF4bZKxonHrX QffX1AtZxN512dWQ30q0grTnMwgseswzXTPLrTWGm0vAfDrYXi+kB/IS657DxQJad89BpAxQJWr g67E9ChHZvLYfP48mGUL9QCqihc8lai0VJeZPnnw5aGsqYdW5FXPvtntEihExftckbqFRlRIQVe /TMzeJ5nSc2d1FXlqsp+aewFawooMmThnW8AFWU1AeQmT5iHw0pWEnmrMf9SGpA2OVeDz6XPRoM 9pZVahc7WDsBfHYeJkPI1GEcHOgbt7pTINpN5kSKvByNYI04s9vNvDFFyi3bINRp3yE8hdta7t3 /PjW19X33dqeHkS4PwqpXC+zmWMs0PtdHwr6/CG3ty+iqNWIeUTYiI5t8vbzYuKSw3VekkCEmQy aWzIyMxq5E5fYc1ScPrHOj9f/NQcfSyZ5Wy2mlmlsvABYQ289AfbQgA2wZmR9Ta95UJK6FfOtZd nwTQu2G9r23RhCA== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 Up to the 'Fixes' commit, having an endpoint with both the 'signal' and 'subflow' flags, resulted in the creation of a subflow and an address announcement using the address linked to this endpoint. After this commit, only the address announcement was done, ignoring the 'subflow' flag. That's because the same bitmap was used for the two flags. It is easy to split it in two: one for 'signal', and one for 'subflow'. It is unusual to set the two flags together: creating a new subflow using a new local address will implicitly advertise it to the other peer. So in theory, no need to advertise it explicitly as well. Maybe there are use-cases -- the subflow might not reach the other peer that way, we can ask the other peer to try initiating the new subflow without delay -- or very likely the user is confused, and put both flags "just to be sure at least the right one is set". Still, the kernel should do what has been asked: using this endpoint to announce the address and to create a new subflow from it. An alternative is to forbid the use of the two flags together, but that's probably too late, and there are maybe use-cases. This patch will avoid people complaining subflows are not created using the endpoint they added with the 'subflow' and 'signal' flag. Fixes: 86e39e04482b ("mptcp: keep track of local endpoint still available f= or each msk") Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm.c | 3 ++- net/mptcp/pm_netlink.c | 20 ++++++++++++-------- net/mptcp/protocol.h | 5 +++-- 3 files changed, 17 insertions(+), 11 deletions(-) diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c index 55406720c607..d29fb35bb927 100644 --- a/net/mptcp/pm.c +++ b/net/mptcp/pm.c @@ -543,7 +543,8 @@ void mptcp_pm_data_reset(struct mptcp_sock *msk) WRITE_ONCE(pm->addr_signal, 0); WRITE_ONCE(pm->remote_deny_join_id0, false); pm->status =3D 0; - bitmap_fill(msk->pm.id_avail_bitmap, MPTCP_PM_MAX_ADDR_ID + 1); + bitmap_fill(msk->pm.id_avail_signals_bitmap, MPTCP_PM_MAX_ADDR_ID + 1); + bitmap_fill(msk->pm.id_avail_subflows_bitmap, MPTCP_PM_MAX_ADDR_ID + 1); } =20 void mptcp_pm_data_init(struct mptcp_sock *msk) diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index ea9e5817b9e9..4805452d05a2 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -156,7 +156,7 @@ select_local_address(const struct pm_nl_pernet *pernet, if (!(entry->flags & MPTCP_PM_ADDR_FLAG_SUBFLOW)) continue; =20 - if (!test_bit(entry->addr.id, msk->pm.id_avail_bitmap)) + if (!test_bit(entry->addr.id, msk->pm.id_avail_subflows_bitmap)) continue; =20 ret =3D entry; @@ -178,10 +178,10 @@ select_signal_address(struct pm_nl_pernet *pernet, co= nst struct mptcp_sock *msk) * can lead to additional addresses not being announced. */ list_for_each_entry_rcu(entry, &pernet->local_addr_list, list) { - if (!test_bit(entry->addr.id, msk->pm.id_avail_bitmap)) + if (!(entry->flags & MPTCP_PM_ADDR_FLAG_SIGNAL)) continue; =20 - if (!(entry->flags & MPTCP_PM_ADDR_FLAG_SIGNAL)) + if (!test_bit(entry->addr.id, msk->pm.id_avail_signals_bitmap)) continue; =20 ret =3D entry; @@ -228,7 +228,9 @@ bool mptcp_pm_nl_check_work_pending(struct mptcp_sock *= msk) struct pm_nl_pernet *pernet =3D pm_nl_get_pernet_from_msk(msk); =20 if (msk->pm.subflows =3D=3D mptcp_pm_get_subflows_max(msk) || - (find_next_and_bit(pernet->id_bitmap, msk->pm.id_avail_bitmap, + (find_next_and_bit(pernet->id_bitmap, msk->pm.id_avail_signals_bitmap, + MPTCP_PM_MAX_ADDR_ID + 1, 0) =3D=3D MPTCP_PM_MAX_ADDR_ID + 1) || + (find_next_and_bit(pernet->id_bitmap, msk->pm.id_avail_subflows_bitma= p, MPTCP_PM_MAX_ADDR_ID + 1, 0) =3D=3D MPTCP_PM_MAX_ADDR_ID + 1)) { WRITE_ONCE(msk->pm.work_pending, false); return false; @@ -537,7 +539,8 @@ static void mptcp_pm_create_subflow_or_signal_addr(stru= ct mptcp_sock *msk) rcu_read_lock(); entry =3D __lookup_addr(pernet, &mpc_addr); if (entry) { - __clear_bit(entry->addr.id, msk->pm.id_avail_bitmap); + __clear_bit(entry->addr.id, msk->pm.id_avail_signals_bitmap); + __clear_bit(entry->addr.id, msk->pm.id_avail_subflows_bitmap); msk->mpc_endpoint_id =3D entry->addr.id; backup =3D !!(entry->flags & MPTCP_PM_ADDR_FLAG_BACKUP); } @@ -570,7 +573,7 @@ static void mptcp_pm_create_subflow_or_signal_addr(stru= ct mptcp_sock *msk) =20 if (local) { if (mptcp_pm_alloc_anno_list(msk, &local->addr)) { - __clear_bit(local->addr.id, msk->pm.id_avail_bitmap); + __clear_bit(local->addr.id, msk->pm.id_avail_signals_bitmap); msk->pm.add_addr_signaled++; mptcp_pm_announce_addr(msk, &local->addr, false); mptcp_pm_nl_addr_send_ack(msk); @@ -592,7 +595,7 @@ static void mptcp_pm_create_subflow_or_signal_addr(stru= ct mptcp_sock *msk) fullmesh =3D !!(local->flags & MPTCP_PM_ADDR_FLAG_FULLMESH); =20 msk->pm.local_addr_used++; - __clear_bit(local->addr.id, msk->pm.id_avail_bitmap); + __clear_bit(local->addr.id, msk->pm.id_avail_subflows_bitmap); nr =3D fill_remote_addresses_vec(msk, &local->addr, fullmesh, addrs); if (nr =3D=3D 0) continue; @@ -822,7 +825,8 @@ static void mptcp_pm_nl_rm_addr_or_subflow(struct mptcp= _sock *msk, __MPTCP_INC_STATS(sock_net(sk), rm_type); } if (rm_type =3D=3D MPTCP_MIB_RMSUBFLOW) - __set_bit(rm_id ? rm_id : msk->mpc_endpoint_id, msk->pm.id_avail_bitmap= ); + __set_bit(rm_id ? rm_id : msk->mpc_endpoint_id, + msk->pm.id_avail_subflows_bitmap); else if (rm_type =3D=3D MPTCP_MIB_RMADDR) __MPTCP_INC_STATS(sock_net(sk), rm_type); if (!removed) diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h index 19d60b6d5b45..cbb430108823 100644 --- a/net/mptcp/protocol.h +++ b/net/mptcp/protocol.h @@ -187,7 +187,7 @@ enum mptcp_pm_status { MPTCP_PM_SUBFLOW_ESTABLISHED, MPTCP_PM_ALREADY_ESTABLISHED, /* persistent status, set after ESTABLISHED= event */ MPTCP_PM_MPC_ENDPOINT_ACCOUNTED /* persistent status, set after MPC local= address is - * accounted int id_avail_bitmap + * accounted in id_avail_*_bitmap */ }; =20 @@ -231,7 +231,8 @@ struct mptcp_pm_data { u8 pm_type; u8 subflows; u8 status; - DECLARE_BITMAP(id_avail_bitmap, MPTCP_PM_MAX_ADDR_ID + 1); + DECLARE_BITMAP(id_avail_signals_bitmap, MPTCP_PM_MAX_ADDR_ID + 1); + DECLARE_BITMAP(id_avail_subflows_bitmap, MPTCP_PM_MAX_ADDR_ID + 1); struct mptcp_rm_list rm_list_tx; struct mptcp_rm_list rm_list_rx; }; --=20 2.43.0 From nobody Mon Sep 16 19:27:00 2024 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 79CFB13777F for ; Fri, 21 Jun 2024 11:39:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718969969; cv=none; b=WTNk9fabWoz1c6Zw59tOSlgmjG3w/0DsQvbDElPGMQBRHRkn/ThuNT+zu572PfHi3wGNiWgKuWKMW+SjT5jCxy9N5yqbw7lvlWL+soLZ1DpIJma8muvboa7X0vllemWl9iX7MFa6vHjRH6RDaxaT8sl89AX56deY6WqOF1UEpIU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718969969; c=relaxed/simple; bh=bxESA9RyE6Q2GVZhl2l+RPRIRfX3gqlM6Uy/yG+YhP4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=XX0CHidksFSoN/ft/gynu8BTLuMgiFB3Aw2Kbo1fwnz+fCSyz0/NOsCMOTNN+atNDwKdeG9sXaDHEKgvJs95mWk3exhecY172gVen4GbphL80I0Qh1Zn5V2yIuT6gksXWYG91Z+iaVk/JQrD8GbE34nhK3+lroMoA0h5LwDYEfQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rDzG9Du3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rDzG9Du3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52A40C4AF08; Fri, 21 Jun 2024 11:39:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718969969; bh=bxESA9RyE6Q2GVZhl2l+RPRIRfX3gqlM6Uy/yG+YhP4=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=rDzG9Du36kvxGYU5jjDCXGluoceNUTkL247NFMPn9P3AruezZcEEPVyqwZrU8IgVo F5bFXv2eYtmc6cvyIFsKFqeQ7deUWfV93F8Hk5rG5MfG50M3ncg6puc74DwCMUYThq b74C2t/PXGAF24GIOJuZE0p82Wwjm8gHZ6Na/ITwGGAO0irGQ/EFTXYVso0+cJ0LsO zCFDF5LHa9iV1eXnPOy07FDzAV+eBiF5rlWYMBXNhQog7vYN3NtRhU3my2c2eGm68R y+7QAnnoIu5FwxTpm3ER8BEhvPGuKo2KcURViDJCuDkkbqABORg44gmgvyEcFDNBzR Xo9KEALX8YOMQ== From: "Matthieu Baerts (NGI0)" Date: Fri, 21 Jun 2024 13:39:09 +0200 Subject: [PATCH mptcp-next 3/4] selftests: mptcp: join: ability to invert ADD_ADDR check Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20240621-mptcp-pm-avail-v1-3-b692d5eb89b5@kernel.org> References: <20240621-mptcp-pm-avail-v1-0-b692d5eb89b5@kernel.org> In-Reply-To: <20240621-mptcp-pm-avail-v1-0-b692d5eb89b5@kernel.org> To: mptcp@lists.linux.dev Cc: Paolo Abeni , "Matthieu Baerts (NGI0)" X-Mailer: b4 0.14.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3973; i=matttbe@kernel.org; h=from:subject:message-id; bh=bxESA9RyE6Q2GVZhl2l+RPRIRfX3gqlM6Uy/yG+YhP4=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBmdWZsUk4jyDc+BC9suK5cCyIWtQ/tK3mujwWxE 8r0UnEaWkqJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZnVmbAAKCRD2t4JPQmmg czS7EADe30JNmsSyN+wp6pqmDYYHEErlu/Hi7Ya7UCWUKcge6UH05XKOFKT5uKp84UOYYRq1jTI y1CiHfd2ydyYFR26+xfLQlGdkMfKqDQGZsCgg0t/ni7BfK3q0fIZzK3wXwTPVUsbcdmrhHH0Vnn TeOd6ePp4E9VDzCC8/6Ogw1C9FRu0DYjF9glMCPWjWc9Z0lLzwZn6ra7C4nggP/3wwDjcF8WQy3 cxyuKa40SQVIYJ+YCAH1ZSqjhXHDJ2tfETEvXiGvkouvZKnSYNOPz0bRLNdnriq1Hv9mPaj/tDo 7MXkosgluZnip4zuqIIhsF9YBfpoZm/OebiR5MNrXSzibPFQEGNlIHPVp33Jp2tc8Y6+9mKQUdw 7MRifurddvdcu2fWGZYWDHQ6ncS5cy/TU67ZDWbAzk6vPwaO0oT+u3yqdRlvIsDPOKC00RJ/34a LRPDVkswKi/aN3EG0KFZS2Gwb0T8F5mzlD3RSzr8t4psy1dmfq28+/LfnAoDOM/ZWS8I3zUpa5n vy/K8Bkad8efa1jBUgWRo36qz4K93Wd/MvJufUwRdr3YgapyaIdkNvuB3KmvvSfkUSzsuUwTWpN eAHD6aIJ71Qey1qd/p0VhP1N16xpiO56JpYIbsFcKFclBHhJwNsHxob89B8UKVkJn1oWNq5GHto kW915PyzETLeFfA== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 In the following commit, the client will initiate the ADD_ADDR, instead of the server. We need to way to verify the ADD_ADDR have been correctly sent. Note: the default expected counters for when the port number is given are never changed by the caller, no need to accept them as parameter then. Signed-off-by: Matthieu Baerts (NGI0) --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 40 ++++++++++++++++-----= ---- 1 file changed, 26 insertions(+), 14 deletions(-) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index 108aeeb84ef1..5f5e498bbb75 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -1415,18 +1415,28 @@ chk_add_nr() local add_nr=3D$1 local echo_nr=3D$2 local port_nr=3D${3:-0} - local syn_nr=3D${4:-$port_nr} - local syn_ack_nr=3D${5:-$port_nr} - local ack_nr=3D${6:-$port_nr} - local mis_syn_nr=3D${7:-0} - local mis_ack_nr=3D${8:-0} + local ns_invert=3D${4:-""} + local syn_nr=3D$port_nr + local syn_ack_nr=3D$port_nr + local ack_nr=3D$port_nr + local mis_syn_nr=3D0 + local mis_ack_nr=3D0 + local ns_tx=3D$ns1 + local ns_rx=3D$ns2 + local extra_msg=3D"" local count local timeout =20 - timeout=3D$(ip netns exec $ns1 sysctl -n net.mptcp.add_addr_timeout) + if [[ $ns_invert =3D "invert" ]]; then + ns_tx=3D$ns2 + ns_rx=3D$ns1 + extra_msg=3D"invert" + fi + + timeout=3D$(ip netns exec ${ns_tx} sysctl -n net.mptcp.add_addr_timeout) =20 print_check "add" - count=3D$(mptcp_lib_get_counter ${ns2} "MPTcpExtAddAddr") + count=3D$(mptcp_lib_get_counter ${ns_rx} "MPTcpExtAddAddr") if [ -z "$count" ]; then print_skip # if the test configured a short timeout tolerate greater then expected @@ -1438,7 +1448,7 @@ chk_add_nr() fi =20 print_check "echo" - count=3D$(mptcp_lib_get_counter ${ns1} "MPTcpExtEchoAdd") + count=3D$(mptcp_lib_get_counter ${ns_tx} "MPTcpExtEchoAdd") if [ -z "$count" ]; then print_skip elif [ "$count" !=3D "$echo_nr" ]; then @@ -1449,7 +1459,7 @@ chk_add_nr() =20 if [ $port_nr -gt 0 ]; then print_check "pt" - count=3D$(mptcp_lib_get_counter ${ns2} "MPTcpExtPortAdd") + count=3D$(mptcp_lib_get_counter ${ns_rx} "MPTcpExtPortAdd") if [ -z "$count" ]; then print_skip elif [ "$count" !=3D "$port_nr" ]; then @@ -1459,7 +1469,7 @@ chk_add_nr() fi =20 print_check "syn" - count=3D$(mptcp_lib_get_counter ${ns1} "MPTcpExtMPJoinPortSynRx") + count=3D$(mptcp_lib_get_counter ${ns_tx} "MPTcpExtMPJoinPortSynRx") if [ -z "$count" ]; then print_skip elif [ "$count" !=3D "$syn_nr" ]; then @@ -1470,7 +1480,7 @@ chk_add_nr() fi =20 print_check "synack" - count=3D$(mptcp_lib_get_counter ${ns2} "MPTcpExtMPJoinPortSynAckRx") + count=3D$(mptcp_lib_get_counter ${ns_rx} "MPTcpExtMPJoinPortSynAckRx") if [ -z "$count" ]; then print_skip elif [ "$count" !=3D "$syn_ack_nr" ]; then @@ -1481,7 +1491,7 @@ chk_add_nr() fi =20 print_check "ack" - count=3D$(mptcp_lib_get_counter ${ns1} "MPTcpExtMPJoinPortAckRx") + count=3D$(mptcp_lib_get_counter ${ns_tx} "MPTcpExtMPJoinPortAckRx") if [ -z "$count" ]; then print_skip elif [ "$count" !=3D "$ack_nr" ]; then @@ -1492,7 +1502,7 @@ chk_add_nr() fi =20 print_check "syn" - count=3D$(mptcp_lib_get_counter ${ns1} "MPTcpExtMismatchPortSynRx") + count=3D$(mptcp_lib_get_counter ${ns_tx} "MPTcpExtMismatchPortSynRx") if [ -z "$count" ]; then print_skip elif [ "$count" !=3D "$mis_syn_nr" ]; then @@ -1503,7 +1513,7 @@ chk_add_nr() fi =20 print_check "ack" - count=3D$(mptcp_lib_get_counter ${ns1} "MPTcpExtMismatchPortAckRx") + count=3D$(mptcp_lib_get_counter ${ns_tx} "MPTcpExtMismatchPortAckRx") if [ -z "$count" ]; then print_skip elif [ "$count" !=3D "$mis_ack_nr" ]; then @@ -1513,6 +1523,8 @@ chk_add_nr() print_ok fi fi + + print_info "$extra_msg" } =20 chk_add_tx_nr() --=20 2.43.0 From nobody Mon Sep 16 19:27:00 2024 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9D928173333 for ; Fri, 21 Jun 2024 11:39:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718969971; cv=none; b=Tetg5Mej/8D/2BhdjYabxLv9wBtXbkFWMS2kWO3FFuLqb0xCJovJFxpPT5MoWk8hRyf1eEUowv2LdcubQYKQq+nOgZ0ZBEw3eOmzBYEcem77f5bezbBZPUqwdytpBvoyte4i6vcGQRrhm76OBK0m9LtM5EeBuDaC/GTRTWeoaTo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718969971; c=relaxed/simple; bh=6BcNCVZi5VEoz9Dllnt92YFkM9GvvqXSuSrVQZ7zPIQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=I0uoiVL5USw3N/Ufr/SlDMFgwtDG4SFW/DFCEge9+36Yf7ev4OLMpWYAUMj2qi2GQTebnY+Ip1TOeKf+Bv9qrDQ7BrmyIv0q1NMzA7AcNyEFmchJ7EhcUfAqpTwQGMSmzN+qqYYWydp28TCSNqn1kdzWLfmy6XcBu0h25bUdXtk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UabpbXce; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UabpbXce" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7B7E3C2BBFC; Fri, 21 Jun 2024 11:39:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718969970; bh=6BcNCVZi5VEoz9Dllnt92YFkM9GvvqXSuSrVQZ7zPIQ=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=UabpbXce4kchtXUkHsilgJDlZ6Vbh+b83kuVBzzkTdR8PyEcQl81L5Tljz3YUC4cO hBgC59MfFftOdF3p0TJ3E0hPr2NxZDlnbGPljZwcXndj8QCGZE8Nl/9GKk+CSHD/+l 3CI4HNretI2QqfBCIQJwvgGRzGOteFH+9h3yit9Tlpcs7jnzQ33/RYS5T+qLOGGkMT 7skS9RTnhkphBbPrEY6/LFbd1XgaS9nw9/pPx/hE5Fkf+K79stL483/eB2tATQ+uI/ 9CiVijYOJzvLOh4/YScgqvwsCmLnVgNfn212HabOz3sk8yR9FZOBP/fbFFC5vZh3Bx Fh9ChsNt7Akwg== From: "Matthieu Baerts (NGI0)" Date: Fri, 21 Jun 2024 13:39:10 +0200 Subject: [PATCH mptcp-next 4/4] selftests: mptcp: join: test both signal & subflow Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20240621-mptcp-pm-avail-v1-4-b692d5eb89b5@kernel.org> References: <20240621-mptcp-pm-avail-v1-0-b692d5eb89b5@kernel.org> In-Reply-To: <20240621-mptcp-pm-avail-v1-0-b692d5eb89b5@kernel.org> To: mptcp@lists.linux.dev Cc: Paolo Abeni , "Matthieu Baerts (NGI0)" X-Mailer: b4 0.14.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2052; i=matttbe@kernel.org; h=from:subject:message-id; bh=6BcNCVZi5VEoz9Dllnt92YFkM9GvvqXSuSrVQZ7zPIQ=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBmdWZsAEhzTVK4+iFmrC/8Zze/NgpbZCEDXsJDw 1xY8n+1d2SJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZnVmbAAKCRD2t4JPQmmg c1cSEADTFmnJjE5ksXJ0k4RFV5Jv2WDvyu4VZvZazYX65q7UdO/EK2ptsVHuG+Ag+srGsCYndSN aue0T0pAvhw50imXTWOv77YAoGGEDY3XJtlMWGf+4858hpallpeztwasTsvlwmRyL700Qo36hvt 5AtvGVII/pZ0lDSiGnh6bCI+17wv1JjJ7KbvkBX5ZKu458ZJaTQ01ZTnjSvRzCPIkZeeGmngnFA pUzYmrgX8EV1sbbEj/wOHZ/YHur/Tq6W3mmO4zv4E7Qnu6/9EcdY4gjXeH8WmAd9PNMYwa++jUb vx5zpWf8KRSgRUyCnNDrerAfBODpuYq9qZgFQEsBB/LJHAUo4S6kgklLk0TqKr4b/0XLa+eb3C6 aVISAWLAx2eXFmZRyKJDlVmwQ0l8TPMCGmo/e4RF5NU4lG7RdliWfNjxwCjIdoiXbSi4SDQ1K6Z 2BFqkUfAgwZW5qNYDXEyeoeP0dI75g4ss8QdfwchLPs7Po5PnSLNWYxYpMzA24vsxbxsRwYMyYL SZG7WC+Q4Vfve3u5o2LBwKZlPR995xzjzv+gfQNXIYhR48i9Oax7zgyBMewFlCuPtc/NP+Rjkqx Pckdb8cfa8GE+unKUTgSrwdtSB3AEQgTpE0h1+NBeWIabNzIT/UHSlMSuAqR4mszu5+MbpKVwCG 8i3m8XLimHpBPuw== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 It should be quite uncommon to set both the subflow and the signal flags: the initiator of the connection is typically the one creating new subflows, not the other peer, then no need to announce additional local addresses, and use it to create subflows. But some people might be confused about the flags, and set both "just to be sure at least the right one is set". To verify the previous fix, and avoid future regressions, this specific case is now validated: the client announces a new address, and initiates a new subflow from the same address. While working on this, another bug has been noticed, where the client reset the new subflow because an ADD_ADDR echo got received as the 3rd ACK: check that no RST have been sent by the client and server. Signed-off-by: Matthieu Baerts (NGI0) --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index 5f5e498bbb75..b8c0b69db527 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -1967,6 +1967,21 @@ signal_address_tests() chk_add_nr 1 1 fi =20 + # uncommon: subflow and signal flags on the same endpoint + # or because the user wrongly picked both, but still expects the client + # to create additional subflows + if reset "subflow and signal together"; then + pm_nl_set_limits $ns1 0 2 + pm_nl_set_limits $ns2 0 2 + pm_nl_add_endpoint $ns2 10.0.3.2 flags signal,subflow + run_tests $ns1 $ns2 10.0.1.1 + chk_join_nr 1 1 1 + chk_add_nr 1 1 0 invert # only initiated by ns2 + chk_add_nr 0 0 0 # none initiated by ns1 + chk_rst_nr 0 0 invert # no RST sent by the client + chk_rst_nr 0 0 # no RST sent by the server + fi + # accept and use add_addr with additional subflows if reset "multiple subflows and signal"; then pm_nl_set_limits $ns1 0 3 --=20 2.43.0