with the assumption the usb150 does not receive a “poweroff” before being pulled from power.
if the usb150 boots and cannot get internet access it defaults to a time last known to the router. how is this done. (time stamp on a file or gl-specific file created by script with date and time inside)
when the router does get connectivity to the internal, what is the time frame it takes before it actually gets it’s time over the internet and where can this be adjusted.
For systems without battery clocks, which I think are all GL iNet travel routers, they seem to use the last time stamp in /etc. I have some GL-AR300M running as servers in restricted areas, so I reboot them nightly with the cron entry:
18 0 * * * sleep 70 && touch /etc/banner && sync && sleep 5 && reboot
This way the initial time set on boot is after the time the cron entry would run, to make sure I do not get into a boot loop. I have used logread to verify that the time on boot is set to the time stamp on /etc/banner and then changes once the system starts talking to the NTP servers. This work-around came from the post:
For how long this takes on your system, look for a time jump in logread after the system boots. It normally happens around when hostapd: attaches to your AP.
Thanks for joining the discussion. that would be a controlled reboot. My question points more towards an uncontrolled power cycle and non eloquent shutdown. (as when the gl-usb150 is unplugged physically)
From my research, in an uncontrolled shutdown, the system would use the timestamp on the last file to be updated in /etc until it could get an update over the network.
for question #1 that is the expected result from my research, but gli has many internal things internal things that they do that might make the answer to question #2 easier. in my testing almost 5 minutes had passed after connectivity and the system clock still had not change so I am looking to speed up the process. I guess I could just write a script in rc.local that check for internet connectivity and restart sysntpd but was also wondering if it was a bug
I have sometime seen the same problem on pure openwrt. My guess is sysntpd didn’t have connectivity at the time it started
that’s exactly what I wanted to hear to satisfy my curiosity…And I’m still alive on top of it all! bonus!
thanks
after further testing I noticed it can sometimes take up 35 seconds after wwan connection for time to be set correctly. what i also notice was an ls -lc in the /etc directory after the time was auto set did not show any files with the current time once the wwan was connected so there is some other mechanism being used to remember time.
System date and time are set by /etc/init.d/sysfixtime script by finding the most recent timestamp of any file found in /etc:
boot() {
local curtime="$(date +%s)"
local maxtime="$(find /etc -type f -exec date -r {} +%s \; | sort -nr | head -n1)"
[ $curtime -lt $maxtime ] && date -s @$maxtime
}
Then, if you have Internet connection, NTP client will receive the actual date and time from an NTP server configured in /etc/config/system
for me the most current time stamp found in /etc with an “ls -lca” was the config directory but was still older than the previous system boot time. so since I have to wait at least a minimum of 35 seconds or more for sysntpd to work after a wwan connection. Problem seems to be there are no changes sometimes to /etc directory so I’m looking to force with a “touch /etc/banner” with “/etc/init.d/sysntpd reload” so at least the most currect time of network connectivity of the boot time of the last boot and atleast 1 touch every 1hour. router is used in a vehicle so it’s not over writing. i’m not so worried about to many writes to nvram. usb150 is really nice. I guess if it were a perfect world and there were smaller, faster and more power economical chips be built frequently enough we might find a usb300 under the Christmas tree with the same or smaller footprint with 128mb, microsd slot and an rtc which takes a very tiny button cell battery. 