My o2 Box 6431 has no builtin RTC and thus has an incorrect time upon each boot until the time is retrieved via NTP. This causes incorrect timestamps in my logs and some certificate check failures.
Has anyone ever managed to add a RTC (real time clock) to a Lantiq xrx200 device, e.g. the o2 Box 6431 or Vodafone Easybox 904 or TP-Link VR200v?
AFAICS there are multiple options for connecting a RTC:
i2c (either builtin or via GPIO), no idea if i2c is supported natively on xrx200, and it seems bitbanging i2c would add a high burden on devices already restricted to singlecore operation for FXS reasons
serial, but might cause weird interactions with the builtin serial console)
USB, but USB starts being available ~0.5 seconds after ethernet gets link, so it's a bit late
You could add a hotplug script that checks whether the time has been updated before starting your application. E.g. for freeswitch I use this script. It fires up freeswitch when the WAN interfaces goes up, but only once ntpd has properly updated the time on the router.
You can "help" the early boot time as it looks for the most recent timestamp in /etc/. A periodic touch there should at least get you past the problems with certificate validation.
See /etc/init.d/sysfixtime
There have been discussions about RTC before on the forum here, with a couple of suggestions. I vaguely recall some USB-based options, but I also vaguely recall the price somewhere around US $30 and personally dismissing that as too expensive.
One more reason, to re-work the time settings via NTP, to bring it to the very front of chain of init scripts. For my usage case (wireguard) I implemented some "dirty" hacks.
In the first post its written "USB, but USB starts being available ~0.5 seconds after ethernet gets link, so it's a bit late".
I dont think that a rework of NTP would fix the requirements of @hailfinger . He needs the correct time set much more early. On a lantiq device he probably also use a DSL line. For a working DSL connection to get NTP working he would probably have to wait at least some seconds after boot to get internet access.
@hailfinger
Would the touching of a file in /etc like mentioned by @jeff work for you? You could touch it as often you like. So the time you see at boot would be the time you have shut down the device. For your logfiles this should be looking really clean. Shutdown time -> startup-log continuing the time -> sync of new time.
If thats not enough, it would be interesting what usecase would require some more exact time setup.
I can understand the OP's concerns more clearly now. 10-20 seconds of "mis-dated" logs of early boot isn't too annoying, but ...
Even though an I2C bit-banging interface would chew up more CPU cycles than a native implementation, I don't think that you'd be passing much data. It looks like with, for example a Maxim DS1307, reading 8 bytes or less at startup, perhaps writing 8 bytes when you get NTP sync and maybe once a day thereafter. Even if it swamped your CPU for that tiny fraction of a second (which I doubt it would), it doesn't seem like it would have meaningful impact.
I tried to specify a local NTP server (in addition to servers on the internet) in the OpenWrt settings, but apparently there are some delays and/or other effects, so the NTP time correction only kicked in after a few minutes when DSL came up. No idea what happened there, will try to track this down and possibly (if this is a bug in OpenWrt) open a bug report.
Regularly touching a file in /etc might wear out the onboard flash chip, but AFAICS JFFS2 wear-leveling should take care of that as long as enough free space exists. I'll try that on my backup router as it looks like the cheapest and easiest solution, and might even be something we can create an OpenWrt package for.
Since I couldn't find an easily accessible GPIO or I2C on my routers, I decided follow up on the USB RTC suggestion. The existing solutions are somewhat expensive (plus really expensive shipping), so I investigated rolling my own USB-I2C-RTC. With a Digispark clone, a Chronodot clone and a CR1632 battery, this looks like a solution with a total cost below 4 EUR (incl. shipping). There's even a ready-made firmware for the Digispark as USB-I2C host: https://github.com/harbaum/I2C-Tiny-USB/tree/master/digispark. OpenWrt supports that firmware with the kmod-i2c-tiny-usb package.
@jeff, you may recall that it turns out the OP of that thread was having issues raising a WIreguard VPN. After extensive testing...I determined that it was cryptographic entropy, not time. Using a a device with an RNG, I was able to verify that tunnels came up faster with more system entropy available. An identical device with an enabled ath9k chip didn't experience the issue, as it used radio noise for entropy.
Did you power off or stop the LAN NTP service while the Internet was disconnect?
Do these check failures prevent some kind of VPN from standing up?
If so, is this a full-site VPN (i.e. all outbound traffic uses it)?
If so, can you provide the result of the following command as soon as you're able to login:
The LAN NTP service stayed up, but the router was powered off.
The check failures are rare and difficult to reproduce. IIRC they happen when my dynamic DNS provider updates its TLS certificate, resulting in a failed DNS update.
That makes sense, as the date on the router could be before the valid dates of the certificate, prior to time/date synchronization.
If this or something similar is the situation (which, by definition, establishes that outside connectivity is "up"), a check to see if NTP has synchronized would be possible, potentially followed up by a simple "GET" to the server in question, which will return that server's concept of its time. That time could be used as a "quick set" of the local clock, with the caveat that it might be "ahead" of "real" time, depending on how reliable the remote server's time synchronization is.
$ curl -v https://google.com/ > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 216.58.192.14...
* TCP_NODELAY set
* Connected to google.com (216.58.192.14) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.google.com
* Server certificate: Google Internet Authority G3
* Server certificate: GlobalSign
> GET / HTTP/1.1
> Host: google.com
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: https://www.google.com/
< Content-Type: text/html; charset=UTF-8
< Date: Thu, 23 Aug 2018 14:54:10 GMT
[...]
and to determine the dates of validity of the certificate
Soldering that solution was easy, and it even works well on Debian, but not on OpenWrt.
With kmod-i2c-tiny-usb on the Lantiq xrx200 target, I can access the RTC with i2c-tools, but the kmod-rtc-ds1307 package to support the RTC apparently is not being compiled for the Lantiq xrx200. The same package is available for ar71xx NAND targets, so this seems to be target config dependent. Once kmod-rtc-ds1307 is available on xrx200, this problem should go away.
The last time this problem came up on the mailing list was in January 2018: https://lists.openwrt.org/pipermail/openwrt-devel/2018-January/010587.html
ds1307 kmod is not available prebuilt for lantiq because RTC feature flag is not set in the Makefile.
Without it being set RTC class is not built and since RTC is not tristate anymore.
But you can compile it yourself fine.