I ran into a similar problem on a Raspberry Pi, where my program would ignore data because it was deemed too old.
It turns out a Pi uses fake-hwclock. This tool stores a timestamp regularly in a file. On boot the Pi reads from that file to set the time. When the Pi has been turned off for longer then the initial time can be hours or days out of sync.
The Pi then takes a couple of seconds to obtain a valid time via NTP, but my program ran quickly enough to work with the old timestamp. After a couple of minutes it would typically work again.
Going in circles without a real-time clock
21–30 of 157 posts
Re: Going in circles without a real-time clock
#22If you are running Bind or SSL/x.509 certs, than an RTC is pretty much a requirement on the raspberry pi. Network time leaps over NTP even when working (first big leap was allowed etc.) can still bork a lot of services.
Local stratum 1 GPS time (even with PPS pin) servers based on Pi's can suffer similar issues when they lose satellite lock (weather etc.)
Have a great day =)
Re: Going in circles without a real-time clock
#23> By "everything else", I also mean WireGuard. Did you know that if your machine gets far enough out of sync, that'll stop working, too? I had no idea that it apparently includes time in its crypto stuff, but what other explanation is there? WireGuard only requires a monotonic clock, because it periodically rotates keys to provide the forward secrecy. Peer clocks are otherwise not required to be synchronized [1]. I g…
Why does it use the time then? Why not just increment its own 96 bit number whenever you use it?
Because it is required to be monotonic per peer. WireGuard has no intrinsic states, so multiple machines with the same peer key will be seen as a single peer and that is actually a legitimate use of WireGuard. These machines would have to be synchronized to each other (but not necessarily to the external clock), and using a time is a straightforward and reasonable way to ensure this.
Re: Going in circles without a real-time clock
#24RTC module for Raspberry is ~ $1.
and you certaintly get what you pay for, DS3231s fry almost as easily as MAX3232s, (And you can do the same thing were you write the time to the RTC before you have the correct time)
I have used these in product designs before with zero failures. Where exactly did you buy your samples?
We found they drift less than 28s a year in standalone mode. Also, were repeatable within +-18ms when using a NTP client.
Microchip RTCs are harder to setup, but also seem to work just as well (ignoring the goofy epoch).
Chip shortage caused people to do unspeakable things.... ;-)
Re: Going in circles without a real-time clock
#25It's unfortunate that using DHCP to get rough time isn't more popular, especially for devices without RTC. Sure DHCP can be spoofed and should be considered more of a last resort, but it sure would be better than nothing and ending up in this kind of a situation where nothing works anymore.
Previous discussion on similar thing: "Encrypted DNS + NTP = Deadlock" https://news.ycombinator.com/item?id=34177331
Re: Going in circles without a real-time clock
#26I know I’ve brought this up before, but I can’t remember exactly where.
It would be nice if DHCP could provide the current time as one of the pieces of information it provides with a lease. If you’re already trusting it for your IP address, you might as well trust it with the current UTC time: The current 64-bit timestamp would be enough to get timestamp-sensitive things working.
Re: Going in circles without a real-time clock
#27Earlier quoted context omitted.
Most newer systems persist EFI options to NVRAM now days as well. Pulling the battery isn't generally enough to reset them anymore.
My desktop remembers all settings, but after power loss still goes into a warning where I have to press F1 to enter settings, then exit them without making changes. I couldn't find an option to not do that.
Yes, this is very annoying.
Re: Going in circles without a real-time clock
#28The wireguard problem is a pain in the neck. Even if you're happy for your system to not have a realtime clock, when it does come online you'd want wireguard to not start until after the clock has synced to a timeserver. The below is what I'm doing at the moment, but I can't say I'm sure it's working - haven't seen wireguard start before the time is synced since doing it, but it could be probabilistic:
systemctl enable systemd-time-wait-sync.service
mkdir -p /etc/systemd/system/wg-quick@wg0.service.d/
echo "[Unit]
After=time-sync.target
Wants=time-sync.target
" > /etc/systemd/system/wg-quick@wg0.service.d/override.conf
Re: Going in circles without a real-time clock
#29Speaking of RTC battery, I've recently come to the realization that I have to make sure that BIOS battery is not absolutely dead in always-on PC boxes. Background: I use an x86 box as home router. I've changed the configuration in the BIOS that it should automatically boot up on power. However if the BIOS battery is dead, the config will be lost and it will revert to default settings, which is not to boot on power. B…
Some unsolicited solutions, maybe not for you but somebody in a similar situation: maybe replace it with a supercapacitor (needs some wiring changes, otherwise it won't ever be charged, should last long enough for most power outages), or use a stack of coin cells in parallel (difficult due to physical dimensions, and they'll still go dead at some point). You can also short two wires on the ATX supply to automatically…
Somehow I feel reliability might take a hit… :|
Re: Going in circles without a real-time clock
#30Tangential: I have a pi 4 running openwrt and a wireguard interface that is routed over the WiFi access point. If you connect to this network it's as if you are connecting in another country. I have outbound traffic only going over wireguard. If wireguard is down then no internet (to avoid any leakage). However if pi loses power the clock resets, wireguard can't handshake with that much clock skew, NTP can't connect without wireguard. So I need to manually update clock after a power failure.
I guess I need requests to the NTP server to go over WAN directly. Always seemed like a hassle to get this to work with openwrt zones and stuff. My eternal gratitude to anyone who shoves me in the right direction...