DDNS IP/updated columns do not update

[Christophe999s]

Hi,
Thanks for looking in to this.
I'm not sure I understand what I should report to ddclient?
ddclient updates the cloudflare dns record and seems to work fine as far as I can see:
2023-03-11T06:51:27   Notice   ddclient[7241]   9078 - [meta sequenceId="1"] SUCCESS: updating my.domain.com: IPv4 address set to x.x.x.x

The issue I raised for duckdns has been merged, so this should be included in the next release: https://github.com/ddclient/ddclient/pull/506

[surly]

I did not realize at first, but the move from 22.7.11_1 to 23.1 (now at 23.1_2, will be 23.1.3 shortly) also broke ddclient updates to easyDNS for me.   (The beginning of logged errors matches my upgrade date)

Code: [Select]

<29>1 2023-03-11T07:17:11-05:00 OPNplenum ddclient[39675] 43033 - [meta sequenceId="10"] FAILED:   updating <REDACTED>: unexpected status (bb)

where the status code in brackets is different for every attempt to update.

I am a reasonably adept user, but not a programmer in the slightest, so I cannot "contribute code".  Don't have a github account either, so clearly not an adept user of that tool, but I'll see what I can do...

[franco]

As I said all we really need is an official bugfix release from ddclient called 3.10.1

[surly]

I may have found something helpful in my case.

For EasyDNS, anyways, the problem may be that ddclient as configured in OPNsense uses a min interval of 5 minutes and EasyDNS API complains back that it wants a minimum interval of 10 minutes.  I'm not sure what started the first string of errors in the very first place, but now it seems stuck in a loop where every 5 minutes it tries to update because the previous failed, and the failure may be due to the unknown status (unknown to ddclient anyways) that I should only send updates every 10 minutes or more. 

The logs show attempts and failures with "unknown status" every 5 minutes.  So it considers that a failure and tries again in 5 minutes, but the "failure" is due to a message that ddclient is trying too often.

Could a knob be added to the opnsense config screen to set the minimum interval / max frequency?  Is this the "-daemon <delay>" option?

EDIT: was overlooking the interval setting on the general tab.  Changed that to '700' in my case to continue testing.  Still believe that ddclient should understand the TOO FREQ error - leaving issue in place.

Code: [Select]

<29>1 2023-03-10T23:45:11-05:00 OPNplenum ddclient[16714] 31563 - [meta sequenceId="1"] FAILED:   updating <REDACTED1>: unexpected status (9d)
<29>1 2023-03-10T23:45:11-05:00 OPNplenum ddclient[16714] 32911 - [meta sequenceId="2"] FAILED:   updating <REDACTED2>: unexpected status (9e)
<29>1 2023-03-10T23:50:12-05:00 OPNplenum ddclient[16714] 82372 - [meta sequenceId="1"] FAILED:   updating <REDACTED1>: unexpected status (bb)
<29>1 2023-03-10T23:50:12-05:00 OPNplenum ddclient[16714] 83451 - [meta sequenceId="2"] FAILED:   updating <REDACTED2>: unexpected status (ba)
<29>1 2023-03-10T23:55:12-05:00 OPNplenum ddclient[16714] 18466 - [meta sequenceId="1"] FAILED:   updating <REDACTED1>: unexpected status (9d)
<29>1 2023-03-10T23:55:12-05:00 OPNplenumn ddclient[16714] 19477 - [meta sequenceId="2"] FAILED:   updating <REDACTED2>: unexpected status (9e)

logging from running 'ddclient -V -force' manually:

Code: [Select]

RECEIVE:  HTTP/1.1 200 OK
RECEIVE:  Date: Sat, 11 Mar 2023 12:53:52 GMT
RECEIVE:  Server: Apache
RECEIVE:  Expires: Thu, 19 Nov 1981 08:52:00 GMT
RECEIVE:  Cache-Control: no-store, no-cache, must-revalidate
RECEIVE:  Pragma: no-cache
RECEIVE:  Set-Cookie: easydns_language=en_US; expires=Sun, 10-Mar-2024 12:53:52 GMT; Max-Age=31536000; path=/
RECEIVE:  Set-Cookie: EasyDNS_SID=REDACTED; expires=Sat, 11-Mar-2023 14:53:52 GMT; Max-Age=7200; path=/; domain=api.cp.easydns.com; secure; HttpOnly
RECEIVE:  X-Frame-Options: sameorigin
RECEIVE:  Content-Security-Policy: frame-ancestors 'self';
RECEIVE:  Vary: Accept-Encoding
RECEIVE:  Connection: close
RECEIVE:  Transfer-Encoding: chunked
RECEIVE:  Content-Type: text/html; charset=UTF-8
RECEIVE: 
RECEIVE:  bb
RECEIVE:  <HTML><BODY><FONT FACE="sans-serif" SIZE="-1">TOO_FREQ<br />
RECEIVE:  <hr noshade size="1">
RECEIVE:  Increase your time between updates for <REDACTED> to 600 seconds or more.<br />
RECEIVE:  </FONT></BODY></HTML>
RECEIVE:  0


