ddns-scripts: Binding to specific wan makes curl timeout

Package Name

ddns-scripts

Maintainer

@feckert

OpenWrt Version

24.10.5

OpenWrt Target/Subtarget

bcm27xx/bcm2711

Steps to Reproduce

1. PPPoE WAN using only IPv6 connectivity and IPv4 tunnel ("Dual-Stack Lite")
2. Use duckdns.org or any other DynDNS provider that only has IPv4 connectivity (but supports AAAA records). In my case, I used the "custom" configuration. I closely followed the process as documented in the user guides
3. Setup ddns-scripts to WAN_6 (the virtual dynamic interface created by the ds-lite package, as the WAN interface itself does only obtain a private fe80::)
4. On do_transfer() curl hangs for 300s before timeout makes the process fail

Actual Behaviour

The issue as far as I understand stems from the WAN layout my ISP provides. Here in Germany, DS-Lite is quite common as transitioning technology towards IPv6. You receive a public IPv6 and an AFTR (an ISP provided router in IPv6 land that your router needs to establish a tunnel to to obtain IPv4 connectivity - basically a fancy CGNAT). The implementation of ds-lite in OpenWRT creates two virtual interfaces, WAN_6 and WAN_6_4, to represent this. The first one being the actual WAN and the second one being said tunnel for v4 traffic.

At the same time, duckdns only has an IPv4 address itself as AWS does not provide IPv6 to their account type or something. This combination makes it necessary to update the AAAA record using an IPv4 connection as my router is only reachable via IPv6 from the outside and duckdns is only reachable via IPv4.

In dynamic_dns_functions.sh:do_transfer() a check is done to bind curl to a specific interface. In my case, WAN_6 (the virtual one) needs to be specified as the interface and ip_network as it is the one containing the actual public IPv6. Binding curl to this interface however makes the routing to duckdns impossible as only IPv6 connectivity is available there, resulting in the observed timeout.

As a workaround I noticed that in said function, a check is done which allows to manually specify a bind_network in the config files. Setting this to the WAN_6_4, the process succeeds and the AAAA record gets updated. Alternatively, not binding curl to any interface allows it to find a successful route, too. Binding curl probably actually serves a good purpose, but is counterproductive here.

I realize that this issue could be resolved with changes in LuCI (luci-app-ddns), too. As a config option there would allow to bind to the appropriate, different WAN. Alternatively, adding documentation for this sort of issue might save others some headache. I'm not sure what the best option would be.

Cheers!

Confirmation Checklist

• The package is maintained in this repository.
• I understand that issues related to the base OpenWrt repository or LuCI repository will be closed.
• I am reporting an issue for OpenWrt, not an unsupported fork.

Start with dynamic_dns_functions.sh, especially do_transfer(), and reproduce the timeout using the WAN_6 and WAN_6_4 arrangement described. Compare the bind_network workaround with the interface and ip_network settings, then review the linked DuckDNS user guide. Done means an agreed code or documentation change that supports this DS-Lite routing case.