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