multipath-tcp / mptcp

⚠️⚠️⚠️ Deprecated 🚫 Out-of-tree Linux Kernel implementation of MultiPath TCP. 👉 Use https://github.com/multipath-tcp/mptcp_net-next repo instead ⚠️⚠️⚠️
https://github.com/multipath-tcp/mptcp_net-next
Other
889 stars 335 forks source link

netlink command to get connection and subflow info #425

Closed VenkateswaranJ closed 3 years ago

VenkateswaranJ commented 3 years ago

How to get Mptcp connection and subflow info when mptcp user space path manager (example mptcpd) starts after mptcp connection has been established? In this case, it needs at least the connection-token to execute further commands (for example add_arr, remv_addr, sub_create etc) but the connection-token only sent as an event during the connection establishment time.

So the userspace path manager has to be started before connection creation? Please correct me if I misunderstand the things here.

matttbe commented 3 years ago

So the userspace path manager has to be started before connection creation?

Yes, that's the idea. The userspace PM is supposed to be a daemon launched at startup.

But because it is always possible to miss events, this userspace path manager should be able to deal with new tokens from any events.

Does it answer your question?

VenkateswaranJ commented 3 years ago

But because it is always possible to miss events, this userspace path manager should be able to deal with new tokens from any events.

The problem is, it never gets an event if it misses MPTCP_EVENT_CREATED and MPTCP_EVENT_ESTABLISHED because further events are triggered only when there is some action done from userspace (example add/remove the address or subflow), but to perform those action userspace path manger needs token and other info (example address ID of local and remote).

Yes, that's the idea. The userspace PM is supposed to be a daemon launched at startup.

It doesn't ensure that the path manager daemon will start and connect to the mptcp NetLink family (sometimes it gets delayed isn't it ?) before any of the client/server application starts their connection.

Let's consider the below scenario:

  1. Client and server application running on a separate physical machine.
  2. User can configure the server IP address in the client device so that it will connect to the server when it boot-up.
  3. For example, consider the client connects to the server socket before the path manager connects to the mptcp Netlink multicast group (on both sides).
  4. Now, the client or server wants to advertise its second IP address. Where to get the connection token to construct Netlink MPTCP_CMD_ANNOUNCE request?

I can handle the above case in two way.

  1. Add a wait block in the client and server application that waits for the mptcp path manager to get initialise.
  2. There should be some way to get the mptcp connection information from the kernel at any time (similar to RTM_GETLINK for example)

@matttbe if you think that adding a wait block would be the right solution for the above scenario please close this issue.

VenkateswaranJ commented 3 years ago
  1. Is it possible to get the connection token via socketopt?
  2. To execute MPTCP_CMD_SUB_CREATE remote address and id has to be advertised before, isn't it? what I mean is, it's not possible to send MPTCP_CMD_SUB_CREATE with [saddr, local_ID, daddr, rem_ID, dport] value from the client-side by assigning some unique value to rem_ID. In this case join connection request will be refused by the server as it doesn't aware of rem_ID. so the rem_ID only be advertised by the remote device and the local device can use that ID but it can't assign a value for rem_ID.
VenkateswaranJ commented 3 years ago
$sudo cat /proc/net/mptcp_net/mptcp 
sl  loc_tok       rem_tok       v6  local_address           remote_address       st ns tx_queue rx_queue     inode
0:  85FF8541      B579A34A       0   0240640A:DA9D           0242640A:04D2       01 01 00000000:00000000    42174

It's the information I was looking for, here it's possible to get an mptcp connection-token at any time. It would be great if this info is available via the Netlink query command ( without worrying about missing event). Also, it would be easier than parsing procfs file :)

is it possible to reset /proc/net/mptcp_net/snmp counter ?

matttbe commented 3 years ago

(I just realised I never replied to the last questions, sorry for that)

It doesn't ensure that the path manager daemon will start and connect to the mptcp NetLink family (sometimes it gets delayed isn't it ?) before any of the client/server application starts their connection.

With init system like systemd, you can easily create some dependences to make sure a service is started before/after another one.

In the first version of the Netlink PM patch, we suggested to add a DUMP command to retrigger events just in case we lost some. But it was not really the good way to go. Probably best to get that via netdiag (MPTCP support has been added in the upstream kernel).

Is it possible to get the connection token via socketopt?

Not with the current version

To execute MPTCP_CMD_SUB_CREATE remote address and id has to be advertised before, isn't it? what I mean is, it's not possible to send MPTCP_CMD_SUB_CREATE with [saddr, local_ID, daddr, rem_ID, dport] value from the client-side by assigning some unique value to rem_ID. In this case join connection request will be refused by the server as it doesn't aware of rem_ID. so the rem_ID only be advertised by the remote device and the local device can use that ID but it can't assign a value for rem_ID.

If you control both ends, you might be able to predict the remote ID. On the other hands, the ID are mostly useful in case of REMOVE_ADDR or MP_PRIO. Maybe you don't use them and that's find if you use the wrong ID.

is it possible to reset /proc/net/mptcp_net/snmp counter ?

No I don't think it can be done. Typically you have nstat that can track the evolution of these counters. At some points, there was a modified version looking at these MPTCP counters I think. On the upstream kernel, nstat can access MPTCP counters without modifications because they are in a different place.

Do you think we can close this ticket?