about mptcp subflow creation question

[kangsenlu]

Pre-requisites
I am running ubuntu 6.8.0-1018 on a host, and openwrt 6.1.71 on another host.
I have two vpn tunnels created between those two hosts, namely tunUDP1 and tunUDP2.
I am trying to connect a ssh client on the ubuntu and a sshd server on the openwrt with mptcp connection which should create subflows through tunUDP1 and tunUDP2.
On the ubuntu, I configure two mptcp endpoints as follows:
ip mptcp endpoint 198.18.0.1 id 1 subflow dev tunUDP1
ip mptcp endpoint 198.18.016.1 id 2 subflow dev tunUDP2

The ssh command is as follows:
ssh -f -2nN -D 31204 -c aes128-ctr -m hmac-sha1 -p 31334 -o UserKnownHostsFile=/dev/null -o TCPKeepAlive=no -o StrictHostKeyChecking=no -o ServerAliveInterval=60 -o ServerAliveCountMax=300 -o PubkeyAcceptedKeyTypes=+ssh-rsa -i /waav/bonding/mp-bonding/proxy/ssh2/id_rsa [email protected]

My question

[matttbe]

Hi,

It looks like your question is missing.

Note that if you want SSH to use MPTCP, you will need to force it, e.g. using mptcpize because SSH doesn't support MPTCP natively (and don't want to...)

[kangsenlu]

well. I did wrapped the ssh command with "mptcpize run". I also wrapped the sshd command with the same "mptcpize run" prefix. Otherwise, I would not get multiple subflows. Correct? Kang-sen On Friday, November 22, 2024 at 12:35:10 PM EST, Matthieu Baerts ***@***.***> wrote: Hi, It looks like your question is missing. Note that if you want SSH to use MPTCP, you will need to force it, e.g. using mptcpize because SSH doesn't support MPTCP natively (and don't want to...) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[matttbe]

Correct, but then what's your question? There are no questions in your initial post. Did you put it in a comment? (Did you remove the <!-- and --> signs)?

[kangsenlu]

Yes. It is my mistake. I did not remove the encloing "<--" for my question text.Anyway, I have observed that there were 3 subflows, not 2 subflows as I expected, established for the mptcp connecton. ***@***.***:/tmp# netstat -net |grep 31334 tcp    0  0 198.18.0.1:59683    198.18.160.251:31334 ESTABLISHED 0      1524394 tcp    0  0 198.18.16.1:55421   198.18.160.251:31334 ESTABLISHED 0      1524394 tcp    0  0 198.18.0.1:23090    198.18.160.251:31334 ESTABLISHED 0      1524394My guess is that one of the subflow from 198.18.0.1 is created as the primary subflow. The other two are created because of the two mptcp endpoints being configured with the "ip mptcp endpoint add ..." command. I am surprised that two of the three subflows are duplications. It seems that mptcp subsystem is not checking for duplicated subflows. That is my question.

[matttbe]

My guess is that one of the subflow from 198.18.0.1 is created as the primary subflow. The other two are created because of the two mptcp endpoints being configured with the "ip mptcp endpoint add ..." command. I am surprised that two of the three subflows are duplications. It seems that mptcp subsystem is not checking for duplicated subflows.

It should. When the connection is fully established, it will check if the initial subflow is using the same address of an endpoint, and if yes, mark it as 'used'.

I see that you are re-using the old kernel from last time. Can you try with an up-to-date kernel first?

[matttbe]

@kangsenlu : by chance, did you manage to check with a more recent kernel?

[kangsenlu]

Thanks for the follow up. I am on vacation until next Monday. So I haven't tried it out on a later kernel. On Thursday, December 5, 2024 at 05:47:34 AM EST, Matthieu Baerts ***@***.***> wrote: @kangsenlu : by chance, did you manage to check with a more recent kernel? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>