Closed VenkateswaranJ closed 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?
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:
MPTCP_CMD_ANNOUNCE
request?I can handle the above case in two way.
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.
socketopt
?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.$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 ?
(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?
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.