4 ms·

MPTCP has been on my radar for a long while and seems very cool. I will say that for seamless wireless/wired switching, Linux bonding works very well. ~15+ ye

MPTCP has been on my radar for a long while and seems very cool. I will say that for seamless wireless/wired switching, Linux bonding works very well. ~15+ years ago I had my laptop set up with eth and wifi bonded, with eth as the preferred, I believe using link-beat as the method. I could be running a big copy, plug in the ethernet and the transfer rate would almost instantly shoot up, and then when done I could unplug and all of my connections would stay up. As WiFi got faster and faster, I used this less and less, so I haven't had it set up for for quite a few years now. But it does show the promise of MPTCP.

globalc 4y ago
Nice, was not sure how stable such a setup would be. The applications will not need further modification and just need to be sent over the bond. For MPTCP, as of today the applications over the mptcp-stream (which has subflows over the 2 media) need to be modified to use MPTCP, or an additional layer like with shadowsocks needs to be used to transparently encapsulate traffic over the link.
- jeroenhd 4y ago
  The article mentions the tool `mptcpize` which converts TCP into MPTCP by hooking calls to the networking API. With the tooling already there, I think this makes for an excellent use case for MPTCP.
  - iforgotpassword 4y ago
    As you need to do it on both ends it is limited to your own stuff. The bonding trick works for everything automagically.
thrtythreeforty 4y ago
Re: bonding, what a good idea! I may have to set this up on my laptop. Are there any downsides? (Besides being unable to connect to different networks of course)
- justsomehnguy 4y ago
  You need to be in the same L2/L3 domain. Not always the case for the corporate networks.
  - ale42 4y ago
    Definitely not the case in our network... IP ranges are totally different on wired and wireless here.
- globalc 4y ago
  You should pay attention to make the ethernet the preferred interface. If aggregation of bandwidth over the various underlying media is important for you: depending on the exact mode, aggregation might not work. Even if working, via bonding you might only get aggregation if the traffic goes over multiple TCP channels, while MPTCP also aggregates for a single TCP channel.
cmsj 4y ago
Yep, I used to do that when I had a thinkpad and a docking station and didn't want all my ssh sessions to drop. Before that I was even doing awful things like forcing the same IP onto both eth and wifi :D
- zootboy 4y ago
  I've had a concept in mind for this exact scenario that I'm reasonably certain will work, I've just never taken the time to fully implement it. No need to bond interfaces or apply the same IP to both interfaces. Let them both acquire different IP addresses in the same subnet. Linux will start announcing its ARP replies on the ethernet path since it has a better path metric. Thus the return path for both the wifi IP and the ethernet IP will become the ethernet link. Any existing connections that were traveling over the wifi link will just move onto the ethernet link automatically. The only difficulty is new connections. Since the ethernet path has the better metric, new connections will establish with the ethernet link's IP address. But the routing table can be adjusted to instead make the wifi link's IP address the default for both the wifi and the ethernet links. Then new connections will always use the wifi IP, and will migrate over to the wifi link when the ethernet link disappears. This should work as long as your wifi link always remains up whether or not you're in the dock.
  - linsomniac 4y ago
    I guess you could do this by just sending gratuitous ARPs for the wifi IP with the eth MAC addr, over the eth interface. Probably have to turn off rp_filter as well?
    - zootboy 4y ago
      You don't even need to do that. The ARP packets seem to be routed to the network through the normal route table, so replies for the wifi IP get sent via the ethernet link and the network switches seem to learn that as the return path. As for rp_filter, it's set to "2" on my machines, which seems to allow return packets on the "wrong" port as long as it's an address that any other port owns.

globalc 4y ago

Nice, was not sure how stable such a setup would be. The applications will not need further modification and just need to be sent over the bond. For MPTCP, as of today the applications over the mptcp-stream (which has subflows over the 2 media) need to be modified to use MPTCP, or an additional layer like with shadowsocks needs to be used to transparently encapsulate traffic over the link.

jeroenhd 4y ago
The article mentions the tool `mptcpize` which converts TCP into MPTCP by hooking calls to the networking API. With the tooling already there, I think this makes for an excellent use case for MPTCP.
- iforgotpassword 4y ago
  As you need to do it on both ends it is limited to your own stuff. The bonding trick works for everything automagically.

thrtythreeforty 4y ago

Re: bonding, what a good idea! I may have to set this up on my laptop. Are there any downsides? (Besides being unable to connect to different networks of course)

justsomehnguy 4y ago
You need to be in the same L2/L3 domain. Not always the case for the corporate networks.
- ale42 4y ago
  Definitely not the case in our network... IP ranges are totally different on wired and wireless here.
globalc 4y ago
You should pay attention to make the ethernet the preferred interface. If aggregation of bandwidth over the various underlying media is important for you: depending on the exact mode, aggregation might not work. Even if working, via bonding you might only get aggregation if the traffic goes over multiple TCP channels, while MPTCP also aggregates for a single TCP channel.

cmsj 4y ago

Yep, I used to do that when I had a thinkpad and a docking station and didn't want all my ssh sessions to drop. Before that I was even doing awful things like forcing the same IP onto both eth and wifi :D

zootboy 4y ago
I've had a concept in mind for this exact scenario that I'm reasonably certain will work, I've just never taken the time to fully implement it. No need to bond interfaces or apply the same IP to both interfaces. Let them both acquire different IP addresses in the same subnet. Linux will start announcing its ARP replies on the ethernet path since it has a better path metric. Thus the return path for both the wifi IP and the ethernet IP will become the ethernet link. Any existing connections that were traveling over the wifi link will just move onto the ethernet link automatically. The only difficulty is new connections. Since the ethernet path has the better metric, new connections will establish with the ethernet link's IP address. But the routing table can be adjusted to instead make the wifi link's IP address the default for both the wifi and the ethernet links. Then new connections will always use the wifi IP, and will migrate over to the wifi link when the ethernet link disappears. This should work as long as your wifi link always remains up whether or not you're in the dock.
- linsomniac 4y ago
  I guess you could do this by just sending gratuitous ARPs for the wifi IP with the eth MAC addr, over the eth interface. Probably have to turn off rp_filter as well?
  - zootboy 4y ago
    You don't even need to do that. The ARP packets seem to be routed to the network through the normal route table, so replies for the wifi IP get sent via the ethernet link and the network switches seem to learn that as the return path. As for rp_filter, it's set to "2" on my machines, which seems to allow return packets on the "wrong" port as long as it's an address that any other port owns.