Bug with dyndns client?



  • Apparently at 5:50AM today, my WAN IP changed.  I was able to surf outbound just fine, and assumed all was well.  When I got to work, I could not get to my home system.  After some poking around on an external  server I manage, which one of my home servers pings periodically, I was able to determine that my IP info at dyndns was stale.  I ssh'ed in via the new IP and looked at /var/log/system.log and saw this:

    
    Oct  2 05:50:38 pfsense check_reload_status: updating dyndns
    Oct  2 05:50:42 pfsense php: : DynDns: Running updatedns()
    Oct  2 05:50:42 pfsense php: : DynDns: updatedns() starting
    Oct  2 05:50:42 pfsense php: : DynDns: _detectChange() starting.
    Oct  2 05:50:42 pfsense php: : DynDns: Current WAN IP: 98.118.100.78
    Oct  2 05:50:42 pfsense php: : DynDns: Cached IP: 173.48.115.67
    Oct  2 05:50:42 pfsense php: : DynDns: cacheIP != wan_ip.  Updating.
    Oct  2 05:50:42 pfsense php: : DynDns: DynDns _update() starting.
    Oct  2 05:50:42 pfsense php: : DynDns: DynDns _update() starting. Dynamic
    Oct  2 05:50:57 pfsense php: : Curl error occurred: Couldn't resolve host 'members.dyndns.org'
    Oct  2 05:50:57 pfsense php: : DynDns: DynDns _checkStatus() starting.
    Oct  2 05:50:57 pfsense php: : DynDns: Current Service: dyndns
    Oct  2 05:50:57 pfsense php: : phpDynDNS: PAYLOAD: 
    Oct  2 05:50:57 pfsense php: : phpDynDNS: (Unknown Response)
    
    

    And that was all she wrote :(  I ran the update script manually, and it came up just fine.  I'm assuming there was some glitch, but if that does happen, I don't think the script should just silently give up forever :(



  • For the moment, I guess I can avoid this by installing the cron package and creating a cron job that runs every few minutes to call the dyndns updater…


  • Rebel Alliance Developer Netgate

    There was a similar thread on the development list, someone else had the same problem.

    It's possible that the dyndns update is happening too soon after the reconnect, since it seems you have no working DNS servers at that point in time. One possible solution was to trigger an additional update about 15 seconds after the first.



  • Well, it's worse than I thought :( I installed the cron package to run the dyndns updater every five minutes, on the theory that if the IP has not changed, it does nothing.  My WAN bounced again, and took awhile to come back up.  From the log:

    
    Oct  2 15:36:31 pfsense php: : Curl error occurred: Couldn't resolve host 'members.dyndns.org'
    Oct  2 15:38:37 pfsense php: : Curl error occurred: Couldn't resolve host 'members.dyndns.org'
    Oct  2 15:40:18 pfsense php: : Curl error occurred: Couldn't resolve host 'members.dyndns.org'
    Oct  2 15:45:18 pfsense php: : Curl error occurred: Couldn't resolve host 'members.dyndns.org'
    
    

    I think this may have been a bonehead move on my part.  I was formerly using my linux server (clarkconnect as the gateway too).  I used 4 gte servers in the 4.2.2.0/24 block and had those in my /etc/resolv.conf.  When I installed pfsense, I was testing, so I pointed /etc/resolv.conf on pfsense at the internal server, which runs dnsmasq.  I am guessing that if you get unlucky, the cache entry for members.dyndns.org has expired, and when pfsense tries to fetch this, it can't, and since the IP has changed, you are screwed.  I will change /etc/resolv.conf on the pfsense and see.  Sorry for the waste of your time :(



  • @danswartz:

    I used 4 gte servers in the 4.2.2.0/24 block and had those in my /etc/resolv.conf.  When I installed pfsense, I was testing, so I pointed /etc/resolv.conf on pfsense at the internal server, which runs dnsmasq.  . . .  I will change /etc/resolv.conf on the pfsense and see.  Sorry for the waste of your time :(

    A better way to change the DNS specification is through the web GUI: System -> General Setup DNS Servers and uncheck the box Allow DNS server list to be overridden by DHCP/PPP on WAN

    I'd consider it a bug if the DynDNS thing isn't resilient to physical link failure. It really should keep trying to make the update, at least if the failure is "failure to connect to the server".



  • Yeah, you're right.  Editing /etc/resolv.conf is not the right way.


Log in to reply