I'm using ddclient v. 3.7.3 to update my IP address using DynDNS. My configuration is pretty standard -- see the pastebin link below. According to the debugging messages, I'm not having any problem getting my current IP address from checkip.dyndns.org (I checked the address and it is correct) and update url for DynDNS contains that same correct IP address. However, the cache file contains a blank IP entry ("IP=", see the config file listed in pastebin below). Subsequent runs throw this error:
"WARNING: file /var/cache/ddclient/ddclient.cache, line 3: Invalid Value for keyword 'ip' = ''"
This makes sense considering the IP address isn't being written to the file. If I manually input an IP address in that file (say IP=22.214.171.124 or whatever), the error goes away. However, subsequent runs not only do not throw any errors but do not update the value in the cache.
This is all very strange. I took a look at the code and found that if I added to IP address to %config at a strategic location, it seems to correctly update the IP address in the cache file (see the third pastebin link below). This isn't a solution to this problem, whatever it may be -- but it might point you in the right direction. Please let me know if I can provide any more information.
Config file - http://ddclient.pastebin.ca/908238
Cache file - http://ddclient.pastebin.ca/908241
Crude Patch - http://ddclient.pastebin.ca/908248
Here's the error message when encountering the "IP=" in the cache file.
Thank you for your pretty complete report.
Previous reports about wrong writing to the cache file where all related to misconfigurations:
* It's not the cause of your problem but I removed unneeded lines in your configuration. See http://ddclient.pastebin.ca/908275
* I see you use SSL. Did you installed the correct SSL-package for your distribution? On debian, you need libio-socket-ssl-perl to have IO::Socket::SSL which is needed to use SSL
* If your used hostname reflects the reality, you're using a custom domain. Use custom=yes.
If any of my comments are correct, remove your cache and try again running verbose. It should work much better.
Okay, I think I've figured it out. The problem has nothing whatsoever to do with what I thought it did. The cache file updating works fine. However, IP address is only added to the %config hash when the update process succeeds. The problem is actually that it never succeeded; the 'IP=' issue was just a symptom of this.
I should learn to read the documentation more carefully. For some reason I thought I was using -verbose when in actuality I was not. Apparently, my updates requests were being rejected by DynDNS's update server because the Authorization string was being broken into two lines. Yes, I do have a ridiculously large password of 63 characters which was causing the line (with "Authorization: Basic " prepended) to exceed 76 characters. When presented with this, DynDNS sends back a 400 Bad Request error similar to this (imagine that the XXXXX contains the chopped off piece of my auth string):
RECEIVE: HTTP/1.1 400 Bad Request
RECEIVE: Date: Mon, 18 Feb 2008 18:46:18 GMT
RECEIVE: Server: Apache
RECEIVE: Content-Length: 312
RECEIVE: Connection: close
RECEIVE: Content-Type: text/html; charset=iso-8859-1
RECEIVE: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
RECEIVE: <title>400 Bad Request</title>
RECEIVE: <h1>Bad Request</h1>
RECEIVE: <p>Your browser sent a request that this server could not understand.<br />
RECEIVE: Request header field is missing ':' separator.<br />
If I change the code according to the patch at http://ddclient.pastebin.ca/908785, DynDNS does not send me the error, my IP address is updated correctly and written to the cache file, and peace and harmony are restored to the universe.
I did discover one other thing. My ridiculous password was randomly generated and contained a '\' character. This was lost when ddclient read the password from the configuration file (it was probably interpreted as an escape); I had to add an additional '\' to keep it from being destroyed. It seems like the code is making an effort to protect '#' characters in passwords so I think it would be a good idea to protect some other characters as well. That or at least make a note in the documentation of what characters are protected or not.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.