I think that the code from Etienne would be dropped long term. I dislike the design of keeping "variables" in the file system. Yes, it's the ramdisk, I know. But after removing that, not much is left from that ucode development. I see the same issue for mini-mwan - it communicates using files that contain the current status.
Regarding simple solutions: Before I introduced mwan3, a simple in house solution based on iperf, a cron job and a simple route replacement was used. That provided a kind of HA (failover without manual actions), but no load balancing at all. This looks like mini-mwan, altough it uses pings instead and does not use cron. I did not took a closer look at mwan4 yet, but I like the idea. What is done in it and what is missing? I don't know the possibilities of ucode. If it does not have good support for parallel processing (ubus, subprocesses for pings), I actually consider that mwan4 (the C implementation) a good path forward. Regarding nftables: I see other options: - using fw4 as a foundation (thus using its fw4 table); its hook mechanism most likely needs to be extended to make this usable - using the library version of nftables libnftnl (yes, this is still nftables, but much nicer than generating text to just throw it into a parser as fw4 does it) I assume that using an own mwan table in nftables would be useful. The priority system in nftables is flexible enough to make this work correctly. I see that we should have talked earlier about this topic. _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
