Created attachment 758 [details] DDNS Updater log extract, DuckDNS 1. DDNS Updater checks for IP change by comparing local WAN IP to result returned by DNS query on Hostname. 2. For duckdns.org, DDNS Updater Hostname must be set to subdomain only, not to FQDN. Update fails if set to FQDN. 3. For duckdns.org, DDNS Updater thus does a DNS query on <subdomain>, which always fails, which is then followed by a successful DNS update. 4. Five minutes later, Step 3 repeats.
Hello bitbanger, thanks for submitting the bug. duckdns.org entirely changed their update API, so I had to rework the entire code handling this provider to support them again. I've uploaded a patch which contains all required changes. https://patchwork.ipfire.org/patch/3250/ Unfortunately I do not own an account so I'm not able to test with valid credentials if an successfull update can be performed. So I have to ask you to apply the patch and help us testing to get this provider working again for everyone. A big thanks in advance -Stefan
Created attachment 772 [details] Unsuccessful test results for proposed patch Performed two tests both resulting in DDNSConfigurationError. Test 1: hostname abc username dcare password <duckdns token> This is the old style definition for duckdns.org. See: https://wiki.ipfire.org/configuration/services/dyndns_providers Test 2: hostname abc username token password <duckdns token> This is my understanding of configuration for token instead of user/password. Either my understanding is incorrect or there is a bug somewhere. Note: In your rewrite you have switched from the previous user/password configuration for duckdns.org to token configuration. Are you sure you want to do this? It invalidates all previous configs for duckdns.org.
In addition to the issue of the variable 'token' not being set (which may be due to a misunderstanding on my part) I think I have found another error. In looking at your code for duckdns.org I see the following: data = { "domains" : self.hostname, "token" : self.token, "ipv6" : self.get_address("ipv6", "-"), "ip" : self.get_address("ipv4", "-"), "clear" : "true", } The issue is with the variable 'hostname'. To RESOLVE (via DNS) the address, hostname must be a FQDN. To UPDATE duckdns.org dynamic DNS, hostname must be a SUBDOMAIN ONLY. Duckdns.org is unlike almost every other DDNS provider in this respect. I did describe this in this bug report's opening comment. Therefore 'domains' must be set to the SUBDOMAIN ONLY, i.e., '.duckdns.org' must be stripped. Once this change is made the user should configure hostname as <subdomain>.duckdns.org.
Created attachment 778 [details] Patches to fix Bug 12415. See Readme.txt in .zip file. Patches to fix Bug 12415. See Readme.txt in .zip file.
Please submit any patches to the mailing lists for review: > https://wiki.ipfire.org/devel/submit-patches
(In reply to Michael Tremer from comment #5) > Please submit any patches to the mailing lists for review: > > > https://wiki.ipfire.org/devel/submit-patches I reviewed the referenced wiki page. I regret to inform you that I cannot reasonably meet the requirements outlined there. As I use webmail exclusively I have no way to submit a patch as inline text without its being corrupted. Further, I will not join any mailing list that publishes my email address on web pages accessible to the public (e.g., web message archive). You are welcome to use the unified context diffs (not Git diffs) that I have already submitted. In case you have not looked at the Readme.txt that I have already submitted, I should point out that Stefan Schantl's proposed patch has three errors of commission and one error of omission.
(In reply to bitbanger from comment #6) > (In reply to Michael Tremer from comment #5) > > Please submit any patches to the mailing lists for review: > > > > > https://wiki.ipfire.org/devel/submit-patches > > I reviewed the referenced wiki page. I regret to inform you that I cannot > reasonably meet the requirements outlined there. As I use webmail > exclusively I have no way to submit a patch as inline text without its being > corrupted. Further, I will not join any mailing list that publishes my email > address on web pages accessible to the public (e.g., web message archive). I am sad to hear that. However, we cannot accept patches in various other formats. This has many disadvantages for the project. First of all, we are an Open Source project. We do things in the open. It is important for us to do that to involve as many people in the development process and to make IPFire better with the help of as many people as possible. Taking part in a conversation is not too much to ask, since it is the standard way to communicate in this day and age. > You are welcome to use the unified context diffs (not Git diffs) that I have > already submitted. I have no interest to extract these from a zip archive and I am not even sure what files you tried to patch there with what and why. We use Git. It is a tool that has proven to be the best way to do software development and I do not have the time to manually patch my sources. > In case you have not looked at the Readme.txt that I have already submitted, > I should point out that Stefan Schantl's proposed patch has three errors of > commission and one error of omission. It is great and important work that you have done here. Please reconsider your decision and help us to make IPFire better.
> I've uploaded a patch which contains all required changes. > > https://patchwork.ipfire.org/patch/3250/ This patch did not seem to have made it into any repository. Resetting this back to ASSIGNED.
Hello *, I've digged through the attached patches and finally changed DDNS and the IPFire ddns.cgi to work well with the DuckDNS provider. The changes have been sent to the upstream DDNS git repository and to the development mailing list and can be found here: https://git.ipfire.org/?p=ddns.git;a=commit;h=ebdb37245e2033b065cce5a19597be4ef1c8875c https://patchwork.ipfire.org/patch/3691/ https://patchwork.ipfire.org/patch/3692/
I have merged these into next. Should we consider to tag another release of DDNS soon or are there any further patches coming?
I'm sad to report that I still see problem #2 with DuckDNS on my IPFire system with the latest stable release as of today. From syslog: ddns[14594]: An update has not been performed because earlier updates failed for myname-is-here.duckdns.org ddns[14594]: Last failure message: ddns[14594]: DDNSConfigurationError: The configuration file has errors ddns[14594]: Further updates will be withheld until 2021-06-14 12:35:00.754217 When I set the sub-domain only, rather than the FQDN as the documentation states, it works without error. I should note that I have no issues manually sending a GET via curl I'm happy to help test any fixes. Community thread: https://community.ipfire.org/t/dynamic-dns-fails-for-duckdns-org/5591
Is this bug with DuckDNS still valid with Core Update 182?
I was able to get this to work but I'm sorry I do not recall what the resolution was. I've since stopped using DDNS though. The configuration is still present in my IPFire system if that is of any help.