Initial clock set

[snaunton]

Enhancement: Add a custom script for the intial-clock-set event. A place to execute anything that requires accurate time during boot. Note: have only tested on an RT-AC68U, but it works well.

[jackyaz]

I second this as a feature!

[RMerl]

My fear with this script is that programmers might start just dumping everything into this specific script rather than simply put their scripts in the more appropriate location, and take care of checking the state of ntp_ready in a waiting loop.

[snaunton]

I sort of understand where you are coming from (I used to poll google using ping to see when the wan was really up, and have moved some scripts - the ones which need proper time to this custom script since), but I also don't really see to much of a problem with them doing so, other than a potentially longer boot. Open source is open after all. If someone wants to do this why hold them back? It is almost certainly not going to break anything.

It's also only really a good place to put things on boot and after the time has been set properly (of course). If you set firewall or nat rules here then they will get overwritten quite regularly in my experience. If a user wants to run something when the wan connects, this doesn't run when the wan reconnects (I had loads of ISP problems last week and this did not run at all when the wan reconnected ... over and over and over again).

[RMerl]

#!/bin/sh

WAITTIMER=0
while [ "$(nvram get ntp_ready)" != "1" -a $WAITTIMER -lt 14 ]
do
        WAITTIMER=$((WAITTIMER+2))
        sleep $WAITTIMER
done

This will wait for ntp_ready to be set in a resource-friendly way. After that you can make one last check, if it's still not set then error out. This is much cleaner IMHO than having everyone start piling up their code within the ntp_ready event itself where it doesn't belong.

[snaunton]

Where would you put that though? wan-event seems the only real option (although I do not know the code as well as you obviously so am happy to be wrong in this). This means that any code is going to be potentially executed whenever there is a change in the wan status, or at least need more "should I execute this now" code.

With initial-clock-set it is only going to be executed when the initial clock is set, usually just during boot. How often does a normal user reboot their router? I know I aim to never reboot it if possible, but I have to when I upgrade firmware :).

[jackyaz]

Various script developers already use a wait loop, but it isn't a very clean solution. Event-driven is usually the way to go, where possible.

At the moment, another option is to hook the "restart_diskmon" event which is called when NTP starts. This is used by at least 1 developer in the absence of an official NTP event hook.

[RMerl]

Event-driven is usually the way to go, where possible.

I agree, but an NTP clock getting set should not be a triggering event for Unbound to get started (as it needs an accurate clock for DNSSEC), Wireguard to get started, and so on. Especially since these will also require other things to be up and running, such as the USB disk to be mounted. Why is loop waiting for the USB disk to be mounted better than having a loop waiting for NTP to be set? The NTP check is actually lighter on system resources than a mount point check if the developer is worried about performance.

That ntp script would just become a huge mess as a dumping ground for everyone and his dog to use for their own scripts.

In an ideal world, services would get started where they belong, and an ntp-synced script could be used to signal those services to restart themselves - this is what dnsmasq does for example. I fear that developers might take the lazy route instead of signaling services started in their appropriate location, and start all of their services here.

[jackyaz]

I personally now use post-mount to satisfy the USB disk ready, but I do have functions for Entware and NTP wait loops. I'm considering increasing the 5 minute limit on the NTP loop since it seems to get hit more than I'd like for most installs.

[RMerl]

Where would you put that though?

It depends on the service. Ideally, it would be done through services-start, as that is where Asuswrt starts most of its own services. A lot of addons rely on Entware however, so they use post-mount, which is also an appropriate location, as Entware services themselves are started there (if any).

[RMerl]

I personally now use post-mount to satisfy the USB disk ready, but I do have functions for Entware and NTP wait loops. I'm considering increasing the 5 minute limit on the NTP loop since it seems to get hit more than I'd like for most installs.

I find it surprising that a boot process + NTP sync would take that long to occur.

[jackyaz]

I personally now use post-mount to satisfy the USB disk ready, but I do have functions for Entware and NTP wait loops. I'm considering increasing the 5 minute limit on the NTP loop since it seems to get hit more than I'd like for most installs.

I find it surprising that a boot process + NTP sync would take that long to occur.

Same, but it happens! I have a script/watchdog I wrote that aggressively checks for NTP and restarts the ntp service every 30s or so which gets it synced faster. Im not sure how often the f/w/ntp service usually tries to sync.

[RMerl]

On my RT-AC68U, after syslog is started, it only takes 1 minutes and 25 seconds before NTP gets synced. Probably much less between the time the USB is mounted and NTP is synced (assuming the USB isn't mounted even after NTP gets synced).

EDIT: I just checked, and on this RT-AC68U the USB disk actually gets mounted after ntp gets synced (3 seconds after ntp sync, to be precise).

Im not sure how often the f/w/ntp service usually tries to sync.

It's handled by ntpd, so whatever retry timings are used by default (I can't remember what they are, it's been too long since I've worked on the ntpd code). This is something I want to take a look at at some point in the future, see if the initial time sync could be made more aggressive.

[jackyaz]

What times do you see on HND?

[RMerl]

What times do you see on HND?

18 seconds between syslogd start and ntp getting set on my RT-AX88U, give or take a few seconds (as I don't have any log entry between WAN being reconnected and ntp's initial sync).

[jackyaz]

That's pretty quick! I wonder why it takes some users more than 5 minutes. This is the script I currently use: http://www.snbforums.com/threads/mounting-issues-with-add-ons.69807/post-658338

[RMerl]

Could be slower connection time as they use PPPoE, or their ISP requires their previous session to fully expire before they can reconnect again. Could be configuration errors on their DNS/NTP parameters... Hard to tell without being able to actively monitor the boot process as it occurs. Even syslog is only partly helpful, because at least in my case ntpd sets the clock nearly at the same time that the log message about WAN having reconnected, so even that message has the correct clock already set on the RT-AX88U.

There are a LOT of people out there who have completely broken DNS setups on their routers. Many will leave their WAN DNS empty after setting DoT, ignoring the fact that the router needs those DNS to be working early on.

Without having a test case to observe, I can only speculate as to what is going on with these setups.

[JackMerlin]

I hope there can be same custom scripts at the radio-start/end and wps-press

Especially the event by the WPS button, this can be very useful, because it will perform the planned operations without entering the terminal or gui.