3

A Raspberry Pi is behind a firewall which is configured to only allow it to access a single external IP (with all ports) which belongs to a Centos7 server.

How can the two devices be configured to ensure that the Raspberry Pi's UTC time is always accurate.

Steps that I have taken...

  1. Configured ntp on server, pointed to server 0.us.pool.ntp.org, configured firewall, etc.
  2. On Pi client, comment out default servers and point to my server, restart.

However, the time is about 1 hour off. Do I still need to configure my server to allow the client to access? If so, can/should I allow all clients, or just mine?

Raspberry Pi

michael@pi:~ $ ntpq -c lpeer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 12.345.67.890   .INIT.          16 u    -   64    0    0.000    0.000   0.000
michael@pi:~ $ date -R
Tue, 20 Jun 2017 10:37:17 +0000

About 24 hours later

michael@pi:~ $ ntpq -c lpeer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 74.208.80.161   .INIT.          16 u    - 1024    0    0.000    0.000   0.000
michael@pi:~ $ date -R
Wed, 21 Jun 2017 11:29:08 +0000

michael@pi:~ $ grep '^[^ #]' /etc/ntp.conf
driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server 12.345.67.890    #This is the Centos server
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

CentOS

[michael@centos7 ~]$ ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+104.156.99.226  192.12.19.20     2 u   21 1024  377   68.864    0.518   0.930
+108.59.2.24     130.133.1.10     2 u   68 1024  377   56.934   -0.234   0.881
+66.7.96.1       216.218.254.202  2 u  480 1024  367   71.228    0.149   1.752
*97.107.128.58   209.51.161.238   2 u   87 1024  377   52.881    1.430   1.507
[michael@centos7 ~]$

About 12 hours later

[michael@centos7 ~]$ ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+104.156.99.226  204.123.2.72     2 u  432 1024  377   68.857    0.466   0.128
+108.59.2.24     130.133.1.10     2 u  838 1024  377   56.550   -0.114   0.083
*66.7.96.1       216.218.192.202  2 u  911 1024  377   73.391    0.920   1.763
-97.107.128.58   209.51.161.238   2 u  655 1024  377   56.110    2.394   0.125
[michael@centos7 ~]$ date -R
Wed, 21 Jun 2017 12:30:44 +0000

[michael@centos7 ~]$ grep '^[^ #]' /etc/ntp.conf
driftfile /var/lib/ntp/drift
restrict default nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict ::1
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
disable monitor
logfile /var/log/ntp.log
  • @cutrightjm No. I agree it totally sounds like a homework question! – user1032531 Jun 19 '17 at 15:29
  • Related: NTP with networks isolated – Mark Plotnick Jun 19 '17 at 16:46
  • @MarkPlotnick Thanks, will check it out. Also, I am assuming that NTP should be used. Right? – user1032531 Jun 19 '17 at 17:14
  • Yes, NTP is preferred, especially if your clocks aren't accurate when left to run on their own, because NTP will check and fix the time every few minutes. An alternative which is not as robust is to run rdate at boot and once in awhile thereafter. – Mark Plotnick Jun 19 '17 at 17:31
  • 1
    Can the Centos7 server access the internet without issue? I'd have it sync to the atomic clocks, and then be an NTP server that the Pi can sync to (which is, now that I look, essentially what Mark Plotnick indicated). Or, you could add a GPS receiver (either to the Centos7 and again have it be a NTP source) or the the Pi. Personally I'd go with my own GPS. – KevinO Jun 19 '17 at 21:37
2

Use a DS3231 RTC module (I2C), and update its time from an NTP server. It is more accurate than my high-end business laptop's built-in RTC.

Next DS3231 for Raspberry Pi RTC Board Real Time Clock Module | Amazon

Note: Cut/unsolder the tiny SMD diode which at its cathode is directly connected to the positive terminal of the battery. Use 200ohm/continuity test on your DMM to find it. It looks like a tiny glass bead. You don't need to charge the battery, yet some modules do it anyway.

Adding a DS3231 Real Time Clock To The Raspberry Pi

Don't use DS1307, it drifts several minutes per month.

Update: You can also use a Si4703 module to get time and date - look at SparkFuns site.

0
+50

This answer is being offered after the solution has been identified through the comments.

Issues that needed to be resolved were:

  1. Clarity

    It wasn't initially clear which configuration files were for the CentOS system (none) and which were for the Pi (some). Later updates to the question cleared that up admirably.

  2. The CentOS server was not initially synchronised to its upstream servers.

    This takes a number of iterations of the poll interval, and ideally the reachability of at least one server should be 377. This is an octal representation of a bitfield that shows the number of recent requests that were successful. Each interval pushes a 1 or 0 on the least significant end of the bitfield. 377 corresponds to 11-111-111.

  3. The Pi couldn't synchronise to its CentOS upstream server

    The iptables firewall on the CentOS server was not at fault, but would have needed to be set to allow inbound UDP queries from the Pi to port 123 and matching replies returned - firewall-cmd --permanent --add-service ntp. It would also have to have allowed outbound requests to the upstream servers on UDP/123 and their corresponding replies. Using servers from the NTP Pool complicates this slightly because servers' IP addresses are switched in and out of the pool on an hourly basis. One option here would be to allow all outbound traffic on UDP/123 and matching replies.

    It turned out that there was a hardware firewall protecting the CentOS system, and it not been configured to allow NTP traffic from the Pi.

-1

Looks like the Pi is having trouble reaching the NTP service. On CentOS there is a built-in firewall enabled by default which blocks most incoming traffic. To allow incoming NTP requests, do the following on the CentoOS 7 box:

firewall-cmd --permanent --add-service ntp
firewall-cmd --reload
  • 3
    Please improve your answer and explain why this solves the problem. – countermode Jun 23 '17 at 6:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.