mirror of
https://github.com/qdm12/ddns-updater.git
synced 2026-07-22 05:42:11 -04:00
Bug: unknown response received, spdyn #158
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Saxfusion on GitHub (Dec 4, 2021).
Originally assigned to: @qdm12 on GitHub.
Running docker compose in host mode with a fixed external dns assignment.
IP updates go through but giving a failure measage anyhow. For the IPv4 as well as the IPv6 record.
For each record i have a corresponding config entry
in the web UI as well as Container Log
So IP update was ok, just the response code was not handled properly i guess.
Strangely when i log into spdyn.de and look at the host log there i see:
04.12.2021 13:58:43 OK, my-IPv6 (example.spdns.eu)
04.12.2021 13:58:41 OK, my-IPv4 (example.spdns.eu)
04.12.2021 13:58:41 'abuse' Response gesendet (my@example.com)
@qdm12 commented on GitHub (Dec 4, 2021):
Thanks for taking the time to report the issue!
It should be fixed in
fa15abb781let me know if it happens again after pulling the latest image 😉
@Saxfusion commented on GitHub (Dec 4, 2021):
The update went through i guess.
REPOSITORY TAG IMAGE ID CREATED SIZE
qmcgaw/ddns-updater latest 55a20324908d 2 hours ago 19.7MB
The error within the updater disappeared. Strangely the "abuse" message in the spdyn control center is still there together with the ipv4 update, god knows why.
@qdm12 commented on GitHub (Dec 6, 2021):
You can check the commit logged at the beginning of the logs as well, but yeah it should be the latest image 😉
Nice!
Maybe stop the container for a few hours to see if it makes a difference?
@Saxfusion commented on GitHub (Dec 6, 2021):
Got another one
ERROR unknown response received: nochg < ipv4 or ipv6 >
"nochg" probably means "noch gut" or "still ok, unchanged" since it is the IP on file at the dynDNS service control panel.
--
manually forcing another IP in the web-IF and letting ddns-updater update it again got it back to "success".
@qdm12 commented on GitHub (Dec 15, 2021):
Fixed in
01334ad91fSorry for the delay!
@Saxfusion commented on GitHub (Dec 15, 2021):
No worries, it's your leisure time...
Would IT Help If in Look Up all published Response Codes that i can find?
I mean they are listed here
https://wiki.securepoint.de/SPDyn/R%C3%BCckgabecodes
Just If you need Input regarding translation.
Still having this on the Site with the Adguard DNS Setup.
Need to check the log, when I find the time, as to why he thinks it needs an update if it is unchanged every 1-3hrs.
@qdm12 commented on GitHub (Dec 15, 2021):
Yes there were already incorporated in the code even before this issue got created 😉
ae7f10448d/internal/settings/providers/spdyn/provider.go (L152-L164)However they don't precise in their docs they return the IP address next to
nochg 1.2.3.4andgood 1.2.3.4so the program wasn't expecting those responses. It would just expectnochgorgood. Now they're both changed to check the prefixes only. I guess for once it's on them their docs is not accurate 😸Yes feel free to create another issue if it's unrelated to the unknown response. Thanks!