-
I want to add one more thing. In my DynDNS account, I don't see any log of pfSense updating the IP. I do see the last log an update was made, by the Windows client. So it doesn't seem to be just a feedback issue.
-
I don't recall exactly what dyn's logs will show you, but they're most certainly sending you "badauth" as the reply. They probably don't add to the update log upon auth failure.
Only thing I can think of, have you put your password in again, while making sure you don't have any form fillers/password managers enabled? Lastpass bit me there once recently, overwriting the password.
-
Yeah, I put the password in by hand numerous times. I even went to the xml file in pfSense that actually stores the login credentials and checked that, and it's correct. I am baffled, the Windows client works fine. Could be a cert issue? I remember reading something about DynDNS is using TLS?
Thanks,
Chris -
If there were a cert problem it would fail well before that, and wouldn't have the provider response code as it wouldn't send a request to obtain a reply.
If you enable verbose logging do you get anything more in the logs?
-
I always thought that "DynDNS (custom)" would be used if you had your own domain name using Dyn services… but if you were using their domain(s), you should be using "DynDNS (dynamic)" instead? Am I wrong about that? What's the difference between the three different DynDNS options?
-
I changed from custom to dynamic in the DynDNS settings. Now the instead of the cached IP being the previous IP, in red, it is now quad zero in red. I do have verbose logging on. The log entries are the same as before.
Chris
-
I changed from custom to dynamic in the DynDNS settings. Now the instead of the cached IP being the previous IP, in red, it is now quad zero in red.
That's what I'd expect after switching service types, that removes the cached IP so you end up with 0.0.0.0 until it updates successfully for the first time.
@virgiliomi:
I always thought that "DynDNS (custom)" would be used if you had your own domain name using Dyn services… but if you were using their domain(s), you should be using "DynDNS (dynamic)" instead? Am I wrong about that? What's the difference between the three different DynDNS options?
I was wondering the same thing. That dates way back, to when they were named DynDNS and not Dyn. If the diff service types had differing config options or update URLs or error response codes, that'd be why you might have 3 diff types. But looking at /etc/inc/dyndns.class, those 3 all do exactly the same thing. Haven't looked back in the history to see if things used to be different way back at some point. That probably should be consolidated to one, and renamed to Dyn, at some point.
I think we almost certainly would have heard from another Dyn user if it were completely non-functional. But they're not nearly as widely used since discontinuing free accounts, so maybe not.
My best suggestion at this point is to go back to the point where it worked (which in this case is easy, just replacing one file), and see if it still works. Replace /etc/inc/dyndns.class with:
https://raw.githubusercontent.com/pfsense/pfsense/e8f35ce462e8af23cb7d1af8ca59bee856a6e7bc/src/etc/inc/dyndns.class
and you'll be back to how it was from February 4-14, which I believe is where your last working snapshot fell. Then trigger a dyndns update, and see what happens. -
Hi,
I just installed pfSense to replace a small wifi router that was working fine with DynDNS.
Found this topic because I got the exact same error message (even changing the type did not help).I'll try the code change to see if that solves the issue.
Will let you know shortly.
-
So, I replaced the code in dyndns.class with :
https://raw.githubusercontent.com/pfsense/pfsense/e8f35ce462e8af23cb7d1af8ca59bee856a6e7bc/src/etc/inc/dyndns.classNow logs are different. Worse in a sense ;)
php-fpm[67544]: /services_dyndns_edit.php: DynDNS (my.hostname.fqdn) There was an error trying to determine the public IP for interface - (). Probably interface is not a WAN interface. php-fpm[67544]: /services_dyndns_edit.php: phpDynDNS: (ERROR!) No Password Provided.
So I guess the code has changed too much.
Meanwhile, here are the logs I get with the original code:
php-fpm[70638]: /services_dyndns_edit.php: phpDynDNS (my.hostname.fqdn): (Unknown Response) php-fpm[70638]: /services_dyndns_edit.php: phpDynDNS (my.hostname.fqdn): PAYLOAD: badauth php-fpm[70638]: /services_dyndns_edit.php: DynDNS (my.hostname.fqdn): Current Service: dyndns-custom php-fpm[70638]: /services_dyndns_edit.php: DynDNS (my.hostname.fqdn): DynDns _checkStatus() starting. php-fpm[70638]: /services_dyndns_edit.php: DynDNS: (my.hostname.fqdn) DNS update() starting. php-fpm[70638]: /services_dyndns_edit.php: DynDNS (my.hostname.fqdn): DynDns _update() starting. php-fpm[70638]: /services_dyndns_edit.php: DynDNS (my.hostname.fqdn): running get_failover_interface for wan. found rl0 php-fpm[70638]: /services_dyndns_edit.php: DynDns (my.hostname.fqdn): XXX.XXX.XXX.XXX extracted from local system. php-fpm[70638]: /services_dyndns_edit.php: DynDns: updatedns() starting
Credentials have been checked.
Any clue ?
P.S.: also tried ZoneEdit and it worked flawlessly.
-
Hi,
Good news.
I was fiddeling with the update URL for DynDNS trying to understand what was failing.
I used curl to do so (https://help.dyn.com/remote-access-api/perform-update/).
Also tried FireFox at some point.
Indeed, 'badauth' indicates authentication failure (https://help.dyn.com/remote-access-api/return-codes/).I tried to update a standard 'host.dyndns.org' entry but still failed to authenticate.
While searching I found an old post (https://wiki.openwrt.org/doc/howto/ddns.client) stating:
'badauth' in Update Output, you have to change your password which contains only letters and numbers. Because busybox's (v1.15.3) wget implementation has an issue handling encoded URLs
As it did not work at first (during my very first attempts in pfSense), I switched back to the regular password for my account (just in case), full of special characters.
After reading the above post, I reverted to using the 'Updater Client Key' you can get on the 'Account Settings' page.Now this worked for the dyndns.org domain. Also using it to update my FQDN worked.
I can't tell why I had failures using the 'Updater Client Key' in the first place, but well … now it works.
Hope this helps out.
-
So, I replaced the code in dyndns.class with :
https://raw.githubusercontent.com/pfsense/pfsense/e8f35ce462e8af23cb7d1af8ca59bee856a6e7bc/src/etc/inc/dyndns.classNow logs are different. Worse in a sense ;)
Guessing you must be on 2.2.x, since the called parameters are different there, in which case that file won't work.
Could you narrow down which character in particular is causing an issue?
-
@cmb:
Could you narrow down which character in particular is causing an issue?
I have also noticed it had stopped working with dyndns. I change the password (example) from "n1ssehult" to "N1ssehult!" and it works again. Dunno why, but it works!
-
I have also noticed it had stopped working with dyndns. I change the password (example) from "n1ssehult" to "N1ssehult!" and it works again. Dunno why, but it works!
In that case you actually added a special character? That sounds like the password change on Dyn's side made it start working rather than anything to do with the contents of the password.
-
@cmb:
In that case you actually added a special character? That sounds like the password change on Dyn's side made it start working rather than anything to do with the contents of the password.
I also have a Asus RT-N65U (padavan fw) using the same DYN-Pro account (different hostname though) for two years that has worked fine lately while pfsense didn't. I also have three other (total four) virtual pfSense installations using four different hostnames, all fails the same. Either the uppercase or the exclamation did it. Dunno.
I know the DYN password was correct as I was able to log in to their site using the "wrong" password, but the "correct" credentials in pfSense failed. I have deleted and recreated the DDNS client entry numerous times in pfSense and thought… alzheimer? Phew... anyhow, it works with "special/upper" characters added.