mwan3, mwan4, and the next steps

[Jonas Lochmann]

Am Sat, Nov 15, 2025 at 09:57:03PM -0500, schrieb Etienne Champetier:
> Pretty excited about this rewrite effort,
> don't know if I'll have much time to write code, but I'll definitely
> try to review / test.

This should be enough.

> or we can build libraries/bindings in C if needed,

That is what I was referring to.

> for example I would like mwan4track to ping / http(s)ping directly
> without exec-ing an external binary,
> we might need something to "ping" (ICMP echo) from ucode.

I am not a fan of this idea. I would like to keep complex network
interactions out of the service - ideally running with less privileges.
The ICMP ping could be an exception, but this would complicats stuff.

> Maybe sum up the goals of having a main mwanX service, my list:
> - avoid serialisation to file in ramdisk
> - communicate via ubus
> - hot config reload, keeping the current mwanXtrack / mwanXrtmon
> status on reconfig / causing less interruption
> - ???

This fits my goals. Another one is avoiding race conditions.

> 
> > 3.1 manage the rtmon instances in the ucode service instead of using
> >     procd and the init script for that
> 
> If we need multiple processes / small services, why manage the
> processes in ucode
> when procd is a service manager ? The init script when using `USE_PROCD=1`
> just make an ubus call to have procd launch a new process, so you can
> do just that,
> and benefit from the procd features (ujail / respawn / ...)

This is to split the transition into multiple parts. First manage it by
the new service, then remove the subprocess.

> > 3.2 implement rtmon within that service in ucode
> 
> I would start with rewriting mwan3rtmon in ucode as it's self contained and
> is where we could find (temporary) blockers with the netlink bindings.

There will be no blockers because one could always call the "ip" binary.

> Also at this stage do you just want to do a rewrite or also change how
> it works ?
> (I'm fine either way)

When you ask for it: I would replace the incremental routing table update
by a routine that calculates the new one. This would be triggered by any
route change in the main table (with debouncing this to limit it to once
per second).

> > 4.1 manage mwan3track instances by the ucode service
> > 4.2 implement mwan3track within the service in ucode
> 
> Do you want a single ucode process to track all wans ? Or keep 1
> process per wan ?

Only one process.

> In the first case we might be limited by being single threaded if we
> track a lot of wans.

What's a lot? How powerful hardware would we expect in this cases?
I never have more than three wans and always run mwan3 at x86 hardware.

> In the second case having each track instance managed by procd makes
> sense to me,
> i.e. having the main mwanX process (re)load the config, launch
> mwanXtrack instances via ubus,
> and the mwanXtrack sends back the status update via ubus.
> 
> > 5. replace iptables calls by nftables/libnft calls
> 
> Same question as with rtmon, do you want to rewrite as is first and
> optimise later ?

I would start with nftables here and again with a functional style:
just generate the new configuration when it changes.

> For the tests I recommend you to just use an OpenWRT VM,
> with virt-manager (libvirt) you create multiple NAT virtual networks
> for the wans.

Yes, this should be good start.