DDNS doesn't work

So after some time with Opwnwrt I'm almost happy with it. It runs stable and I do "understand" how to use it.
However there is one topic which I could not resolve up to now. I like to use DDNS to get access to my NAS from the internet. I used IP64.net as DDNS. This is the content of my DDNS config:

config ddns 'global'
        option ddns_dateformat '%F %R'
        option ddns_loglines '250'
        option ddns_rundir '/var/run/ddns'
        option ddns_logdir '/var/log/ddns'
        option use_curl '1'

config service 'ip64'
        option service_name 'ipv64.net'
        option use_ipv6 '0'
        option enabled '1'
        option lookup_host 'xxx.lan64.de'
        option domain 'xxx.lan64.de'
        option username 'xxx@xxx.com'
        option password 'xxxxxxxxxxxxxxxxxx'
        option ip_source 'network'
        option ip_network 'wan'
        option interface 'wan'
        option use_syslog '2'
        option check_interval '1'
        option check_unit 'hours'
        option force_interval '24'
        option force_unit 'hours'
        option retry_unit 'seconds'
        option use_https '1'

So the problem I have is, that the IP adress is not listed in Luci-DDNS and the status always shows "Not running". If I try to "reload" it shows the following message "xhr request timed out".

I crosschecked with IP64 and it returns IPV6 and IPV4 adress which is the same of whatsmyip. I also contacted my internet provider and asked if dualstack is runing (confirmed).

So I need some advise or help what I'm doing wrong or what I haven't done correctly.

Thanks for your help :slight_smile:

You need to use the custom option as shown on their web site.
Note that you don't need to use https in the "Update URL", use just "http://..."
Don't forget to install curl and hostip (or drill or another similar tool) and configure certificate path as /etc/ssl/certs/ca-certificates.crt

Edit: it looks like that with 24.10 we now have a predefined "provider" for ipv64.net, however it is broken - the name within the file is "duckdns.org", so custom configuration will not be needed once that is fixed. There is no such problem with the master branch.

Thanks for the quick answer. I followed the instruction. So my DDNS config looks like this:

config ddns 'global'
        option ddns_dateformat '%F %R'
        option ddns_loglines '250'
        option ddns_rundir '/var/run/ddns'
        option ddns_logdir '/var/log/ddns'
        option use_curl '1'

config service 'ip64'
        option use_ipv6 '0'
        option enabled '1'
        option lookup_host 'xxx.lan64.de'
        option update_url 'http://ipv64.net/nic/update?domain=[DOMAIN]&key=[PAS
        option domain 'xxx.lan64.de'
        option username 'none'
        option password 'my Update-Token'
        option use_https '1'
        option cacert '/etc/ssl/certs/ca-certificates.crt'
        option ip_source 'network'
        option ip_network 'wan'
        option interface 'wan'
        option use_syslog '2'
        option check_unit 'minutes'

Still the same problem. Could it be, that the firewall or the port forwarding needs to be adapted?

Please show the DDNS client log.

I'm not sure where to find this. I looked it up under var/log but this is empty

in /var/log/ddns

But you can view it if you click Edit on the DDNS and then on the last tab:

I think I managed it now (sorry).

 175219       : ************ ************** ************** **************
 175219  note : PID '7015' started at 2025-02-28 17:52
 175219       : ddns version  : 2.8.2-43
 175219       : uci configuration:
ddns.ip64.cacert='/etc/ssl/certs/ca-certificates.crt'
ddns.ip64.check_unit='minutes'
ddns.ip64.domain='lallkopf.lan64.de'
ddns.ip64.enabled='1'
ddns.ip64.force_unit='minutes'
ddns.ip64.interface='wan'
ddns.ip64.ip_network='wan'
ddns.ip64.ip_source='network'
ddns.ip64.lookup_host='lallkopf.lan64.de'
ddns.ip64.password='***PW***'
ddns.ip64.retry_unit='seconds'
ddns.ip64.update_url='http://ipv64.net/nic/update?domain=[DOMAIN]&key=[PASSWORD]
ddns.ip64.use_https='1'
ddns.ip64.use_ipv6='0'
ddns.ip64.use_syslog='2'
ddns.ip64.username='none'
ddns.ip64=service
 175219       : verbose mode  : 0 - run normal, NO console output
 175219       : check interval: 600 seconds
 175219       : force interval: 4320 seconds
 175219       : retry interval: 60 seconds
 175219       : retry max count : 0 times
 175219       : No old process
 175219       : last update: never
 175219       : Detect registered/public IP
 175219       : #> /usr/bin/khost -t A lallkopf.lan64.de  >/var/run/ddns/ip64.da
 175219  WARN : NO valid IP found
 175219  info : Starting main loop at 2025-02-28 17:52
 175219       : Detect current IP on 'network'
 175219 ERROR : Can not detect current IP using network_get_ipaddr 'wan' - Error
 175219  WARN : PID '7015' exit WITH ERROR '1' at 2025-02-28 17:52

