Dynamic DNS not updating after modem/router reboot

Hello,

I am using a Freedombox at home. I set up my modem/router so the Freedombox is in the DMZ. I then set up dynamic DNS for the Freedombox using ddns.freedombox.org. It has been working fine for my cell phone and computer to get calendar info from Radicale via the internet. However, each time my home modem has rebooted due to it losing power, it gets a new IP address from my internet service provider.

When I set up the Freedombox, I gave it my login info for the ddns account, which I thought would allow the Freedombox to update the DDNS with any IP address changes. However, it has not been able to do that. Instead, I have had to log into my ddns account and manually set the IP address to the new one any time the modem/router reboots.

Has anyone else had this problem? Or can you suggest ways that I can debug the problem?

I have also been wondering if there is a way to have a cron job check for IP address changes and, if there is, send an update to the ddns server, but I’m not sure how to send the updated info.

I am running Freedombox 25.9 on a Pioneer device. I installed the image on the SSD several months ago and it has updated automatically since then.

When it seems to get stuck, what do you see on the System/Dynamic DNS Client page for “Last update” and “Result”? The client should be checking for an update every 5 minutes. Every minute the “Last update” value should increment until it rolls back to 0 after 5 minutes (you may need to refresh the page to see this). I don’t remember what “Result” says when an update is detected, but it will usually say “Success (Already up-to-date)”.

Hello @lifeform,

When the DDNS is working properly, I am seeing Last Update = “1 minute” and Result = "Success (Already up to date). So it looks like it is checking and seeing that the DDNS has the right IP address under normal conditions.

I then turned off the power strip that powers the modem/router, a switch that provides more ethernet ports, and the freedombox for 5 minutes. I waited 10 minutes for everything to power back up and stabilized, and then checked the DDNS client page again. It showed Last Update = “0 minutes” and Result = “Failed”. It also showed IP Address = “-”, whereas when it succeeded prior to the power cycling it showed an IP address in the normal format.

I refreshed the page a few minutes later and got Last Update = “3 minutes” and Result = “Failed”. I refreshed the page again another few minutes after that and got Last Update = “1 minutes” and Result = “Failed”. So it appears that it is trying to update things every 5 minutes like you described, but it isn’t working for some reason.

Next, I logged into my account on ddns.freedombox.org and manually updated the IP address using its web interface. When I checked the Freedombox ddns client page a few minutes later, I got Last Update = “0 minute” and Result = "Success (Already up to date) and IP Address = a properly formatted IP address.

So it seems that the DDNS client can tell when ddns.freedombox.org has the right IP address, but it can’t update it if it is wrong.

Any thoughts?

Is your Pioneer’s backup battery connected? Or to be more specific, is the Pioneer restarting when you cut and restore power to the power strip, or just the modem/router and Ethernet switch?

In any case, check whether the log provides any clues to the DDNS failure. You may have to temporarily change the System/Configure setting for “System-wide logging” if it’s currently set to “Disable logging, for privacy”.

I would suggest bracketing the time period from just before cutting the power to when you first see “Result = ‘Failed’” on the DDNS client page. To view the log, you can use the Cockpit application or SSH into the Pioneer and use the journalctl command from the command line (you can also use journalctl within Cockpit from the “Terminal” window). If the Pioneer is restarting, the start time of interest equates to “Current Boot” in Cockpit. Here’s a sample journalctl command that picks out all log entries for an eleven minute interval.

sudo journalctl -S “2025-05-28 13:11:00” -U “2025-05-28 13:22:00”

Hello @lifeform,

My Pioneer does not have a battery in it. I really should get one for it. I have added it to my to-do list.

I switched the System/Configure setting to “Write to disk, useful for debugging”. Then I unplugged the power to the modem/router but left the Pioneer powered up and running. I left the modem off for 5 minutes and then plugged it back in. When I examined the logs, I found the following detailed entry about the DDNS update failing. It occurred while the modem was off.


