For some reason the router messes up the time when rebooting - not every time, but quite often. Sometimes by minutes, sometimes by a day or so. What might be causing this?
Since virtually all all-in-one routers don’t have a battery-backed, real-time clock (RTC), they don’t “know” what time it is when they boot. For most applications, a clock that is always going forward is sufficient, not absolute accuracy.
Since there is no RTC, OpenWrt “does its best” by setting the clock to the last-modified file in /tmp/, which isn’t a terrible thing as it’s almost always somewhere in the past. Typically sysntpd or, if installed ntpd will query Internet time servers and advance the system clock to a more-correct time. Until there is “NTP sync”, the time will be somewhere in the past.
This usually isn’t a problem for most applications for most users. The one notable exception being if you insist on connecting over Wireguard before you have NTP sync, as Wireguard can interpret the time sent being before it last “heard from you” as a replay attempt and decline the connection.
Can it take the time from the device that it’s connected to/through?
Well - go upstream and get a proper ntpd and we can go back into the future - with this - RTC’s? Where we’re going we won’t need RTC’s - ntpd is good enough for many purposes, including fun things like SDR, it’s that good…
Anyways - getting started here…
opkg update
opkg install ntpd
/etc/init.d/sysntpd disable
/etc/init.d/ntpd enable
/etc/init.d/ntpd start
netstat -l | grep ntp
Netstat should show that NTP is looking for time…
Let’s check…
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*ns512634.ip-167 192.168.10.254 2 u 64 64 37 86.233 0.353 1.373
+golf.zq1.de 205.46.178.169 2 u 62 64 37 158.028 -2.374 2.308
+yikes.bl2.tolna 130.149.17.8 2 u 63 64 37 184.319 0.734 2.128
-uruz.org 235.106.237.243 3 u 65 64 37 158.519 -1.657 7.792
If you want to change the ntp servers - look at /etc/config/system…
config timeserver 'ntp'
option enabled '1'
option enable_server '0'
list server '0.openwrt.pool.ntp.org'
list server '1.openwrt.pool.ntp.org'
list server '2.openwrt.pool.ntp.org'
list server '3.openwrt.pool.ntp.org'
One can use these - or the debian pools…
And since most VPN/Timesource folks are concerned about entropy sooner or later…
opkg install haveged
/etc/init.d/haveged enable
/etc/init.d/haveged start
This fills the entropy pool…
Checking…
cat /proc/sys/kernel/random/entropy_avail
1401
And that helps with things like OpenVPN/Wireguard along with Stubby and DNS over TLS…
I’ve done this with a couple of WRT distro’s and all is good there…
How is it possible that sometimes it has the exact right time once turned on after hours of being off, if it doesn’t have a battery?
Because by the time you can connect to it, it has network connectivity and has synchronized time already.
This is typically only an issue for time-sensitive services during very early boot.
1 Like