Which devices have Battery backed RTC built in?

@reinerotto

Out of curiosity, since you are going to assume a network interface, have you actually observed the behavior of time going backwards, or being updated too slowly with the existing scripts? I haven't been able to chase down how it works in the scripts, but it seems that busybox ntpd has a way to simply set the time right now, with no multi-hour skewing involved, and I'd be surprised if OpenWRT booted up and didn't use that method

Can you explain the issue you're having with Wireguard that requires this highly-accurate time upon boot?

The concern described PDF mitigates replay attacks. If you have concern that a rogue peer may come to possess the Private Key of a legitimate peer, you should implement a PreShared-Key, or (if possible) better yet, rekey the server and peer.

And FYI, there's a active bug report about PreShared-Key not working in UCI at this time:

@Wayne
In case, the openwrt device with wireguard is booted with a new firmware image, which is built a couple hours before actual time,
then the system time is "into the past", as the system starts with the saved time of image build.
This then causes wireguard not to start up, as for the peer the time seems to be set back.

I have to add for clarification, that I do not use LuCi to manage the system, but various custom scripts.
I.e. within rc.local I start wg, but this will not work in case of new image, as time adjustment occures later in the /etc/init,d/-chain, unfortunately.
So I actually did some hacks to set the time earlier, as soon as WAN up, but a RTC+battery looks like cleanest solution for me.

@Wayne
In case, the openwrt device with wireguard is booted with a new firmware image, which is built a couple hours before actual time,
then the system time is "into the past", as the system starts with the saved time of image build.
This then causes wireguard not to start up, as for the peer the time seems to be set back.

I have to add for clarification, that I do not use LuCi to manage the system, but various custom scripts.
I.e. within rc.local I start wg, but this will not work in case of new image, as time adjustment occures later in the /etc/init,d/-chain, unfortunately.
So I actually did some hacks to set the time earlier, as soon as WAN up, but a RTC+battery looks like cleanest solution for me.

@Daniel: As I understand existing code, there is some "trick" used to vaguely adjust time first, by finding and using
the timestamp of youngest file within /etc..., and then to do the final adjustment gracefully.

I have an olimex lime2 board and it has support for battery

 dmesg | grep rtc
[    1.565239] hctosys: unable to open rtc device (rtc0)
[   10.232248] sunxi-rtc 1c20d00.rtc: rtc core: registered rtc-sunxi as rtc0
[   10.239166] sunxi-rtc 1c20d00.rtc: RTC enabled

OK, I can potentially see a scenario where the OpenWRT device is a client and the last time the server had was May 17, 11:09 (NTP adjusted). The client is rebooted and the server is not. The client tries to reconnect with its May 6th build time and the server "refuses" the connection. Is this what you are seeing, or is it something else?

I'm not trying to dissuade you from your search for a RTC-enabled device, but here are a couple more alternatives to consider until you find one.

  • touch a file in /etc/ on graceful shutdown (and perhaps periodically to accomodate ungraceful shutdown)
  • Hold off on bringing up the wireguard connection until the box has "good enough" time. If security/obscurity concerns you, use one of the secure DNS approaches to get the NTP servers. NTPv4 doesn't support encryption though, if that is an issue.

I think you're right, but since you're starting wg in rc.local anyway, how about just putting

/etc/init.d/sysntpd stop
ntpd -q -p pool.ntp.org
/etc/init.d/sysntpd start
sleep 2

right before starting wireguard, as documented here:
https://wiki.openwrt.org/doc/howto/ntp.client

this should slew the time directly where you need it to be in a reliable way, and then smoothly adjust the time thereafter.

I can confirm that on my router at least within the 2 second sleep, the clock is set correctly. Though I'm now thinking it should be reordered, and probably it's a good plan to sleep a little longer too.

/etc/init.d/sysntpd stop
ntpd -q -p pool.ntp.org
sleep 4
/etc/init.d/sysntpd start

I think you can add multiple pool instances with
ntpd -q -p 0.pool.ntp.org -p 1.pool.ntp.org -p 2.pool.ntp.org ...

I can't imagine a lot of real world scenarios where there's enough network connection to bring up wg but not enough network connection to make this set your clock correctly, though it's possible to think up some special cases (a lan with restrictive firewall that doesn't pass ntp packets for example... but it's pretty limited)

@Jeff: Yes, you show a real world scenario.
I already implemented your suggestion one, as a back-up procedure for the single-shot time adjustment after WAN up, which is my main
workaround.
However, nothing beats a clean solution with a RTC+battery.

2 Likes

as long as you're aware of the workaround and still want an RTC then more power to you, I just wanted to make sure the workarounds had been considered.

wit256m or witi512m MQMaker have an RTC with a battery - it works in practice as a real-time clock without the need to install an additional network client such as ntpclient.
All you need in these devices is to install the hwclock program/package ...

WARNING on AR150+RTC from GLi !
I bought an AR150+RTC. However, I found out, that GL.iNet now sells a new version of RTC, with another chip. Which is NOT supported by official openwrt yet, only by GLis own fork of lede/openwrt.
Actually I am discussing this isue on GLis forum, as I consider it not very user friendly.

Yeah,they roll their own stuff a lot.
But it should not be hard to patch in the driver.
Altough it should be better patched in into generic target
https://github.com/domino-team/lede-1701/commit/da12f900525dd31fe46bfc3d0cfdac8d83bded4a