Bug: unknown response received, spdyn #158

Closed
opened 2025-11-20 04:21:03 -05:00 by saavagebueno · 7 comments
Owner

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

{
      "provider": "spdyn",
      "domain": "example.spdns.eu",
      "host": "@",
      "user": "my@example.com",
      "password": "MyPwd",
      "token": "my-unique-token",
      "ip_version": "ipv6",
      "provider_ip": false
    },
Failure (unknown response received: good < correct IP > ), XXmYYs ago

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)

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 ```json { "provider": "spdyn", "domain": "example.spdns.eu", "host": "@", "user": "my@example.com", "password": "MyPwd", "token": "my-unique-token", "ip_version": "ipv6", "provider_ip": false }, ``` ``` Failure (unknown response received: good < correct IP > ), XXmYYs ago ``` 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)
Author
Owner

@qdm12 commented on GitHub (Dec 4, 2021):

Thanks for taking the time to report the issue!

It should be fixed in fa15abb781

let me know if it happens again after pulling the latest image 😉

@qdm12 commented on GitHub (Dec 4, 2021): Thanks for taking the time to report the issue! It should be fixed in https://github.com/qdm12/ddns-updater/commit/fa15abb781c54253b3404966e60c237be8e9b811 let me know if it happens again after pulling the latest image 😉
Author
Owner

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

@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.
Author
Owner

@qdm12 commented on GitHub (Dec 6, 2021):

The update went through i guess.

You can check the commit logged at the beginning of the logs as well, but yeah it should be the latest image 😉

The error within the updater disappeared.

Nice!

Strangely the "abuse" message in the spdyn control center is still there together with the ipv4 update, god knows why.

Maybe stop the container for a few hours to see if it makes a difference?

@qdm12 commented on GitHub (Dec 6, 2021): > The update went through i guess. You can check the commit logged at the beginning of the logs as well, but yeah it should be the latest image :wink: > The error within the updater disappeared. Nice! > Strangely the "abuse" message in the spdyn control center is still there together with the ipv4 update, god knows why. Maybe stop the container for a few hours to see if it makes a difference?
Author
Owner

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

@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".
Author
Owner

@qdm12 commented on GitHub (Dec 15, 2021):

Fixed in 01334ad91f

Sorry for the delay!

@qdm12 commented on GitHub (Dec 15, 2021): Fixed in 01334ad91f20bea6b4b5bdd6043d3fd0b7cfe6fd Sorry for the delay!
Author
Owner

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

@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.
Author
Owner

@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.4 and good 1.2.3.4 so the program wasn't expecting those responses. It would just expect nochg or good. Now they're both changed to check the prefixes only. I guess for once it's on them their docs is not accurate 😸

as to why he thinks it needs an update if it is unchanged every 1-3hrs.

Yes feel free to create another issue if it's unrelated to the unknown response. Thanks!

@qdm12 commented on GitHub (Dec 15, 2021): Yes there were already incorporated in the code even before this issue got created :wink: https://github.com/qdm12/ddns-updater/blob/ae7f10448da8716edb47a3535896f35d003c9cd6/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.4` and `good 1.2.3.4` so the program wasn't expecting those responses. It would just expect `nochg` or `good`. Now they're both changed to check the prefixes only. I guess for once it's on them their docs is not accurate :smile_cat: > as to why he thinks it needs an update if it is unchanged every 1-3hrs. Yes feel free to create another issue if it's unrelated to the unknown response. Thanks!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ddns-updater#158