Since three days for now (last update of DDNS entry is Friday, 4th) ddclient (dns/ddclient, most recent version 3.8.2) rejects updating of the privided IP to the dynamic DNS service with the following error message: [...] WARNING: file /var/tmp/ddclient.cache, line 3: Invalid Value for keyword 'ip' = '' WARNING: skipping update of all from <nothing> to xxx.xxx.xxx.xxx. WARNING: last updated <never> but last attempt on Tue Jul 8 20:14:11 2014 failed. WARNING: Wait at least 5 minutes between update attempts. regards, ddclient@gate.walstatt.dynvpn.de (version 3.8.2) The operating system is FreeBSD CURRENT: FreeBSD 11.0-CURRENT #1 r268416: Tue Jul 8 18:29:05 CEST 2014 amd64 Since Friday, 4th, nothing changed in my setup or environment except the operating system (on that box the OS is updated on a daily basis).
Which dynamic dns service are you using? I have the same behaviour with dyndns as you describe. As a work around you can disable SSL (ssl=no in etc/ddclient.conf). I wonder if there is a new incompatability between p5-IO-Socket-SSL (which was recently updated in the ports tree), or if dyndns.org has changed behaviour. With ddclient -debug -verbose -foreground -file /usr/local/etc/ddclient.conf I see: RECEIVE: HTTP/1.1 400 Bad Request RECEIVE: Date: Wed, 09 Jul 2014 16:51:21 GMT RECEIVE: Server: Apache RECEIVE: Content-Length: 362 RECEIVE: Connection: close RECEIVE: Content-Type: text/html; charset=iso-8859-1 RECEIVE: RECEIVE: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> RECEIVE: <html><head> RECEIVE: <title>400 Bad Request</title> RECEIVE: </head><body> RECEIVE: <h1>Bad Request</h1> RECEIVE: <p>Your browser sent a request that this server could not understand.<br /> RECEIVE: Reason: You're speaking plain HTTP to an SSL-enabled server port.<br /> RECEIVE: Instead use the HTTPS scheme to access this URL, please.<br /> RECEIVE: </p> RECEIVE: </body></html>
My dynamic dns service is TwoDNS in Berlin. As you already indicated: I had to disable ssl=yes. With ssl=yes enabled, I see a similar error as you showed, Error 400, Bad Reuest. Since I have used ssl=yes for several months now and it worked (indicated by the fact I was able to connect from my department to my private server via the domain I use) I didn't care. The problem occured around 4th July - that was, approximately, the last time the IP of my domain has been updated (I can check that on my provider's webpage). So, without ssl=yes, all the traffic, including my passowrd, is sent in the clear and this is an unacceptable situation. As I wrote above: with ssl=no or commenting ssl=yes out, the update is performed as expected.
Thanks. Agreed that ssl=no is unacceptable, but I wanted to know if it was a problem related to IO-Socket-SSL or the dynamic DNS provider. It seems to be an interaction with IO-Socket-SSL, because we have the same behaviour with two different providers.
enabling ssl=yes gives me [...] DEBUG: get_ip: using if, tun0 reports xxx.xxx.xxx.xxx DEBUG: DEBUG: nic_dyndns2_update ------------------- INFO: setting IP address to xxx.xxx.xxx.xxx for all UPDATE: updating all DEBUG: proxy = DEBUG: url = http://update.twodns.de/nic/update?system=dyndns&hostname=all&myip=xxx.xxx.xxx.xxx&wildcard=ON DEBUG: server = update.twodns.de CONNECT: update.twodns.de CONNECTED: using SSL SENDING: GET /nic/update?system=dyndns&hostname=all&myip=xxx.xxx.xxx.xxx&wildcard=ON HTTP/1.0 SENDING: Host: update.twodns.de SENDING: Authorization: Basic foobarsomethingkomischesinderzeile SENDING: User-Agent: ddclient/3.8.2 SENDING: Connection: close SENDING: RECEIVE: HTTP/1.1 400 Bad Request RECEIVE: Server: nginx/1.1.19 RECEIVE: Date: Fri, 11 Jul 2014 06:20:08 GMT RECEIVE: Content-Type: text/html RECEIVE: Content-Length: 271 RECEIVE: Connection: close RECEIVE: RECEIVE: <html> RECEIVE: <head><title>400 The plain HTTP request was sent to HTTPS port</title></head> RECEIVE: <body bgcolor="white"> RECEIVE: <center><h1>400 Bad Request</h1></center> RECEIVE: <center>The plain HTTP request was sent to HTTPS port</center> RECEIVE: <hr><center>nginx/1.1.19</center> RECEIVE: </body> RECEIVE: </html> [...] and the update dies. Without SSL it works. Using the specified URL with https:// instead http:// as shown above works fine manually. The dynamical DNS provider reported no problems on their side, so I guess the problem might be related to the update of some PERL modules. I try to check this by reverting the updated perl module as mentioned by mjl@luckie.org.nz.
This PR can be closed now. With the update of p5-IO-Socket-SSL to 1.997 use_ssl=yes works again.
Followup indicates that this is now fixed.