Mwan3 stopped working

I’m having a problem with my mwan3 setup - probably since the 3.11 update but as I didn’t get an upgrade notification I’m not 100% sure.
I have two connections, PPPOE via VDSL Modem and Cable via Provider-Router (UM ConnectBox).
This was working fine for 1+ years, I’ve set up some rules based on source/dest IP, TCP/UDP ports etc.
Now both Interfaces show as offline, and therefore the rules do not work (traffic is using only wan Interface).
I’m not sure if the error message regarding “local” was there before as I usually did my configuration via Luci.

root@turris:~# mwan3 status
/lib/mwan3/mwan3.sh: line 3: local: can only be used in a function
Interface status:
interface wan2 is offline and tracking is down
interface wan is offline and tracking is down

Current ipv4 policies:

Current ipv6 policies:

Directly connected ipv4 networks:

Directly connected ipv6 networks:

Active ipv4 user rules:

Active ipv6 user rules:

root@turris:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth1
0.0.0.0 62.155.246.44 0.0.0.0 UG 0 0 0 pppoe-wan2
10.85.3.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
10.85.4.0 10.85.4.2 255.255.255.0 UG 0 0 0 tun_turris
10.85.4.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun_turris
62.155.246.44 0.0.0.0 255.255.255.255 UH 0 0 0 pppoe-wan2
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth1
192.168.21.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.9

root@turris:~# ping -4 -c 3 -W 1 -I eth1 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=122 time=23.540 ms
64 bytes from 8.8.8.8: seq=1 ttl=122 time=13.103 ms
64 bytes from 8.8.8.8: seq=2 ttl=122 time=17.934 ms

— 8.8.8.8 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 13.103/18.192/23.540 ms
root@turris:~# ping -4 -c 3 -W 1 -I pppoe-wan2 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=125 time=19.149 ms
64 bytes from 8.8.8.8: seq=1 ttl=125 time=19.291 ms
64 bytes from 8.8.8.8: seq=2 ttl=125 time=19.239 ms

— 8.8.8.8 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 19.149/19.226/19.291 ms

root@turris:~# cat /etc/turris-version
3.11

It got to stable roughly 22h ago. I’m not sure how quickly it would notice and perform the update in your case, but you’d probably see in log if it hasn’t restarted yet.

I had an unsolicited restart yesterday, after which I noticed the mwan3 didn’t work anymore.
I did not get any of the emails I usually get though.
I did reboot multiple times yesterday while troubleshooting the mwan issue.
Now it looks like I’m on 3.11, at least there seem to be no pending updates:

root@turris:~# uptime
 14:19:01 up 14:13,  load average: 0.79, 0.75, 1.03
root@turris:~# cat /etc/turris-version 
3.11
root@turris:~# pkgupdate 
WARN:Script file:///usr/share/updater/localrepo/localrepo.lua not found, but ignoring its absence as requested
WARN:Requested package luci-i18n-ddns-en that is missing, ignoring as requested.

Right, I’m also missing the usual e-mail notification about my upcoming delayed update, but that’s most likely a separate issue.

Hello,

I see. In upcoming version of Turris OS 3.11.1, I’ve ugraded the mwan3.
Can you please tell me if it works for you once we’d release it to have any feedback about it? :slight_smile:

Unfortunately after the upgrade to 3.11.1 it still doesn’t work:

root@turris:~# cat /etc/turris-version
3.11.1
root@turris:~# mwan3 status
Interface status:
interface wan2 is offline and tracking is down
interface wan is offline and tracking is down

Current ipv4 policies:

Current ipv6 policies:

Directly connected ipv4 networks:

Directly connected ipv6 networks:

Active ipv4 user rules:

Active ipv6 user rules:

I face a similar problem with Turris OS 3.11.1 and mwan3. In addition, there seems to be an error with the mmx_mask option (default value: 0x3F00). Here is the error I get when starting the mwan3 service with the default configuration.

> /etc/init.d/mwan3 restart
ip: invalid argument '0x3d00/0x3F00' to 'fwmark'
ip: invalid argument '0x3e00/0x3F00' to 'fwmark'
ip: invalid argument '0x3d00/0x3F00' to 'fwmark'
ip: invalid argument '0x3e00/0x3F00' to 'fwmark'
ip: invalid argument '0x100/0x3F00' to 'fwmark'
/sbin/hotplug-call: /etc/hotplug.d/iface/15-mwan3: line 481: network_get_metric: not found
 103710  WARN : Service section disabled! - TERMINATE
 103710  WARN : Service section disabled! - TERMINATE

> mwan3 interfaces
Interface status:
 interface wan is error and tracking is active
 interface wan6 is unknown and tracking is down
 interface wanb is unknown and tracking is down
 interface wanb6 is unknown and tracking is down

Was this ever solved as I realized that I just created a topic for the same problem. Would be really great to fix mwan3 finally. Seems it’s broken since a long time and I’m on latest stable

I’m on the nightly and mwan3 is still broken, I had to uninstall it as otherwise after any small interruption of my ISP (nightly modem firmware updates…), the Omnia would stay without WAN connection until a reboot. I would love to see mwan3 supported again by TurrisOS, it’s working well on a vanilla OpenWRT/LEDE.

Would you guys from turris please finally fix mwan3 you have broken. It used to work and is known to work on default Openwrt so turris broke it somehow. It’s also very troublesome that turris seems to just ignore stuff they broke which doesn’t help keeping a turris omnia as a reliable product.

For me everything works fine again since Dec. '18 after re-creating the config as suggested in the other thread Mwan3 after update not working

Which post in that thread are you refererring too? My wan connection still shows state ‘error’ even with newest mwan3 which just got installed with some ujpdates. Now the fwmark errors are gone but wan interfacxe is still not working. What config change is needed to make it work?

Mainly the post #19 from fnord Mwan3 after update not working .
I remember I tinkered a bit at first, trying also the modifications from post #20 while keeping my existing config but it only started to work once I started to configure from scratch again.
If I read the thread correctly the modifications described should be provided by updates in the meantime, but it probably doesn’t hurt to take a look at the scripts directly if it still doesn’t work with a new config.