Cannot connect to


First, thanks for the great dyndns service. I am using it happily for years now.

Since a few days I have an issue with my raspberry though and it seems the dyndns does not get updated.

I use this ddclient configuration:

use=if, if=eth0
use=cmd, cmd='curl'

This is the error message for ddclient -force

root@raspberrypi:/home/pi# sudo ddclient -force
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    12  100    12    0     0     57      0 --:--:-- --:--:-- --:--:--    57
WARNING:  cannot connect to socket:  IO::Socket::IP configuration failed
FAILED:   updating Could not connect to

Any hint how to progress here would be appreciated

Hi MarcusE1W,

Thank you for your question, and welcome to the deSEC forum :slight_smile:

A few weeks ago, we disabled support for old versions of TLS. As of now, TLS 1.2 or a newer version is required.

Is it possible that your version of ddclient or openssl does not support TLS 1.2?

Stay secure,

Dear MarcusE1W,

my guess is that your curl does not support TLS 1.2. Since March 2020, TLS 1.2 or TLS 1.3 are required to connect to, as lower TLS versions are considered weak.

cURL supports TLS 1.2 since version 7.34.0 (released six years ago). Please see if you can confirm that your curl is pre-7.34. If so, a curl update will very likely fix your problem.


Hi @nils Hi @peter

Thanks for the quick reply. This could be it.

I have these versions installed with raspian:

  • curl: Version: 7.38.0-4+deb8u16
  • openssl: OpenSSL 1.0.1t 3 May 2016
  • ddclient: 3.8.2

Could one of these be the culprit ?

I have updated ddclient to 3.9.1, still the same, that leaves openssl

According to the change log (ctrl-f “Initial TLS v1.2 client support.”), OpenSSL introduced TLS1.2 support with 1.0.1. I can see two scenarios:

  • ddclient does not use openssl, but some other library.
  • OpenSSL 1.0.1t does not support any of the cipher suites we are offering.

Would you be able to capture the communication with our server using tcpdump? One way to capture the packets would be (make sure you are using IPv4):

  • Run tcpdump -s 0 -w -i any - net > dump.pcap
  • In another terminal, force ddclient update

I tried that, however the tmcdump command just terminated with ‘syntax error’…

I have noticed something else, if I use ddclient --force --debug I get this:

root@raspberrypi:/home/pi# ddclient --force --debug
WARNING:  file /var/cache/ddclient/ddclient.cache, line 3: Invalid Value for keyword 'ip' = ''
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    12  100    12    0     0     55      0 --:--:-- --:--:-- --:--:--    56
DEBUG:    get_ip: using cmd, curl reports
DEBUG:     nic_dyndns2_update -------------------
DEBUG:    proxy  = 
DEBUG:    url    =
DEBUG:    server =
WARNING:  cannot connect to socket:  IO::Socket::IP configuration failed
FAILED:   updating Could not connect to

The interesting bit is the url, it is http and not https. Could that be the problem ?

btw, I just used the raspberry ddclient.conf on my linux laptop and the update works. So it’s definitely not your service. It’s somewhere in my raspberry installation, presumably because something is out of date…

Hi MarcusE1W,

Your debug output contains your IP which allowed me to look at our logs. We see the following:

72#72: *40030 SSL_do_handshake() failed (SSL: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher) while SSL handshaking

So it looks like the set of ciphers we offer and the set of ciphers your client supports does not overlap. That means that something is indeed out of date (e.g. openssl).

Good luck,

1 Like

So in the end I have updated raspian to stretch (9.11) , it was previously still jessie (8.0).
This sorts it.
Thanks for all the help :smiley:

1 Like


I had the same problem: Suddenly the IP update didn’t work for me anymore. I used the dyn-dns function of my router (TP-link vr200). Sadly it was/is not clear why the update did not work anymore and there is no update for my router.

I think many people used the function of their (old) router. Would it be possible to offer an alternative endpoint like

Anyway, a little info in the documentation would be good, that if the update doesn’t work, the tls version should be checked, right?

Hi ocean,

Thanks for the suggestion. We put high value on security, and we are not going to keep old libraries in our software stack in order to support insecure cryptographic methods. We consider them to be only marginally better than unencrypted communication (which we do not endorse either).

So, unfortunately, we can’t help you out with an alternative endpoint.

I’m sorry to hear that it was hard to figure out the reason why your update did not work anymore; however, the router does have knowledge about what went wrong in the connection, and it’s a pity that it didn’t tell you this information in more detail.

We also sent out messages to users who recently updated their IP using an old TLS version to warn them of the change, a few weeks before we actually made the change. In case you update your IP very rarely, you may not have received this message (because we might have considered your account passive), in which case we’d like to apologize!

Stay secure,