OMR Experience

[hatemos]

  I'd like to thank the team for this trumendous work. Big up.

Here are my different scenari using OMR on Netgear R7800

I fist used Vutr (1vCore@2.4Ghz, 1Gb ram, 25Gb NVMe storage, 4To traffic) ipv4@spain

• Installed 0.59rc3-5.4 works fine (used up to 5 wans)
• I upgraded to 0.59.1 and had bootloops and 2 wans/3 are detected but not used - downgraded
• Back to 0.59rc3-5.4 works fine (used up to 5 wans)

Then I wanted to try a nearer VPS I chose octenium.com (1vCore@2.4Ghz, 2Gb ram, 60Gb RAID10 storage, illimited traffic)

• Ubuntu 20.04 LTS = file masked error during vps script install, same result with script update
• Debian 11 uses one wan only (flag: multipath blocked by ISP, marked incompatible by OMR compatibility test) (Shadowsocks and V2Ray)
• Debian 10 uses 1wan/3 (flag: green, marked incompatible by OMR compatibility test) (Shadowsocks and V2Ray)
  Debian 9 processing ... first try: error, 2nd same as Debian 10 and 11 (Shadowsocks and V2Ray)

Can the community help me with algerian VPS provider (I have full root access) so that I can reduce the ping to the server ?

Originally posted by @hatemos in #2724

[Steltek]

Did you check that the mptcp Kernel is running on your VPS (when you get the 'multipath blocked' messages)? I have had issues with grub not picking the right one sometimes.

Alternatively, you can enable "MPTCP over VPN" on the line(s) that show this issue to have the MPTCP traffic encapsulated. (I'm using Wireguard for this in the Advanced Settings, but OpenVPN should work too.)

[hatemos]

Hi @Steltek ,
Thank you vey much for your response. Tha Kernel seems to be up and running. Here's what I get when I log as root

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
< OpenMPTCProuter VPS 0.1028 >Last login: Mon Jan 9 03:30:14 2023

I tried to set MPTCP over VPN but neither WG nor Openvpn made the OMR use more than 1 wan.
I suspect some ports to be blocked by octenium. I'll open a ticket and see what would be their answer.

[Steltek]

Use
uname -a
to see which kernel you're running.

[hatemos]

I get the same Kernel version as well in the other working vps. Here's what I get

Linux ....xyz 5.4.207-mptcp #1 SMP Sun Jul 24 14:39:44 UTC 2022 x86_64 GNU/Linux

[Steltek]

So you are running the correct kernel on the VPS, but MPTCP is being blocked/filtered somewhere between your OMR and the VPS. You'll have to pass MPTCP through a VPN of some sort for it to go through. (make sure the respective VPN shows as active/enabled in OMR, e.g. for Wireguard check under Status -> Wireguard to make sure handshakes and traffic are going though).

[hatemos]

Hi @Steltek
Thank you very much for your answer. I tried OMR over vpn unsuccessfully. The Wirguard status shows handshake and data transfer.
I run this command on the server side

root@vps1vps:~# netstat -napt
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:65301 0.0.0.0:* LISTEN 8274/openvpn
tcp 0 0 0.0.0.0:65401 0.0.0.0:* LISTEN 302/dsvpn
tcp 0 0 127.0.0.1:44796 0.0.0.0:* LISTEN 8231/ss-server
tcp 0 0 0.0.0.0:65500 0.0.0.0:* LISTEN 383/python3
tcp 0 0 127.0.0.1:10085 0.0.0.0:* LISTEN 8236/v2ray
tcp 0 0 0.0.0.0:65222 0.0.0.0:* LISTEN 478/sshd
tcp 0 464 172.21.21.50:65222 "my.ip:33589 ESTABLISHED 6433/sshd: root@pts
tcp6 0 0 :::65400 :::* LISTEN 223/iperf3
tcp6 0 0 :::65500 :::* LISTEN 359/python3
tcp6 0 0 :::65222 :::* LISTEN 478/sshd
tcp6 0 0 :::65001 :::* LISTEN 4387/glorytun-tcp
tcp6 0 0 :::65228 :::* LISTEN 8236/v2ray
tcp6 0 0 :::65101 :::* LISTEN 8232/v2ray-plugin

[Steltek]

Hello,

Wireguard typically uses UDP, not TCP, so it won't show up in a netstat like the one you ran.

What does your OpenMPTCPRouter status say for the VPN link? It should look like the wgwan2 link on this screen:

Does the MPTCP Support check (Network -> MPTCP) go through on the VPN link? Does the MPTCP Fullmesh page show both links?

[hatemos]

Compatibility test with WG ifaces takes forever without any result.
Here are some captures

Fullmesh with three ip's

The last time I tried, this morning, I had all check marks green

Here's WG IO

When OMR over VPN is deactivated, unstable and unconsistent results (change every minute) compatibility test is negative.

[Ysurac]

What compatibility test you use ? And what is exactly the result ? All connections are failing ? This seems strange if it's not same provider.
You have a quite high CPU usage on router side. You should try to disable and enable connection one by one.

[hatemos]

I use the embedded compatibility test Network>MPTCP-Support check result (without OMR over vpn):
-TCPOptionMPTCPCapable
In fact there are two scenarios: a working vps (vultr) which ip's located in Spain (no problem whatsoever); and an algerian-based VPS (I'w like to use reduce the OMR-VPS travel latency) where I didn't manage to run more than 1 wan (master is used), this is my main problem. Either the OS images they provide (ubuntu 18, 20.04, Debian 9,10 and 11) are altered or some ports are blocked on their side. Which ports exactly do we need for OMR to work?
Though I've noticed that high CPU load in comparison with openwrt, I thought it was normal untill I compared the values with those @Steltek posted earlier in this feed. Maybe the router setup process is the reason.
Can I use a local dedicated linux server on a seperate desktop PC to replace the provider's vps ?
Thank you @Ysurac for this tremendous work.

[Ysurac]

If the VPS was rebooted after install, it seems that provider is blocking MPTCP.
VPS/server must have an higher Internet connection than all your connection aggregated. So it must be in a datacenter or at another place with a high bandwidth.

[hatemos]

Thanks @Ysurac that makes sens. And yes the server has been rebooted many times, with different linux distros.
Speaking of the high cpu load, I think my R7800 cpu is quite choking (see the blank load charts in attachments)when the global input is near 10-11 MB/s . The download stops and restarts (Free DM v6.18.0). Is this activity normal?

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days