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

How to know remote side interface index #454

Closed VenkateswaranJ closed 2 years ago

VenkateswaranJ commented 2 years ago

is there any way to know the remote side interface index? when I receive the subflow established Netlink event, I want to know from which remote interface this subflow has been established.

https://github.com/multipath-tcp/mptcp/blob/d6c8c0c0ca6cfd3992a925acee79df9cdc2f0a7f/include/uapi/linux/mptcp.h#L69-L72

I see the if_idx parameter in subflow established Netlink event but this represents the local interface index and not the remote one isn't it ?

Basically, I want to identify the below connection scenario on Host1.

mptcp

On Host1 I need to know whether both of my subflow established to the same interface on the remote side or a different one. So that I can say the connection is redundant or not. In the above case even though I have multiple subflows the connection is not redundant (if I pull out the cable from eth1 on Host2 then the Mptcp connection will close).

I may differentiate with destination IP address but sometimes the same interface has multiple IP then this logic won't work. So the correct way to Identify redundant paths is to identify connections between interfaces.

matttbe commented 2 years ago

Hello,

Mmh, if I'm not mistaken, the MPTCP_ATTR_LOC_ID and MPTCP_ATTR_REM_ID attributes are also added in the event but they seem missing in the doc.

Do you not have them?

VenkateswaranJ commented 2 years ago

The IDs are referring to the IP address not the interface. What happens if same interface has two static IP configured then I can't say from which remote interface this subflow has been created.

I just wants to know whether I have created subflows between all the remote and local eth interfaces or not. Do you have any other idea to figure this out ?

matttbe commented 2 years ago

The IDs are referring to the IP address not the interface.

Correct.

What happens if same interface has two static IP configured then I can't say from which remote interface this subflow has been created.

No indeed.

I just wants to know whether I have created subflows between all the remote and local eth interfaces or not.

In the protocol, hosts only announce IP, not interfaces.

To avoid that, the host2 can also only announce IPs that makes sense, e.g. only IPs of other interfaces. Would it be OK for you?

VenkateswaranJ commented 2 years ago

To avoid that, the host2 can also only announce IPs that makes sense, e.g. only IPs of other interfaces. Would it be OK for you?

Yepp, that's what I'm doing right now, but I wonder that major use case of mptcp is providing redundant connection between client and server and we can only say that I have redundant connection by checking whether I have connections on different physical paths ( not by checking whether I have connections to different remote IPs) so that's reason I want to know the remote side physical interface or some kind of recognizing paths.

But yes if it's not defined in protocol itself then nothing to discuss here.

Please close this issue.

matttbe commented 2 years ago

Yepp, that's what I'm doing right now, but I wonder that major use case of mptcp is providing redundant connection between client and server and we can only say that I have redundant connection by checking whether I have connections on different physical paths ( not by checking whether I have connections to different remote IPs) so that's reason I want to know the remote side physical interface or some kind of recognizing paths.

Yes I understand your point but in some cases, you can also have different IPs on the same interface and different paths will be used to reach them. Likely v4 and v6 IPs on the same interface will go through different paths.

But yes if it's not defined in protocol itself then nothing to discuss here.

Indeed :-/