NTP not syncing with clients

Gertjan · Sep 28, 2020, 8:52 AM

Not related :
This :

is not needed as they already (hidden ;) ) exist as soon as you activate a DHCP server on that interface.
This explains the leading 0/0.

stephenw10 · Sep 28, 2020, 11:18 AM

@Impatient said in NTP not syncing with clients:

Why do you have an o after your 0. us.pool.ntp it should be 0.us.pool.ntp.org

It's just the ntp output truncating it. You can see the actual urls are correct in the settings. Plus it's actually pulling IPs from the pool to connect to.

Steve

Yo5hi · Sep 29, 2020, 1:11 PM

@Gertjan Yep, that was just a residual sanity check. Removed it now.

@stephenw10 Yeah, it's pulling IPs correctly from the pool and looks to be properly synchronizing the time, from the looks of the NTP service status page (screenshot above).

Any idea why the NTP service will only send a valid timestamp after the initial request, and then no longer after that?

I noticed that the client request looks different (e.g. Peer polling interval, Leap indicator) after the 1st request, but that may be how Wireshark is parsing the data:

1st request:

Subsequent requests:

With NTP, is the client supposed to send its current timestamp with the request? The client, on boot, would have a timestamp of zero (so 1970), so is there something going on with the NTP service giving a null timestamp because the client's timestamp is substantially offset?

stephenw10 · Sep 29, 2020, 11:16 AM

Hmm, not really I'm afraid. ntpd is a fickle beast!

If you set the client time/date manually to something close to the real time does it then sync?
I have seen clients that did that before.

Steve

Gertjan · Sep 29, 2020, 1:12 PM

@Yo5hi said in NTP not syncing with clients:

The client, on boot, would have a timestamp of zero (so 1970)

The local clock is dead ?
IMHO, ntp syncs to correct small differences. Not decades. It would take centuries to bridge such a gap - NTP corrects using small portions.

JKnott · Sep 29, 2020, 2:42 PM

@Gertjan said in NTP not syncing with clients:

The local clock is dead ?

Or more likely the CMOS battery. That's very common on older computers.

johnpoz · Sep 29, 2020, 3:52 PM

@Yo5hi said in NTP not syncing with clients:

With NTP, is the client supposed to send its current timestamp with the request?

Yes..

here is my client starting its sync process..

🔒 Log in to view

You can see its currently not sync'd - will be back once it synced and show you the client packet

currently it has just stared

ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp.local.lan   .PPS.            1 u   62   64    7    0.623   -1.238   0.930

edit: ok now showing sync'd, notice the leap indicator went away..and showing reach of 377, and have * next to the server

ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp.local.lan   .PPS.            1 u    5   64  377    0.632   +0.357   0.325

🔒 Log in to view

I would really suggest if you can just run the ntp client on it, so you can get lots of info of what is going on with just the ntpq command

JKnott · Sep 29, 2020, 6:51 PM

@johnpoz said in NTP not syncing with clients:

I would really suggest if you can just run the ntp client on it, so you can get lots of info of what is going on with just the ntpq command

One thing you have to watch for, in the name of security bogus times are sometimes used. However, they apparently don't cause problems.

Check through this capture to see some examples of those bogus times.

NTP.pcapng

Yo5hi · Sep 30, 2020, 4:43 AM

I just manually set the time on the IoT device (it doesn't have a RTC on board or a CMOS) and had it try to sync with the NTP service and got the same behavior. From the packets, it appears that the NTP service on pfSense is throwing some sort of error in the "Reference ID" field though (detailed below).

Client's first sync request (it doesn't put its current timestamp in, apparently, even though I set it manually before the sync):
🔒 Log in to view

Server's response (looks correct):
🔒 Log in to view

Client makes another request 5 seconds later with some differences to 1st request for some reason:
🔒 Log in to view

Server response, but now has "Unidentified reference source 'RATE'" and reports and invalid stratum of zero:
🔒 Log in to view

I don't see anything in the System Logs for the NTP service that's an error or anything, and the NTP monitoring data looks fine (within 7ms over the last 24hrs, if I am interpreting it correctly):

🔒 Log in to view

What does "Unidentified reference source 'RATE'" mean?

Yo5hi · Sep 30, 2020, 5:09 AM

Ok, I had a feeling that it was something to do with rate limiting, or the rate that the client is trying to poll the server, so I slowed down the frequency that the client performs retries to sync the clock from every 5 seconds to every 20 seconds and it reliably syncs now after 3-4 attempts.

So it appears that there's some sort of rate limiting or something about NTP that doesn't allow clients to poll it more often than 20 secs or so.

So it's working now - I just wish that my devices don't have to wait 60-80 secs on boot to sync.

Thanks for the help, everyone.

Gertjan · Sep 30, 2020, 6:06 AM

@Yo5hi said in NTP not syncing with clients:

I just wish that my devices don't have to wait 60-80 secs on boot to sync.

So, it boots, asks the time ones - got it, and sets it's own clock, and wants be sure and checks up a second time. It pauses the entire system while waiting for that ??

No RTC, bad NTP implementation ... hummm.