is it possible to get mptcp_info from mptcp socket inode

[VenkateswaranJ]

I can get the mptcp socket inode from /proc/net/mptcp_net/mptcp

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: 73A8808 9F45418 0 0342640A:85B1 0242640A:17AC 01 02 00000000:00000000 79714

Now, is it possible to get the mptcp_info of this inode? getsockopt() only accept fd isn't it?

[matttbe]

Hello,

Does your app "own" the fd? I think you can explicitly "share" FD between processes somehow but not sure that's what you want and it certainly requires additional permissions.

Maybe best to retrieve info via netlink like ss tool is doing?

[VenkateswaranJ]

Maybe best to retrieve info via Netlink like ss tool is doing?

Ok, I'll try to look at the ss source code.

Two more quick questions before closing this issue.

Is it mandatory to configure source routing to make mptcp V0 work properly?

Once the mptcp connection is created between client and server, I'm sending a message from the client to the server and I got Mptcp connection Established event on the client but not on the server-side because it has not yet sent anything to the client.

Now is it valid to announce the second IP from the server (connection establishment is not needed for announcing IP) and create a subflow for that IP from the client (connection established on the client)? Is it valid or should I need to wait until the connection establishment has to happen on both sides?

You answered my similar question to this in another thread but I'm asking it again because I tested the above case without configuring source routing and I'm only able to create a second subflow after the connection establishment happens on both sides.

I couldn't attach the Wireshark log so I'm attaching an image.

[matttbe]

Is it mandatory to configure source routing to make mptcp V0 work properly?

Yes and no. What is important is that packets sent from one IP which is attached to one interface are routed through this interface. So most of the time, you will need to ensure that by adding IP routes/rules. Of course, if the client and server have pair of IPs in the same subnet, that's not needed.

Same with MPTCP v1: that's not linked to the protocol, just because in Linux, we rely on the routing mechanism to choose the next hop.

Now is it valid to announce the second IP from the server (connection establishment is not needed for announcing IP) and create a subflow for that IP from the client (connection established on the client)? Is it valid or should I need to wait until the connection establishment has to happen on both sides?

If I'm not mistaken, it is valid and supported by this kernel. But best is to experiment.

You answered my similar question to this in another thread but I'm asking it again because I tested the above case without configuring source routing and I'm only able to create a second subflow after the connection establishment happens on both sides.

What do you see from the server side? Can you see the packets arriving? Any message print by the kernel with mptcp_debug=1?

I couldn't attach the Wireshark log so I'm attaching an image.

(you can attach .zip file if needed)

[VenkateswaranJ]

What do you see from the server-side? Can you see the packets arriving? Any message print by the kernel with mptcp_debug=1?

Yes, I can see the syn packet arrive on the server-side, but it's not sending back syn+ack so the client retries for 3 times (I have set syn retries to 3) and close subflow. I don't see any message on debug window on the server-side. I even don't see anything strange on /proc/net/mptcp_net/snmp

This is my test setup:

I have connected two PCs straight away and didn't configure source routing. I can able to ping both IPs from server to client and vice versa.

Here is my mptcp configuration on both sides

kernel.osrelease = 4.19.126.mptcp
net.mptcp.mptcp_checksum = 1
net.mptcp.mptcp_debug = 1
net.mptcp.mptcp_enabled = 1
net.mptcp.mptcp_path_manager = netlink
net.mptcp.mptcp_scheduler = redundant
net.mptcp.mptcp_syn_retries = 3
net.mptcp.mptcp_version = 0

Note: The problem is only on creating a subflow between 10.100.130.3 <----> 10.100.66.2 and I can able to create other combinations.

Test 1:

1. Created a mptcp connection between 10.100.66.2 <----> 10.100.66.3 via netcat.
2. Sent a test message ('yes') from 10.100.66.3 to 10.100.66.2 and this makes the connection established on the client-side (10.100.66.3).
3. Try Creating subflow between 10.100.130.3 <----> 10.100.66.2, but this gets failed after 3 syn tries.
4. Sent a test message ('yes') from 10.100.66.2 to 10.100.66.3 and this makes the connection established on the server-side (10.100.66.2).
5. Now retrying create subflow between 10.100.130.3 <----> 10.100.66.2 and it works this time.

Test 2:

1. Created a mptcp connection between 10.100.66.2 <----> 10.100.66.3 via netcat.
2. Sent a test message ('yes') from 10.100.66.3 to 10.100.66.2 and this makes the connection established on the client-side (10.100.66.3).
3. Try Creating subflow between 10.100.130.3 <----> 10.100.66.2, but this gets failed after 3 syn tries.
4. Announce 10.100.66.2 to the client-side (with id 0) even though it's the primary connection.
5. Now retrying create subflow between 10.100.130.3 <----> 10.100.66.2 and it works this time.

Test 3: (fullmesh)

1. Changed the path manager to fullmesh from netlink.
2. Created a mptcp connection between 10.100.66.2 <----> 10.100.66.3 via netcat.
3. Sent a test message ('yes') from 10.100.66.3 to 10.100.66.2 and this makes the connection established on the client-side (10.100.66.3).
   4. Creates 3 subflows including the 10.100.130.3 <----> 10.100.66.2 one. How it's possible this time :confused: :confused: :confused:

I even tried with the default scheduler but the results are the same.

I have attached the pcap for all three tests.

pcap.zip

[matttbe]

Mmh, I'm not sure, sorry.

I think your "Test 2" is what is more covered: the HAG sends an ADD_ADDR and switch to fully established without waiting to send new data.

On your test 3, did you only change the PM on the client side? If Fullmesh is set on the server side, it will also send ADD_ADDR.

[VenkateswaranJ]

I think your "Test 2" is what is more covered: the HAG sends an ADD_ADDR and switches to fully established without waiting to send new data.

HAG means?

On your test 3, did you only change the PM on the client side? If Fullmesh is set on the server side, it will also send ADD_ADDR.

No, I did both sides look at packet numbers 4,5 in the test3 server log. Addresses getting announced from both side but it only announce secondary IPs 10.100.130.2 & 10.100.130.3, not the primary one.

I wonder how fullmesh could pass this test. I have these tests with a source-routed setup but the results are the same.

[matttbe]

I think your "Test 2" is what is more covered: the HAG sends an ADD_ADDR and switches to fully established without waiting to send new data.

HAG means?

Sorry, I meant to say server.

On your test 3, did you only change the PM on the client side? If Fullmesh is set on the server side, it will also send ADD_ADDR.

No, I did both sides look at packet numbers 4,5 in the test3 server log.

Ack!

Addresses getting announced from both side but it only announce secondary IPs 10.100.130.2 & 10.100.130.3, not the primary one.

yes, that's expected then all good!

I wonder how fullmesh could pass this test. I have these tests with a source-routed setup but the results are the same.

Is it not because the server will quickly announce the different addresses it has?

[VenkateswaranJ]

Is it not because the server will quickly announce the different addresses it has?

I don't know :confused: let this issue open for some time. I'll try to figure out what's happening on the kernel side and get back.

[VenkateswaranJ]

The only workaround I can get from userspace is to announce IP from the server-side only the connection gets established and start creating subflows from the client-side after the first announcement.