/usr/bin/plinth
Failed to be update Dynamic DNS - [Errno -2] Name or service not known
Traceback (most recent call last):
File “/usr/lib/python3/dist-packages/plinth/modules/dynamicdns/init.py”, line 213, in _update_dns_for_domain
result, ip_address = gnudip.update(domain[‘server’],
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3/dist-packages/plinth/modules/dynamicdns/gnudip.py”, line 27, in update
socket.connect((server, GNUDIP_PORT))
socket.gaierror: [Errno -2] Name or service not known

CODE_ARGS
(gaierror(-2, ‘Name or service not known’),)
CODE_FILE
/usr/lib/python3/dist-packages/plinth/modules/dynamicdns/init.py
CODE_FUNC
_update_dns_for_domain
CODE_LINE
221
EXCEPTION_INFO
(<class ‘socket.gaierror’>, gaierror(-2, ‘Name or service not known’), <traceback object at 0xaf957f08>)
EXCEPTION_TEXT
Traceback (most recent call last): File “/usr/lib/python3/dist-packages/plinth/modules/dynamicdns/init.py”, line 213, in _update_dns_for_domain result, ip_address = gnudip.update(domain[‘server’], ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File “/usr/lib/python3/dist-packages/plinth/modules/dynamicdns/gnudip.py”, line 27, in update socket.connect((server, GNUDIP_PORT)) socket.gaierror: [Errno -2] Name or service not known
LOGGER
plinth.modules.dynamicdns
PRIORITY
3
PROCESS_NAME
MainProcess
SYSLOG_IDENTIFIER
/usr/bin/plinth
THREAD_NAME
Thread-597 (_runner)
_BOOT_ID
f06938564d504622a9ecabb4d3336f87
_CAP_EFFECTIVE
0
_CMDLINE
/usr/bin/python3 /usr/bin/plinth
_COMM
plinth
_EXE
/usr/bin/python3.11
_GID
117
_HOSTNAME
freedombox
_MACHINE_ID
b9561dfeba6541749ac14e817feabecc
_PID
513
_RUNTIME_SCOPE
system
_SELINUX_CONTEXT
unconfined
_SOURCE_REALTIME_TIMESTAMP
1748484487755558
_SYSTEMD_CGROUP
/system.slice/plinth.service
_SYSTEMD_INVOCATION_ID
573bdbefc8a745ef83b7fc28f278621e
_SYSTEMD_SLICE
system.slice
_SYSTEMD_UNIT
plinth.service
_TRANSPORT
journal
_UID
110
__CURSOR
s=ff3825b2cb2b4eb98a723ac4f7a8f9dd;i=1840;b=f06938564d504622a9ecabb4d3336f87;m=143fef113d;t=6363cc4c9b889;x=f1c6380876550524
__MONOTONIC_TIMESTAMP
86971978045
__REALTIME_TIMESTAMP
1748484487755913


I also noticed that the summary logs had a lot of entries saying “error: kex_exchange_identification: Connection closed by remote host”. I’m not sure what those are about. They may have nothing to do with this.

Does the log entry give you any clues?

@lifeform, I realized after my last post that there was a filter on the log entries that was screening some of the pertinent entries. The summary log below shows the entries that contain the domain we use for ddns. I turned off the modem arount 8:05pm, turned it back on around 8:12pm, and had internet back at about 8:14pm. I manually updated the DDNS by logging into my account at about 8:35pm.


8:38 PM Dynamic domain [redacted] is up-to-date: [redacted] /usr/bin/plinth 2

8:18 PM Updating dynamic domain [redacted], DNS address [redacted], looked up external address [redacted] /usr/bin/plinth 4

8:12 PM Updating dynamic domain [redacted], DNS address None, looked up external address None /usr/bin/plinth

8:12 PM Unable to lookup DNS for host [redacted]: Command ‘[‘host’, ‘-t’, ‘A’, ‘[redacted]’]’ returned non-zero exit status 1. /usr/bin/plinth

8:08 PM Updating dynamic domain [redacted], DNS address None, looked up external address None /usr/bin/plinth

8:07 PM Unable to lookup DNS for host [redacted]: Command ‘[‘host’, ‘-t’, ‘A’, ‘[redacted]’]’ returned non-zero exit status 1. /usr/bin/plinth


So the Pioneer could see that the DDNS needed to be updated starting at 8:18pm. It looks like it tried to update it four times between then and 8:33pm. For some reason, though, it isn’t able to update it. The detailed log entry for the update attempt is below.


/usr/bin/plinth
Updating dynamic domain [redacted], DNS address [redacted]4, looked up external address [redacted]

CODE_ARGS
(‘[redacted]’, ‘[redacted]’, ‘[redacted]’)
CODE_FILE
/usr/lib/python3/dist-packages/plinth/modules/dynamicdns/init.py
CODE_FUNC
_update_dns_for_domain
CODE_LINE
208
LOGGER
plinth.modules.dynamicdns
PRIORITY
6
PROCESS_NAME
MainProcess
SYSLOG_IDENTIFIER
/usr/bin/plinth
THREAD_NAME
Thread-609 (_runner)
_BOOT_ID
f06938564d504622a9ecabb4d3336f87
_CAP_EFFECTIVE
0
_CMDLINE
/usr/bin/python3 /usr/bin/plinth
_COMM
plinth
_EXE
/usr/bin/python3.11
_GID
117
_HOSTNAME
freedombox
_MACHINE_ID
b9561dfeba6541749ac14e817feabecc
_PID
513
_RUNTIME_SCOPE
system
_SELINUX_CONTEXT
unconfined
_SOURCE_REALTIME_TIMESTAMP
1748486021954779
_SYSTEMD_CGROUP
/system.slice/plinth.service
_SYSTEMD_INVOCATION_ID
573bdbefc8a745ef83b7fc28f278621e
_SYSTEMD_SLICE
system.slice
_SYSTEMD_UNIT
plinth.service
_TRANSPORT
journal
_UID
110
__CURSOR
s=ff3825b2cb2b4eb98a723ac4f7a8f9dd;i=1934;b=f06938564d504622a9ecabb4d3336f87;m=149b611748;t=6363d203bbe93;x=9997f48aa25d5bf1
__MONOTONIC_TIMESTAMP
88506177352
__REALTIME_TIMESTAMP
1748486021955219


You may want to edit your post to substitute placeholders for your actual domain name and IP addresses.

It looks like at 8:18 the new IP was detected and should have been updated at ddns.freedombox.org since there’s no error message in the log. I’m still puzzled because I would have expected to see at least one “Success (Already up-to-date)” log message between 8:18 and 8:35 or maybe another “Updating” message.

Just to nail down the update mechanism being used, on the System/Dynamic DNS Client page, what is the value for “Service Type”?

@sunil Can it be that your recent server side changes to DDNS broke something?

Hello @lifeform,

The service type is GnuDIP.

I’m not positive, but I believe the the “4” at the end of the 8:18pm log entry means that the entry was repeated four times. That would make sense if it tried to update the ddns again at 8:23pm, 8:28pm, and 8:33pm before I updated it manually around 8:35pm.