mwan3 and IPv6

[Jonas Lochmann]

I consider IPv6 support independent of mwan3 refactoring. It works in
my setup.

Regarding the IPv6 tracking, there is the issue with the source IP
selection.

Issue 1: removed (zero valid lifetime) IPv6 prefixes were kept as
deprecated by odhcp6c [1]. The fix was merged two weeks ago. This
should not have caused issues in mwan3 because deprecated prefixes
should be avoided, but my attempt to fix that failed because the
system lib change my mwan3 fix implementation depended on was not
merged without a reason for a rejection [2, 3]. The current
implementation just uses the first IP.

Issue 2: Which first IP? In the end, the first one reported by odhcp6c
because netifd keeps that sorting and returns that when someone queries
it [4]. I am using an unpublished patch that sorts the IP by their
"number" in netifd to deterministically get one IP as the first IP.
This helps because odhcp6c adds new IPs as they are received at the
end of the list. So you can start with [public IP, private IP] and
once the public changes, it is [private IP, public IP] and pinging
only works from the public one/when the public one is the first one.
Another solution is forcing the fallback to the ip utitiliy instead of
asking netifd in mwan3 because it sorts the IPs or gets them sorted
from the kernel.

Solution from the mwan3 side: better source IP selection. This is
independent of other changes and only affects one particular routine.
So public IPs and non deprecated IPs should be preferred. The open
question is what happens if there is a private IP and a deprecated
public IP.

Without knowing ddns-scripts, they could be affected by the same issues.
When asking a web service, then the kernel just picks the source IP
and usally does a good job when doing that.

Regarding the NAT: I have my patch for prefix rewriting using fw4 [5].
There was no feedback that helped improving it and still no one feeling
the need to merge it. This implementation rewrites the prefix if it
does not fit to the output interface and otherwise keeps the address
as it is. Because this is ucode, one can just apply the patch on the
device itself and then add a masquerade-prefix instead of a masquerade
rule.

Now, one could add this to mwan3 instead once it uses nftables. Still,
I consider this functionality useful even without mwan3, so it belongs
to fw4 or some extra package, but the hooks provided by fw4 are not
flexible enough for this use case.

[1] https://github.com/openwrt/odhcp6c/pull/108
[2] https://github.com/openwrt/packages/pull/23057
[3] https://github.com/openwrt/openwrt/pull/14333
[4] https://lists.openwrt.org/pipermail/openwrt-devel/2025-October/044321.html
[5] https://lists.openwrt.org/pipermail/openwrt-devel/2025-October/044301.html

Am Mon, Nov 17, 2025 at 10:36:04AM +0000, schrieb Simon Iremonger:
> On 16/11/2025 17:42, Jonas Lochmann wrote:
> > 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.
> 
> Just to observe, in OpenWrt 24.10.4 mwan3 and ddns-scripts packages :-
> 
> * mwan3 IPv6-tracking never seemn to work, never finds interface 'up'
>    despite the IPs in config pinging perfectly fine.  Maybe this
>    did work in older OpenWrt but not 24.10 series?
> 
> * ddns-scripts IPv6 interface or IPv6-scrape [using
>     suggested checkipv6.dyndns.com or other tests], others report
>     having to use external script as workaround.
> 
> I may well be able to help testing newer builds/tests in time for
> IPv6-enabledness; I have many IPv6 blocks, dynamic via other ISP,
> one DHCPv6, one static routing, etc --so options to do so.
> 
> I would like to see convenient options for NAT66/etc options
> for failover IPv6 to work more easily / integrated where
> appropriate.  I do wonder if there are better ways this
> could or 'should' work that involve changing routing metrics
> on the fly so that current global address ranges get prioritised.
> 
> 
> --Simon
>