dynamic DNS - 1/3 not correctly set at boot

[dvl]

@gertjan said in dynamic DNS - 1/3 not correctly set at boot:

Your "members.dyndns.org" page bails out with a "404" as a reply. That's good enough to fail the test. The DynDNS update procedure stops.

You say 'your'. It is not mine. It is built into the pfSense code. It is the page used to update the IP address with my DynDNS provider. It is not the page used to determine the IP address.

Am I confused about this interpretation of what is going on?

[Gertjan]

@dvl said in dynamic DNS - 1/3 not correctly set at boot:

Am I confused about this interpretation of what is going on?

Hummmm.
I see what you mean .... !

Feb 25 16:55:56 bast php-fpm[336]: /rc.dyndns.update: Curl error occurred: Could not resolve host: members.dyndns.org

This is probably an error spit out during line 460 - /etc/inc/dyndns.class - suddenly "members.dyndns.org" couldn't be be resolved.
Or, a small moment just before that point, checkip.dyndns.org resolved very well.

I guess it's actually just bad timing : the resolver (or forwarder) was being restart at that very moment.

[dvl]

Are you sure that checkip.dyndns.org is being invoked at this point or is pfSense acting upon knowing a change has occurred?

[Gertjan]

_Checkip() is called first, and uses the checkip.dyndns.org URL to get the actual WAN IP.
It's compared with the cached IP.
If different, in the case of a dyndns.org, htpps://members.dyndns.org&...... is called to set the new WAN IP.
It's that last call that fails with a "cannot resolve", I guess because at that moment the Resolver was asked to restart for some reason.

edit : remember : power came just back, processes starting up, like the dyndns house keeping. At boot time, it's not unknown that processes restart more often. Unbound is pretty known for being kicked around a lot.

[dvl]

@gertjan For what it's worth, I'm using BIND here.

In the case of a power-up after a power-failure, what can be done to ensure success on this? I have an idea.

I am tempted to invoke create a cronjob which will be invoked using the @reboot feature. That script will first sleep for 5 minutes, and then invoke /etc/rc.dyndns.update

This sleep time is based on:

• the system booted at Feb 25 16:55:01
• the 'Could not resolve host' log entry at Feb 25 16:55:56

This means any failed initial sequence will be fixed 5 minutes later.

[Gertjan]

In my early "pfSEnse" days, I also discovered that sometimes my dyndns IP was not updated.
What I did : I inserted into the /etc/inc/dyndns.class file a sleep(60) timer.
You solution is much more cleaner !

[dvl]

Thanks.

I try to never modify vendor code, instead preferring to send patches upstream.

Maintaining your own set of patches is not sustainable for moving targets.

I just installed the cron package. What is an appropriate place to install my scripts? I'm planning on /usr/local/sbin/fix-dydns-after-reboot.sh

[dvl]

Here is the file:

$ ls -l /usr/local/sbin/fix-dydns-after-reboot.sh
-rwxr-xr-x  1 root  wheel  138 Feb 28 15:40 /usr/local/sbin/fix-dydns-after-reboot.sh

$ cat /usr/local/sbin/fix-dydns-after-reboot.sh
#!/bin/sh

# sleep for 5 minutes
/bin/sleep 300

# invoke the same code as found in the crontab
/usr/bin/nice -n20 /etc/rc.dyndns.update

What I just found amusing: I ran the job from the command line and wondered why I was not seeing anything in the log files....

I need to wait 5 minutes.

[dvl]

Confirmed, this worked, by viewing: /status_logs.php

I then added to cron, to run at a soon-to-occur time. That ran fine too.

I am now confident this will run at @reboot.

[dvl]

An interesting popup when trying to delete a cron entry:

[dvl]

This is what the resulting cronjob looks like: