diagnosing chronyc sources unusable - time won't sync

Question

Trying to get chrony working on a LAN, in RHEL-8.10. The service on either my chrony server or a client appears to be functional as reported by a service chronyd status -l. However I cannot get time to sync between the two, they are off by a couple minutes.

# this command is performed on a time client server, having ip 192.168.1.4 for example

chronyc> sources -a -v

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^? 192.168.1.1                   3   6   377     5  -1500us[-1705us] +/-  500ms

# I edited the name/ip here for posting, it resolves to the hostname via dns in our little LAN

And chronyc tracking reports all zeros, versus on another server that is online [intranet] is sync's to a dedicated time server and here the time matches that from time.gov to the second, and chronyc tracking reports with things like System time : 0.000830548 seconds fast of NTP time and not all zeros.

on my LAN systems, I have tried setenforce 0 and service firewalld stop and neither helped.

What causes the '?' = unusable in chronyc sources ? This seems to be the most obvious problem comparing between a working setup versus non-working.

I feel like my error is on my RHEL-8.10 server that I am trying to make a chrony time server that others sync to, is there anything special in that /etc/chrony.conf that is needed that isn't obviously already documented in that default file as provided by redhat? Below is my /etc/chrony.conf from the server I want to be the time server on my LAN having ip 192.168.1.1, which does not time sync to anything else. Am I missing anything below that would cause the '?' = unusable to happen when doing chronyc sources -a -v from a time client on my LAN?

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync

# Enable hardware timestamping on all interfaces that support it.
#hwtimestamp *

# Increase the minimum number of selectable sources required to adjust
# the system clock.
#minsources 2

# Allow NTP client access from local network.
allow 192.168.1.0/24

# Serve time even if not synchronized to a time source.
local stratum 10

# Specify file containing keys for NTP authentication.
keyfile /etc/chrony.keys

# Get TAI-UTC offset and leap seconds from the system tz database.
leapsectz right/UTC

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
#log measurements statistics tracking

And on my clients their chrony.conf simply has server 192.168.1.1 iburst at the top.

Answer 1

in my case the cause for the ? = unusable as reported by chronyc sources -a -v was not actually having port 123 UDP open in the firewall on my time server.

My /etc/firewalld/zones/custom.xml file did have a line in it to open 123/udp, however doing a firewall-cmd --list-all did not display that port number. The solution in my case was to:

• re-edit the firewall xml file, do a firewall-cmd --complete-reload and make sure 123/udp was displayed when doing a firewall-cmd --list-all.
  • of course you could also do a systemctl stop firewalld
• however even turning off the firewall on both the server and client, I observed the chronyd service needed to be restarted on the client, and then you should wait at least 30 seconds before doing a chronyc sources -a -v to see if you get a ^* response instead of ^?. When I first did everything typing fast, I was always getting ^? from chronyc sources causing frustration.
• I found the chrony.service also had to be restarted on the client, only then did chrony sources -a -v about 30 seconds later report with a * = best instead of unusable. And chronyc tracking then did not have all zeros.