The traffic does not switch to the functioning network interface when one of the interfaces goes down

[stt12706]

Expected Behavior

Use two interfaces for MPTCP aggregation. When one of the interfaces disconnects, the iperf traffic should continue transmitting.

Current Behavior

When one of the network interfaces used for MPTCP aggregation disconnects, the iperf traffic drops to 0 bps and does not switch to the remaining network interface.

Possible Solution

Steps to Reproduce the Problem

1. use iperf3 to send traffic iperf3 -c iperf3.moji.fr -i1 -t600 -p5222
2. disconnect wanX by ifdown wanX
3. iperf3 traffic drops to 0 bps

Context (Environment)

Specifications

• OpenMPTCProuter version: v0.63-snapshot
• OpenMPTCProuter VPS version: 0.1032
• OpenMPTCProuter VPS provider: self-hosting
• OpenMPTCProuter platform: asus tuf ax4200
• Country:

[stt12706]

I checked the logs, and when I disconnect one of the interfaces, the iperf traffic continues to transmit until the notification

user.notice firewall.omr-server: Firewall reload, set server part firewall reloading

appears. After that, the traffic drops to 0 bps.

Below are the complete logs from the moment the disconnection occurred.

Tue Apr  1 10:50:09 2025 daemon.notice netifd: wan1 (18403): udhcpc: received SIGTERM
Tue Apr  1 10:50:09 2025 daemon.notice netifd: wan1 (18403): udhcpc: unicasting a release of 192.168.50.33 to 192.168.50.1
Tue Apr  1 10:50:09 2025 daemon.notice netifd: wan1 (18403): udhcpc: sending release
Tue Apr  1 10:50:09 2025 daemon.notice netifd: wan1 (18403): udhcpc: entering released state
Tue Apr  1 10:50:09 2025 daemon.notice netifd: wan1 (18403): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "wan1" } (Permission denied)
Tue Apr  1 10:50:09 2025 daemon.notice netifd: Interface 'wan1' is now down
Tue Apr  1 10:50:09 2025 daemon.notice ttyd[7006]: [2025/04/01 10:50:09:2306] N: rops_handle_POLLIN_netlink: DELADDR
Tue Apr  1 10:50:09 2025 kern.info kernel: [414912.175879] mtk_soc_eth 15100000.ethernet eth1: Link is Down
Tue Apr  1 10:50:09 2025 daemon.notice netifd: Interface 'wan1' is disabled
Tue Apr  1 10:50:09 2025 daemon.notice netifd: Network device 'eth1' link is down
Tue Apr  1 10:50:09 2025 daemon.notice netifd: Interface 'wan1' has link connectivity loss
Tue Apr  1 10:50:14 2025 user.notice post-tracking-001-initialize: Routes not correctly set for wan1 (eth1 table 7) with IPs 192.168.50.33
Tue Apr  1 10:50:16 2025 user.notice post-tracking-001-initialize: Restart OMR-Tracker
Tue Apr  1 10:50:16 2025 user.notice omr-tracker: Launching...
Tue Apr  1 10:50:19 2025 user.notice firewall.omr-server: Firewall reload, set server part firewall reloading
Tue Apr  1 10:50:20 2025 user.notice omr-bypass: Starting OMR-ByPass...
Tue Apr  1 10:50:23 2025 user.notice omr-tracker: Launched
Tue Apr  1 10:50:23 2025 user.notice post-tracking-002-error: wan1 (eth1) switched off because link down
Tue Apr  1 10:50:24 2025 user.notice post-tracking-002-error: Delete default route to 211.xx.xx.xx dev eth1
Tue Apr  1 10:50:25 2025 daemon.info omr-tracker-ss: Reload Shadowsocks Rust rules
Tue Apr  1 10:50:26 2025 user.notice firewall.omr-server: Firewall reload, set server part firewall reloading
Tue Apr  1 10:50:27 2025 user.notice omr-bypass: OMR-ByPass is running
Tue Apr  1 10:50:30 2025 user.notice firewall.omr-server: Firewall reload, set server part firewall reloading
Tue Apr  1 10:51:01 2025 user.notice omr-schedule-010-services: Set firewall on server vps

the result of ip r before the disconnection:

default via 10.255.252.1 dev tun0
default via 192.168.50.1 dev eth1 metric 1
default via 192.168.50.1 dev eth1 metric 7
default via 192.168.123.254 dev lan3 metric 10
10.255.252.0/24 dev tun0 proto kernel scope link src 10.255.252.3
192.168.50.0/24 dev eth1 scope link metric 7
192.168.50.1 dev eth1 scope link metric 7
192.168.100.0/24 dev br0 scope link metric 9999
192.168.123.0/24 dev lan3 scope link metric 10
192.168.123.254 dev lan3 scope link metric 10
211.xx.xx.xx metric 1
	nexthop via 192.168.50.1 dev eth1 weight 100
	nexthop via 192.168.123.254 dev lan3 weight 1

after:

default via 10.255.252.1 dev tun0
default via 192.168.123.254 dev lan3 metric 1
default via 192.168.123.254 dev lan3 metric 10
10.255.252.0/24 dev tun0 proto kernel scope link src 10.255.252.2
192.168.100.0/24 dev br0 scope link metric 9999
192.168.123.0/24 dev lan3 scope link metric 10
192.168.123.254 dev lan3 scope link metric 10
211.xx.xx.xx via 192.168.123.254 dev lan3 metric 1

[Ysurac]

You are running iperf from the router or from a client ?

[stt12706]

I run iperf from the router

[stt12706]

I just tested from the client side, and iperf still encounters the issue where the traffic drops to 0.

[lhc1993]

Is there any progress on fixing this?

[Ysurac]

Can you try latest snapshot ?

[stt12706]

Alright, I'll give it another try. Thanks

[stt12706]

I’m currently using the QNAP 301W, and the latest snapshot I’m on is from March 26, 2025. But I noticed that others seem to be using versions from April 10, so this probably isn’t the latest version, right?

[Ysurac]

Currently QANP 301W snapshot doesn't compile, will be ok on next snapshot.

[stt12706]

Got it, thank you

[stt12706]

Hi Ysurac, I created the latest snapshot for QNAP 301W and tested it.
After I unplugged the wan1 (master), the iperf3 traffic successfully failed over to wan2 and didn't drop to 0.
However, when I plugged wan1 back in, the iperf traffic did not aggregate. it only continued on wan2.
I tested bot TCP and UDP separately, and this issue only occurs with TCP.
By the way, the proxy I'm using is Shadowsockets-Rust, and the VPN is Glorytun UDP.

[stt12706]

If I instead unplug wan2, the iperf traffic also doesn’t drop to zero.
After plugging wan2 back in, I can see the iperf traffic showing a combined effect of wan1 + wan2.

[Ysurac]

Did you try with iperf -R ?