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. _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