I made a change to the internet adapter. Since the network adapter "wan" is not the one for the internet. I corrected it to the right adapter "Internet". The protocol looks now like this:

 183432       : ************ ************** ************** **************
 183432  note : PID '15853' started at 2025-02-28 18:34
 183432       : ddns version  : 2.8.2-43
 183432       : uci configuration:
ddns.ip64.cacert='/etc/ssl/certs/ca-certificates.crt'
ddns.ip64.check_unit='minutes'
ddns.ip64.domain='lallkopf.lan64.de'
ddns.ip64.enabled='1'
ddns.ip64.force_unit='minutes'
ddns.ip64.interface='Internet'
ddns.ip64.ip_network='Internet'
ddns.ip64.ip_source='network'
ddns.ip64.lookup_host='lallkopf.lan64.de'
ddns.ip64.password='***PW***'
ddns.ip64.retry_unit='seconds'
ddns.ip64.update_url='https://ipv64.net/nic/update?domain=[DOMAIN]&key=[PASSWORD]&ip=[IP]'
ddns.ip64.use_https='1'
ddns.ip64.use_ipv6='0'
ddns.ip64.use_syslog='2'
ddns.ip64.username='none'
ddns.ip64=service
 183432       : verbose mode  : 0 - run normal, NO console output
 183432       : check interval: 600 seconds
 183432       : force interval: 4320 seconds
 183432       : retry interval: 60 seconds
 183432       : retry max count : 0 times
 183432       : 'SIGTERM' was send to old process
 183432  note : PID '15339' terminated by 'SIGTERM' at 2025-02-28 18:34
 183432       : last update: 2025-02-28 18:31
 183432       : Detect registered/public IP
 183432       : #> /usr/bin/khost -t A lallkopf.lan64.de  >/var/run/ddns/ip64.dat 2>/var/run/ddns/ip64.err
 183432  WARN : NO valid IP found
 183432  info : Starting main loop at 2025-02-28 18:34
 183432       : Detect current IP on 'network'
 183432       : Current IP '87.123.50.50' detected on network 'Internet'
 183432       : Update needed - L: '87.123.50.50' <> R: ''
 183432       : Force communication via device 'pppoe-Internet'
 183432       : #> /usr/bin/curl -RsS -o /var/run/ddns/ip64.dat --stderr /var/run/ddns/ip64.err --interface pppoe-Internet --cacert /etc/ssl/certs/ca-certificates.crt --noproxy '*' 'https://ipv64.net/nic/update?domain=lallkopf.lan64.de&key=***PW***&ip=87.123.50.50'
 183433       : DDNS Provider answered:
{"status":"success"}
 183433  info : Update successful - IP '87.123.50.50' send
 183433  info : Forced update successful - IP: '87.123.50.50' send
 183433       : Waiting 600 seconds (Check Interval)

And yet the DDNS does not show any ip adress although it recognized the right IP adresss (87.123.50.50). There is still the XHR error. The status is now always running. It shows the number (15853).

I'm not sure why this happens. I have my domain successfully updated with pretty much the same settings.
At the same time I see a non-JSON response in my log:

175832       : DDNS Provider answered:
good

when you have

So here some update. It works. But I also checked over whatsmyip the correspondent Infos. It seems that the internet provider did not provided Dualstack before. The change could be seen that before IPv6 was native and IPv4 not (fall back). Funny enough that it is now the other way round. And surprisingly it is working like a charme.
Iḿ sorry that I bothered you before with this topic. I can assure you that I learnt with your input. Thanks for all your efforts.

