0

I have a few raspberry pi's operating at a customer facility, and this facility has restricted the pi's traffic to only the IP of my server (digital ocean ubuntu droplet running a django application). They were working great for a few weeks until they stopped communicating. The IT group at this company realized it was because the clocks on the raspberry pi's were out of sync, causing the https request/response to fail. What is the best way of solving this issue? Preferably without additional hardware. I have seen some other posts suggesting a real time clock, but I would really prefer to do this without adding more hardware if that is a possibility.

My thought is to have my server send a date to the pi every few days over https as a string, and have the pi run a script to change the time to this new submitted date?

MattG
  • 173
  • 5

3 Answers3

3

It is possible to setup a local NTP server on your server. The RasPis can address this NTP server to synchronize their clocks with all the features NTP provides. If the server can connect to the internet, its NTP server can synchronize with a time server on the web, so you do not have to monitor the time on your local NTP server.

Ingo
  • 40,606
  • 15
  • 76
  • 189
2

Without access to a NTP server the only solution is a RTC.

You can copy the date from the host by running
ssh pi@hostIP sudo date -s$(date -Ins) before ssh connection.

Milliways
  • 54,718
  • 26
  • 92
  • 182
1

"Best way of solving this issue... without hardware".

OK... but "the issue" is not particularly well-defined IMHO. For example:

clocks on the raspberry pi's were out of sync, causing the https request/response to fail

Assuming your RPis use the default SNTP in systemd-timesyncd, it's clear enough that system time on these RPis will tend to greater variance than some. This because SNTP sacrificed accuracy for other objectives; see this for more details.

But... where is the https request/response failing? - on your client's machinery, or on your RPis?... or on your django droplet thing-y? Available solutions will be different depending upon which hosts are choking over the bogus time. And is the django droplet thing-y hosted on RPi - or on one of DO's servers? My point is only this: the missing details may mean you're foregoing some good solutions.

For example, one obvious solution is to replace SNTP with a more accurate service in systemd-timesyncd; e.g. openntpd or chrony, and configure one of your RPIs to act as a time server for the others. But your question fails to inform us whether or not that's possible; i.e. "facility has restricted the pi's traffic to only the IP of my server". This is an ambiguous specification because you don't say if your "server" could provide (or relay) NTP services.

Another example: If your RPis can access an https web server with accurate time, you could simply issue a curl -v to that server, and grep the headers for an accurate date-time:

curl -v https://google.com/ 2>&1 | grep "< date:"
< date: Sat, 31 Oct 2020 19:48:16 GMT

You'll obviously need to parse this quickly, and use it to set time on your system(s).

Similarly, perhaps a django droplet can learn what the time is, and share that with your RPis.

Finally, wrt another fuzzy requirement:

Preferably without additional hardware.

What exactly is your priority? A working solution, or satisfying your preferences?

There are many sources of accurate time. You don't want hardware? OK - here's one solution:

  1. call this number on your telephone: +1 (303) 499-7111

  2. when your call is answered, enter the following command as fast as you can:

sudo date -s -u '2020-10-31 19:48:16'

OTOH, if hardware is allowed as part of a solution, you could consider a GPS-based solution - they make "GPS-HATs" for the RPi. If satellite visibility is an issue, consider using and RTL-SDR dongle to access one of the rf-broadcast time services.

An RTL-SDR dongle can receive accurate time broadcasts including ADS-B messages from aircraft and/or FDA facilities.

In the US, the WWV (and WWVH) signals are broadcast continuously on 2.5 MHz & 20 MHz frequencies. Around the world, there are other systems that provide time services. Besides the RTL-SDR dongle receiver, there is at least one excellent tutorial describing how to hack a receiver using a Raspberry Pi.

And so, if you exclude "additional hardware" from the set of solutions, you may be missing out on a world of inexpensive and reliable sources of time.

Seamus
  • 18,728
  • 2
  • 27
  • 57