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

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

GitHub · Where software is built

• A similar idea has not been reported before.
• mptcp.dev website does not cover my case.
• The wiki doesn't cover my case.

I'm pondering about writing an userspace Path Manager - for an MPTCP client case.

The server can report addresses in two ways:

• via ADD-ADDR - this is properly reported to userspace PM as a netlink message type 6
• via cleared "Do not attempt to establish new subflows to this address and port" flag on initial SYN-ACK

Typically, the "Do not attempt to establish new subflows to this address and port" flag is set, so a naive userspace PM can assume this. But this seems wrong. The "Do not attempt to establish new subflows to this address and port" flag is set as part of struct mptcp_subflow_request_sock allow_join_id0 member. Unless I read the code wrong, this struct is not passed to the netlink code that generates connected/established events.

I think access to this flag is necessary for any sane userspace PM. Unless I got something wrong and there maybe is a way to read it?

Marek

I guess another new netlink attribute on created/established message?

An alternative would be for userspace PM to do some kind of ss query and ping the socket state. But again - I don't think this is going to report much. The extreme hack would be to steal socket from userspace and query its state with MPTCP_FULL_INFO. (does this struct have info on whether server allowed the server address pair reuse?)

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