Am Wed, Mar 25, 2026 at 10:59:18AM +0000, schrieb Simon Iremonger 
(openwrt-devel) via openwrt-devel:
> https://openwrt.org/docs/guide-user/network/wan/multiwan/mwan3
> 
> ?  ...

I have no account at the wiki. Anyone could put a link to a mailing
list archive to the corresponding message.

> > This is solved in my OpenWrt fork. Patches were submitted, but not
> > reviewed or accepted yet. And the patches are not new. That's why
> > I started my fork.
> 
> Has this reached a stable point, can we look at getting this backported
> into master and potentially 25.12 series?  What would be pragmatic and
> appropriate?  Would refactored version have a new name, mwan4 etc?

This is working stable and used in production. As far as I can see, my
current solution consists of netifd patches [1, 2, 3]. There is no need
to do any mwan4 or other renaming when fixing problems. There is one
PR for mwan3 to avoid issues when IPs change [5]. This is not in my
fork right now and only needed in one particular environment I know.
(one particular provider)

> **NB** One classic limitation of mwan3 package, is that it will tend
> to disable IPv6 by default.  The 'defaults' definitely need changing
> so mwan3 installation does not cause a regression if not yet configured.

The defaults use questionable hosts for checking the connections. You could
put empty defaults (= do nothing) or provide bad defaults - you cannot
provide useful ones. Moreover, if mwan3 should touch IPv6, you need to
enable NAT or provide another solution. I implemented a NAT that should
be less intrusive than the default one [4]. This one was discussed
and not accepted with the main reason that there is no standard (RFC)
describing what it does. So currently only rewriting all source IPs to
those of the router is possible.

> This may or may not have been sorted already...  In any case, what would
> now be pragmatic and sensible, to document and tidy up the situation for
> mwan3 in 25.12 "as-is"?

- regular masquerade nat is needed (or any alternative)
- only works stable with static IPs as upstreams

[1] 
https://patchwork.ozlabs.org/project/openwrt/patch/qfixcrgjoxeyenoritmrzaeskfc2aotl2bivf7k3mdvfevweuk@5fneri2ckmj7/
[2] 
https://patchwork.ozlabs.org/project/openwrt/patch/t2z6asxwyyuvjjkm7qup2seyzquxwdrripksvcy7vsnhsrupr3@g5hwluee5jns/
[3] 
https://patchwork.ozlabs.org/project/openwrt/patch/yurztna63qhlz5hucg7f6nzhcrpazy7yt56hvvuhknvxqdhejw@2cfhybizk6pd/
[4] 
https://patchwork.ozlabs.org/project/openwrt/patch/[email protected]/
[5] https://github.com/openwrt/packages/pull/27745

_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to