From Newsgroup: comp.protocols.time.ntp
Hello,
Recently, our monitoring started alerting because the ntpd server intermittently returns the error Leap indicator: clock unsynchronized
(192).
Our monitor is a Python script (similar to this example
https://www.mattcrampton.com/blog/query_an_ntp_server_from_python/)
that queries the NTP server and checks the response time.
I captured packets with tcpdump and see that most responses return
correct time, but some return this unsynchronized leap indicator with
zero timestamps:
09:37:48.443219 IP (tos 0x0, ttl 62, id 6086, offset 0, flags [DF],
proto UDP (17), length 76)
10.254.253.100.34106 > 10.254.253.1.123: [udp sum ok] NTPv3,
Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 0.000000000
09:37:48.443280 IP (tos 0xb8, ttl 64, id 2192, offset 0, flags [DF],
proto UDP (17), length 76)
10.254.253.1.123 > 10.254.253.100.34106: [bad udp cksum 0x10ac ->
0xe3de!] NTPv3, Server, length 48
Leap indicator: clock unsynchronized (192), Stratum 0
(unspecified), poll 3 (8s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 0.000000000
Ntpd logs look normal, no obvious errors, and ntpq -p shows stable
peers with normal offsets (~7 ms), stratum 2rCo3, and good reach (377):
ntpq> pe
remote refid st t when poll reach delay offset jitter ============================================================================== -185.116.194.200 80.241.0.72 2 u 15 64 377 40.310 +25.548 3.463 *boris.esilnet.k 194.190.168.1 2 u 6 64 377 32.532 +6.037 2.112 +nntp.hoster.kz 80.241.0.72 2 u 9 64 377 43.705 +16.318 1.870 +time.cloudflare 10.199.8.4 3 u 11 64 377 23.630 +7.168 3.344 ntpq> as
ind assid status conf reach auth condition last_event cnt ===========================================================
1 59040 933a yes yes none outlier sys_peer 3
2 59041 966a yes yes none sys.peer sys_peer 6
3 59042 944a yes yes none candidate sys_peer 4
4 59043 941a yes yes none candidate sys_peer 1
ntpq> rv
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd
4.2.8p17@1.4004-o Sun Apr 14 17:08:41 UTC 2024 (1)", processor="x86_64", system="Linux/6.12.31", leap=00, stratum=3,
precision=-24, rootdelay=84.000, rootdisp=42.497, refid=176.108.64.46, reftime=ec18df02.e7f4a192 Wed, Jul 9 2025 12:28:50.906, clock=ec18e095.7cf33ecf Wed, Jul 9 2025 12:35:33.488, peer=59041, tc=6, mintc=3, offset=+7.088290, frequency=-18.999, sys_jitter=9.160873, clk_jitter=21.942, clk_wander=0.501
ntpdate against a public pool confirms time difference is just a few milliseconds.
The server time is correct and stable. Still, this leap unsynchronized
response appears occasionally.
What else should I check to understand why ntpd suddenly starts
returning this error? Any ideas what conditions cause this partial unsynchronized state? How to debug it further?
Thanks in advance.
--
Peter.
--- Synchronet 3.21a-Linux NewsLink 1.2