Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

in-kernel PM: re-establish subflows after "network" errors #440

Open
matttbe opened this issue Sep 16, 2023 · 3 comments
Open

in-kernel PM: re-establish subflows after "network" errors #440

matttbe opened this issue Sep 16, 2023 · 3 comments
Labels
enhancement pm path-manager

Comments

@matttbe
Copy link
Member

matttbe commented Sep 16, 2023

In case of network issue (blackhole, wrong path, etc.), it might be interesting to re-established subflows that got closed after a TCP-level error (timeout, RST, etc.) as it was maybe a temp issue or a change in the network (e.g. NAT dropping connections a bit too quickly)

@matttbe matttbe added enhancement pm path-manager labels Sep 16, 2023
@arinc9
Copy link
Contributor

arinc9 commented Jun 25, 2024

On top of that, it'd be great if newly added subflows were established on existing MPTCP connections. For example, a cellular network interface that was described as a subflow path may go down and up. In that case, even though mptcpd adds it back as a subflow, that subflow won't be re-established on the existing MPTCP connection. Unless I'm wrong?

@matttbe
Copy link
Member Author

matttbe commented Jul 11, 2024

For example, a cellular network interface that was described as a subflow path may go down and up. In that case, even though mptcpd adds it back as a subflow, that subflow won't be re-established on the existing MPTCP connection. Unless I'm wrong?

If the corresponding endpoint is removed and re-added, the subflow should be re-created. If not, that's a bug.

@matttbe
Copy link
Member Author

matttbe commented Jul 11, 2024

For the initial issue, such patch can be used as a starting point:

diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c
index 98b0b31e3b8d..c64fa3fe4779 100644
--- a/net/mptcp/pm.c
+++ b/net/mptcp/pm.c
@@ -202,6 +202,8 @@ void mptcp_pm_subflow_check_next(struct mptcp_sock *msk,
 	if (!READ_ONCE(pm->work_pending) && !update_subflows)
 		return;
 
+	mptcp_pm_nl_close_subflow(msk, subflow); /* or before the return just above? */
+
 	spin_lock_bh(&pm->lock);
 	if (update_subflows)
 		__mptcp_pm_close_subflow(msk);
diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c
index d353cb007090..5a7ccefdb36a 100644
--- a/net/mptcp/pm_netlink.c
+++ b/net/mptcp/pm_netlink.c
@@ -782,6 +787,15 @@ static bool mptcp_local_id_match(const struct mptcp_sock *msk, u8 local_id, u8 i
 	return local_id == id || (!local_id && msk->mpc_endpoint_id == id);
 }
 
+void mptcp_pm_nl_close_subflow(struct mptcp_sock *msk,
+			       const struct mptcp_subflow_context *rm_subflow)
+{
+	struct sock *rm_ssk = mptcp_subflow_tcp_sock(rm_subflow);
+
+	if (rm_ssk->sk_err == TODO || rm_subflow->reset_reason == TODO)
+		/* TODO: recreate subflow */
+}
+
 static void mptcp_pm_nl_rm_addr_or_subflow(struct mptcp_sock *msk,
 					   const struct mptcp_rm_list *rm_list,
 					   enum linux_mptcp_mib_field rm_type)
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index cee0a8098b41..b7ed9a2db7ea 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -1145,6 +1145,9 @@ unsigned int mptcp_pm_get_add_addr_accept_max(const struct mptcp_sock *msk);
 unsigned int mptcp_pm_get_subflows_max(const struct mptcp_sock *msk);
 unsigned int mptcp_pm_get_local_addr_max(const struct mptcp_sock *msk);
 
+void mptcp_pm_nl_close_subflow(struct mptcp_sock *msk,
+			       const struct mptcp_subflow_context *rm_subflow);
+
 /* called under PM lock */
 static inline void __mptcp_pm_close_subflow(struct mptcp_sock *msk)
 {

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement pm path-manager
Projects
Status: Needs triage
Development

No branches or pull requests

2 participants