DDNS IP/updated columns do not update

Started by julsssark, January 27, 2023, 06:00:59 PM

Previous topic - Next topic
March 11, 2023, 06:49:33 AM #15 Last Edit: March 11, 2023, 07:00:34 AM by 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

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)

<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...

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

March 11, 2023, 01:57:30 PM #18 Last Edit: March 11, 2023, 02:21:44 PM by 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.


<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:

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


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

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

Hi Guys,

so, whats the verdict here?  ;D

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

cheers
Michael

April 22, 2023, 03:40:41 PM #23 Last Edit: April 22, 2023, 06:43:32 PM by 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:


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)

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.

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.
OPNsense 24.7 - Qotom Q355G4 - ISP - Squirrel 1Gbps.

Team Rebellion Member

April 27, 2023, 05:04:19 PM #26 Last Edit: April 27, 2023, 06:21:25 PM by 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.

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

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.

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.