The only web site you need to check is your router web interface, Interfaces section. It clearly shows what you [don't] have. There is no need to visit wimi.com etc.

1 Like

I have also activated dyndns in openwrt.
My router is currently still connected behind a Fritzbox that runs as an exposed host. I have configured my settings and am not sure whether the URL in the advanced settings is correct. I entered http://checkip.dyndns.com there to get the current IP address. I set the timer to 30 minutes. However, the query does not start when the router boots up. When I press Start DDNS, nothing happens. Only when I press Restart DDNS does anything happen.

164925 : ************ ************** ************** **************
164925 note : PID '23713' started at 2025-12-09 16:49
164925 : ddns version : 2.8.2-64
164925 : uci configuration:
ddns.IPv64.cacert='/etc/ssl/certs/ca-certificates.crt'
ddns.IPv64.check_interval='30'
ddns.IPv64.check_unit='minutes'
ddns.IPv64.domain='xxxx.lan64.de'
ddns.IPv64.enabled='1'
ddns.IPv64.interface='wan'
ddns.IPv64.ip_source='web'
ddns.IPv64.ip_url='http://checkip.dyndns.com'
ddns.IPv64.lookup_host='xxxx.lan64.de'
ddns.IPv64.password='PW'
ddns.IPv64.update_url='http://ipv64.net/nic/update?domain=[DOMAIN]&key=[PASSWORD]&ip=[IP]'
ddns.IPv64.use_https='1'
ddns.IPv64.use_ipv6='0'
ddns.IPv64.use_syslog='2'
ddns.IPv64.username='none'
ddns.IPv64=service
164925 : verbose mode : 0 - run normal, NO console output
164925 : check interval: 1800 seconds
164925 : force interval: 259200 seconds
164925 : retry interval: 60 seconds
164925 : retry max count : 0 times
164925 : No old process
164925 : last update: 2025-12-09 16:19
164925 : Detect registered/public IP
164925 : #> /usr/bin/hostip xxxx.lan64.de >/var/run/ddns/IPv64.dat 2>/var/run/ddns/IPv64.err
164926 : Registered IP '46.x.x.x' detected
164926 info : Starting main loop at 2025-12-09 16:49
164926 : Detect current IP on 'web'
164926 : #> /usr/bin/curl -RsS -o /var/run/ddns/IPv64.dat --stderr /var/run/ddns/IPv64.err --cacert /etc/ssl/certs/ca-certificates.crt --noproxy '*' 'http://checkip.dyndns.com'
164926 : Current IP '46.x.x.x' detected on web at 'http://checkip.dyndns.com'
164926 : Waiting 1800 seconds (Check Interval)

What does ist mean:

Run once service ddns enable
Then execute service ddns enabled ; echo $? and you should get 0 as a result.

config ddns 'global'
        option ddns_dateformat '%F %R'
        option ddns_loglines '250'
        option ddns_rundir '/var/run/ddns'
        option ddns_logdir '/var/log/ddns'
        option upd_privateip '1'
        option use_curl '1'

config service 'IPv64'
        option use_ipv6 '0'
        option enabled '0'
        option lookup_host 'xxxx.lan64.de'
        option update_url 'http://ipv64.net/nic/update?domain=[DOMAIN]&key=[PASSWORD]&ip=[IP]'
        option domain 'xxxx.lan64.de'
        option username 'none'
        option password 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
        option use_https '1'
        option cacert '/etc/ssl/certs/ca-certificates.crt'
        option ip_source 'web'
        option interface 'wan'
        option use_syslog '2'
        option check_interval '30'
        option check_unit 'minutes'
        option ip_url 'http://checkip.dyndns.com'

What I noticed: The page shows the next update in three days, even though I only have a 30-minute interval. The second field, Forced Interval, shows 72 even though I deleted the field. Do I still have incorrect information?

Please replace pictures with formatted copy/paste of your /etc/config/ddns

1 Like

When you don't have force_interval defined it defaults to 72 (hours).
See https://openwrt.org/docs/guide-user/base-system/ddns#section_service

1 Like

Thanks for the info. What do you think is the best setting for force_interval? I check every 30 minutes to see if the IP has changed. So I don't normally need force_interval, right?

I suppose I normally set it to force update every 24h as a precaution.

1 Like

What is the difference between “Interval for checking for changed IP” and “Interval for forced update with DDNS provider”? Do we perform an update in both cases when the IP changes, or only in the case of Force_interval? If it works in both cases, then the time for force_interval can be longer.

We check periodically and send updates as needed.

We're sending out an update simply because it's time.

1 Like