Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Going in circles without a real-time clock

rachelbythebay.com

Post reply on HN
Print view View original

31–40 of 157 posts

Re: Going in circles without a real-time clock

#31

Post by Hrnrurj »

riobard wrote: post #14

Speaking 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…

Voltage check on battery is part of regular PC maintenance. Like cleaning dust, checking all fans are spinning, capacitors are not getting bigger, checking for weird sounds in PSU, overnight memtest...

You should do it every year or two...

Re: Going in circles without a real-time clock

#32

Post by citrin_ru »

CaliforniaKarl wrote: post #26

I 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.

I trust a free wifi hotspot to give me an IP (traffic will be protected by TLS), but not with the time. E. g. time from the past can be used to trick into accepting an expired TLS certificate. But for most wifi hotspots it will be unintentionally wrong because such devices often unmonitored and not maintained until they completely break.

Re: Going in circles without a real-time clock

#33

Post by M95D »

icehawk wrote: post #15
M95D wrote: post #8

RTC 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 a DS1307 installed ever since I bought a RPi3B+. It didn't fail and it's accurate enough until NTP updates the time.

Are you sure you connected it correctly?

Re: Going in circles without a real-time clock

#34

Post by mapreduce »

CaliforniaKarl wrote: post #26

I 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.

> If you’re already trusting it for your IP address, you might as well trust it with the current UTC time

I don't follow! How does trusting DHCP with IP address automatically mean I should trust it with the current UTC time?

Time requires higher degree of trust than IP.

I may not care what my IP address looks like but I might care a lot about what the current UTC time is and I might want this to come from a more trustworthy device.

Re: Going in circles without a real-time clock

#36

Post by hcfman »

hcfman wrote: post #35

Install sbts-aru as a base system and it will keep your Pi accuracy to sub-microsecond error. https://github.com/hcfman/sbts-aru Problem solved.

Or... Install one of these on a Pi somewhere in your network and use that as a time source for all of your devices. Problem solved for all your machines.

Re: Going in circles without a real-time clock

#37

Post by hcfman »

hcfman wrote: post #36
hcfman wrote: post #35

Install sbts-aru as a base system and it will keep your Pi accuracy to sub-microsecond error. https://github.com/hcfman/sbts-aru Problem solved.

Or... Install one of these on a Pi somewhere in your network and use that as a time source for all of your devices. Problem solved for all your machines.

So you know, sbts-aru is an audio recording program. However, in one command it sets an an overlayFS protected SD card setup and chrony GPS based time synchronization. You can turn off all the recording related stuff and then you have a stratum #1 time server for your network. Real easy, real cheap. No more time problems.

There's no reason now for all geeks not to have at least one stratum #1 time server in their networks. Really none.

Re: Going in circles without a real-time clock

#38

Post by hcfman »

jlubawy wrote: post #11

My raspberry pi is also currently dead, something it didn't like about updating the OS caused it to be bricked. All updates were done within the OS, so didn't expect anything bad to happen. I could reflash the OS, but I also "don't have the time". I'll just use my laptop until I do have the time someday to resurrect it.

Quite likely installing the sbts-aru as a base project would have prevented this as well. Loads of SD cards get corrupted historically without apparent good reason. Using a memory-based overlayFS file system solves so many of these problems. sbts-aru, as well as setting up a stratum #1 time server sets up a resilient memory overlayFS as a base.

Re: Going in circles without a real-time clock

#39

Post by Terr_ »

mapreduce wrote: post #34
CaliforniaKarl wrote: post #26

I 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.

> If you’re already trusting it for your IP address, you might as well trust it with the current UTC time I don't follow! How does trusting DHCP with IP address automatically mean I should trust it with the current UTC time? Time requires higher degree of trust than IP. I may not care what my IP address looks like but I might care a lot about what the current UTC time is and I might want this to come from a more trus…

To offer an example, if an attacker can manipulate the time then they can make the target accept expired or revoked cryptographic certificates, potentially enabling impersonation or man-in-the-middle attacks.

In contrast, a different IP than expected isn't such a big deal... Although it might break the collaboration of two computers as crude denial of service

Re: Going in circles without a real-time clock

#40

Post by hcfman »

cjbillington wrote: post #28

The 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 enab…

Well... I see where you are going with this but is it necessary? What happens if the clock gets it's correct time sync back, will not wireguard come back online by itself ?

Then the real solution might involve ensuring good clock sync. Using a GPS synched time source is good for this, such as this one :) https://github.com/hcfman/sbts-aru

Post reply on HN