Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ddns-scripts: use ip_network as default for bind_network #13182

Closed
mrjoel opened this issue Aug 21, 2020 · 4 comments · Fixed by #13183
Closed

ddns-scripts: use ip_network as default for bind_network #13182

mrjoel opened this issue Aug 21, 2020 · 4 comments · Fixed by #13183

Comments

@mrjoel
Copy link
Contributor

mrjoel commented Aug 21, 2020

Environment: OpenWrt current snapshot

I'm running into an issue where the incorrect IPv6 address is used for comparison when determining whether an update is needed.

The DNS API service used autodetects the IPv6 address from the source address of the request, which ends up being the address assigned to wan6 (br-wan). This all works as expected, using use_ipv6 and force_ipversion.

The issue is that on every check interval, the DNS lookup is made (and gets the correctly submitted WAN address), however it is compared against the LAN IPv6 interface address instead of the wan6 address. As a result it doesn't match and thinks an update is needed.

What may be confusing things is that I have multiple networks (LAN and Guest), so have the wan6 network interface in /etc/config/network configured with option reqprefix '60' in order to obtain a larger prefix delegation to assign a /64 to each of the local networks.

A sanitized version of the UCI service config is:

ddns.example_service=service
ddns.example_service.enabled='1'
ddns.example_service.use_https='1'
ddns.example_service.use_ipv6='1'
ddns.example_service.force_ipversion='1'
ddns.example_service.interface='wan6'
ddns.example_service.ip_network='wan6'
ddns.example_service.update_url='https://ddnsapi.example.com/set'
ddns.example_service.domain='mrjoel.example.com'
ddns.example_service.lookup_host='mrjoel.example.com'
ddns.example_service.username='username'
ddns.example_service.password='password'
ddns.example_service.use_syslog='2'
@mrjoel
Copy link
Contributor Author

mrjoel commented Aug 21, 2020

Investigating further, the local address seems to be correctly determined, the remote (DNS lookup) address is incorrect since the update request seems to be using a different source address and not the ip_network.

@mrjoel
Copy link
Contributor Author

mrjoel commented Aug 21, 2020

The "wget-ssl" command doesn't seem to be getting called with the "--bind-address" argument since $bind_network is empty. Investigating further to determine if it's just a configuration issue.

@mrjoel
Copy link
Contributor Author

mrjoel commented Aug 21, 2020

The bind_network variable is checked, but doesn't seem to actually be set anywhere. If I change my device version to have a bind_network=wan6 right before the [ -n "$bind_network" ] check (line 707 of current git, non-minimized source) then everything functions as expected.

It's not clear where/when/how that is/was expected to be populated, but I'll look further and see if I can come up with a patch.

@mrjoel
Copy link
Contributor Author

mrjoel commented Aug 21, 2020

Ok, in reviewing the UCI documentation for ddns I see that the bind_network is indeed a separate config variable.

I'll retitle the issue to request that if bind_network is not set but ip_network is, then the value of ip_network should be used for bind_network processing by default.

@mrjoel mrjoel changed the title ddns-scripts: incorrect IPv6 address for checking ddns-scripts: use ip_network as default for bind_network Aug 21, 2020
mrjoel added a commit to mrjoel/openwrt-packages that referenced this issue Oct 21, 2020
pprindeville pushed a commit to pprindeville/packages that referenced this issue Dec 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant