mwan3, mwan4, and the next steps

[Etienne Champetier]

(resending as text for the mailing-list)

Hello Jonas,

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.

Le ven. 14 nov. 2025 à 15:12, Jonas Lochmann
<openwrt at jonaslochmann.de> a écrit :
>
> So I took a look at mwan4 now and it looks like a skeleton. And I took a
> look at ucode and its capabilities: ubus and netlink are supported. I
> don't know how complete the netlink part is, but there was at least
> something with routes and it seems to be extendable at runtime by shared
> libraries exposing APIs in a certain way.

or we can build libraries/bindings in C if needed,
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.

> Now I think that mwan3 could be modernized step by step:
>
> 1.  replace the rpcd based ubus interface of mwan3 by a "real" service
>     implemented with ucode - but doing the same thing it does currently
>
> 2.  manage state in the ucode service and not in files; provide a ubus
>     interface to get and set parameters

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
- ???

> 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 / ...)

> 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.

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

> 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 ?
In the first case we might be limited by being single threaded if we
track a lot of wans.
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 ?

> Those steps could be rearranged in many ways, but there are some
> dependencies between them.
>
> I could start with point 1 but I would like to get an OK from Florian
> Eckert first before I start this. I have to think where I can test this
> without annoying anyone.

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.

Best
Etienne