Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/multipath-tcp/mptcp_net-next/issues/534 below:

Kernel built-in PM is unreliable · Issue #534 · multipath-tcp/mptcp_net-next · GitHub

• A similar issue has not been reported before.
• mptcp.dev website does not cover my case.
• An up-to-date kernel is being used.
• This case is not fixed with the latest stable (or LTS) version listed on kernel.org

Pardon my lack of specificity, but I can't quite pinpoint this problem. I'm trying to run vanilla Linux as MPTCP client. I'm expecting "interactive" semantics - I want to get a reliable MPTCP connection over ever-changing network interfaces.

I'm running ubuntu 22, kernel 3.8. I have NetworkManager configured and I see ip mptcp endpoints ... subflow nicely configured when new network interface is created/enabled. And the entries correctly disappear on interface down. All other settings (sysctl's ) are default. I'm using in-kernel built-in path manager.

I manually create an MPTCP flow to a server, the server reports clear "Do not attempt to establish new subflows to this address and port" flag - allows client to reconnect. Initially I have two network interfaces - ethernet and Wi-Fi and I indeed see two underlying TCP subflows created.

When I yank out ethernet, the appropriate subflow disapears. When I plug it in it's often recreated. The same works for Wi-Fi.

It's all nice and shiny, but for an unknown reason this just stops working at some point. I don't know - maybe I'm yanking the ethetnet off too often? Or with too small delay? I'm sure it works (ping works) but at some point, the mptcp just seems to give up and fails to establish a new flow. I don't think this is about hitting "ip mptcp limits". Maybe there is some race-condition in the system, and it moves the MPTCP to a broken state.

I don't expect any resolution for this ticket, but I wanted to report it. Maybe it's a well known bug or feature of PM?

Any hints on how to debug built-in PM and understand why it just switches mptcp socket to a "broken" state (ie: gives up on establishing new subflows) would be helpful.

Marek

Built-in PM seems to give up on an MPTCP socket at some point.

I would expect MPTCP socket to stay working while I'm adding/removing network interfaces, as long as at least one network interface is always in a good state. I understand that when I break all connectivity MPTCP might, rightfully so, error.

Linux mrnew 6.8.0-49-generic #49-Ubuntu SMP PREEMPT_DYNAMIC Mon Nov  4 02:06:24 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
PRETTY_NAME="Ubuntu 24.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.1 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo
net.mptcp.add_addr_timeout = 120
net.mptcp.allow_join_initial_addr_port = 1
net.mptcp.checksum_enabled = 0
net.mptcp.close_timeout = 60
net.mptcp.enabled = 1
net.mptcp.pm_type = 1
net.mptcp.scheduler = default
net.mptcp.stale_loss_cnt = 4
192.168.1.149 id 13 subflow dev wlp0s20f3 
XXXXX id 14 subflow dev wlp0s20f3 
add_addr_accepted 0 subflows 2

No response

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4