The setting of <delay> from within opnsense may be a useful option, and workaround for a few problems including this one.  I'm guessing that the real problem here is that ddclient needs to be made to understand a "TOO FREQ" response from my particular API?  Of course whatever originally set it into this loop is still unknown.


EDIT: Issue #525 opened

[julsssark]

There are a couple of bugs open in the ddclient GitHub for the spamming:

https://github.com/ddclient/ddclient/issues/481
https://github.com/ddclient/ddclient/issues/431

[Christophe999s]

It looks like ddclient is as good as dead... Unless someone takes over the project...
https://github.com/ddclient/ddclient/issues/528

[CJ]

That's unfortunate.  Looking for alternatives, it appears that inadyn is the only recently updated client I can find.

[His.Dudeness]

Hi Guys,

so, whats the verdict here? 

Should I switch back to legacy dynDNS client to be able to update my OPNsense box?

cheers
Michael

[zibloon]

Hello,

I have the same problems and I have 2 routers so I can compare:
 - everything works smoothly on OPNsense 22.7.11_1-amd64 with os-ddclient 1.9_2
 - I get errors on OPNsense 23.1.6-amd64 with os-ddclient 1.12

Both are running the same config (only the hostnames change). The errors on the last version are:

Code: [Select]

FAILED:   updating mynamexxx.dnsalias.net: unexpected status (13)
Use of uninitialized value $h in hash element at /usr/local/sbin/ddclient line 4122.
Use of uninitialized value $_[0] in sprintf at /usr/local/sbin/ddclient line 2179.
WARNING:  updating : nochg: No update required; unnecessary attempts to change to the current address are considered abusive
Use of uninitialized value $h in hash element at /usr/local/sbin/ddclient line 4131.
Use of uninitialized value $h in hash element at /usr/local/sbin/ddclient line 4132.
Use of uninitialized value $h in hash element at /usr/local/sbin/ddclient line 4133.
Use of uninitialized value $h in hash element at /usr/local/sbin/ddclient line 4122.
Use of uninitialized value $_[0] in sprintf at /usr/local/sbin/ddclient line 2179.
FAILED:   updating : unexpected status (0)
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
FAILED:    was not updated because protocol <undefined> is not supported.

The last version DOES UPDATE correctly on dyndns but it looks like it doesn't write the result correctly in /var/tmp/ddclient.cache so I imagine it's constantly updating... This is risky as dyndns could consider me as a spammer.

As a workaround, I disabled os-ddclient and I am using os-dyndns 1.27_3 [Dynamic DNS (legacy)]. I prefer dyndns anyway as I can also monitor a "WANGWGROUP" interface (multiwan), which is not possible with ddclient (see https://github.com/opnsense/plugins/issues/2899)

So if possible, please don't remove os-dyndns from future versions. I think it is especially important as the author of ddclient himself declared: "Lack of time and general interest in this project. I don't know the code anymore and can't really be a help in fixing this." (see https://github.com/ddclient/ddclient/issues/431#issuecomment-1424608301)

[gstyle]

I had the same problem.

With ddclient I changed in
"Services" - "Dynamic DNS" - "Settings" - "General Settings"
the "Backend" from "ddclient" to "OPNsense".

After this, the IP update is shown correctly.

[marjohn56]

I have switched back to the legacy client, it works without issues for me. I'll keep the package stored away so that if it does get binned I can still run it. I know if and when it gets binned there'll be no support... I can cope with that.

[julsssark]

23.1.6 appears to have fixed the spamming problem. I am using a CloudFlare API token with the ddclient backend and now I see the following message in my logs: "SUCCESS: XXX.XXX.com: skipped: IPv4 address was already set to ." I can live with the missing IP address in the columns/logs. My IP address rarely changes, so I can't test the case where the IP address has changed.

Edit: I needed to turn verbose logging on to see the skip messages.

[Prinxe1]

That did ddclient has always been an issue for me since 22.7. 

[julsssark]

The 23.1.9 release with the 1.13_2 os-ddclient fixed the DDNS display problem. The columns in the DDNS listing are now updating correctly using Cloudflare API token and the OPNsense backend.

[dcol]

Should have stuck with the old version seeing the lack of support for the new one. Still not fixed in 23.7. Now the old version has been removed.