I made some progress on this, and I think there is a spot that needs improvement in the source of the dyndns script. When the curl function is called, the URL is built with an IP address derived from the hostname of checkip.dyndns.org, instead of actually the name.
Original Line 1226 of dyndns.class:```
$ip_ch = curl_init("http://{$checkip}");
Improvement:```
$ip_ch = curl_init("http://{$hosttocheck}");
I understand we could first check to see if the name resolves, but curl should be called with a hostname, not an IP, so that the web server that runs the service can respond to the called service correctly, even if it has virtual hosts or a similar configuration on it. I stumbled upon this because the checkip.dyndns server that was resolving at the time, was not working correctly, and it was replying a generic dyndns page. On noticing this unreliability with the checkip service, I built my checkip service on a web server that runs virtual hosts, thus when curl called with an IP, it would not reply to the checkip service.
Anyway, that doesn't resolve the issue Im having, but I feel its a better way to call curl with hostname rather than IP.
The problem I still haven't been able to resolve, is that I'm still getting "route: writing to routing socket: No such process" notifications. The dyndns update seems to run twice each time (this is not related to the multiple cron bug that was resolved recently), and checkip.dyndns.org does service throttling and does not seem to like more than one request quickly, thus it would sometimes not reply and generate errors. Now with my own checkip service, the script always receives the public IP even if it executes mutliple times and updates fine, even if it does it twice, but still generates the "route: writing to routing socket: No such process" notification…
