From Newsgroup: comp.protocols.time.ntp

--000000000000ee258106398465d0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you, Martin. That's it! The 'restrict limited' setting was
enabled, and that was the cause.

Steven, I've attached the dump, though I believe we've found the root
cause. Anyway, thank you too!

--
Peter.



On Wed, Jul 9, 2025 at 4:05=E2=80=AFPM Martin Burnicki <questions@lists.ntp= .org> wrote:

Hi Peter,

stratum 0 in a network packet is possibly displayed as stratum 16, and
it's an indicator for a Kiss-o'-Death (KoD) packet.

A server can send KoD packets if rate limits have been configured at the server and a client polls the server too often.

Such packets should also have something like "RATE" as a refid, but the
refid in your packet trace is only displayed as "(unspec)", so we can't
see the real contents of the refid field.

Regards,

Martin

Peter Volkov wrote:

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), precis=

ion 0

Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (un=

spec)

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: (un=

spec)

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 2=E2=80=933, and good reach =

(377):

ntpq> pe
remote refid st t when poll reach delay offset=

jitter

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

-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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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=3D0 status=3D0615 leap_none, sync_ntp, 1 event, clock_sync, version=3D"ntpd 4.2.8p17@1.4004-o Sun Apr 14 17:08:41 UTC 2024 (1)", processor=3D"x86_64", system=3D"Linux/6.12.31", leap=3D00, stratum=3D3, precision=3D-24, rootdelay=3D84.000, rootdisp=3D42.497, refid=3D176.108=

.64.46,

reftime=3Dec18df02.e7f4a192 Wed, Jul 9 2025 12:28:50.906, clock=3Dec18e095.7cf33ecf Wed, Jul 9 2025 12:35:33.488, peer=3D59041,=

tc=3D6,

mintc=3D3, offset=3D+7.088290, frequency=3D-18.999, sys_jitter=3D9.1608=

73,

clk_jitter=3D21.942, clk_wander=3D0.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.

--
Martin Burnicki

Senior Software Engineer

Email: martin.burnicki@meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

MEINBERG Funkuhren GmbH & Co. KG
Lange Wand 9
31812 Bad Pyrmont, Germany

Registry Court: Amtsgericht Hannover 17 HRA 100322
Managing Directors: Natalie Meinberg, Daniel Boldt, Andre Hartmann,
Heiko Gerstung

Websites: https://www.meinberg.de https://www.meinbergglobal.com

Meinberg - The Synchronization Experts.

--000000000000ee258106398465d0
Content-Type: application/octet-stream; name="ntpd.dump"
Content-Disposition: attachment; filename="ntpd.dump" Content-Transfer-Encoding: base64
Content-ID: <f_mcwdid7d0>
X-Attachment-Id: f_mcwdid7d0

1MOyoQIABAAAAAAAAAAAAAAABAABAAAAunNuaAnPDABaAAAAWgAAAP5rd0uM5B6FueR9xggARQAA TFJhQAA+EdndCv79ZAr+/QGSDwB7ADhBkRsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAALpzbmhXzwwAWgAAAFoAAAAehbnkfcb+a3dLjOQIAEW4AEzxi0AAQBE3 +wr+/QEK/v1kAHuSDwA4EKwcAgPoAAAIHwAABQtQ8QBI7BjyMjyLA/kAAAAAAAAAAOwY8jrW5SUH 7BjyOtbpjhq6c25ou/INAFoAAABaAAAA/mt3S4zkHoW55H3GCABFAABMknpAAD4RmcQK/v1kCv79 AY6OAHsAOEUSGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA unNuaAHzDQBaAAAAWgAAAB6FueR9xv5rd0uM5AgARbgATPGaQABAETfsCv79AQr+/WQAe46OADgQ rNwAAwAAAAAAAAAAAFJBVEUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALpzbmgPdg4A WgAAAFoAAAD+a3dLjOQehbnkfcYIAEUAAEyGFEAAPhGmKgr+/WQK/v0BxeQAewA4DbwbAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8c25ohLgEAFoAAABaAAAA /mt3S4zkHoW55H3GCABFAABMU8RAAD4R2HoK/v1kCv79Ad2rAHsAOPX0GwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAv3NuaMHFAABaAAAAWgAAAP5rd0uM5B6F ueR9xggARQAATFVrQAA+EdbTCv79ZAr+/QGfOwB7ADg0ZRsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMFzbmi9vgAAWgAAAFoAAAD+a3dLjOQehbnkfcYIAEUA AEx5+EAAPhGyRgr+/WQK/v0BzdYAewA4BcobAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADDc25oE6gOAFoAAABaAAAA/mt3S4zkHoW55H3GCABFAABMWohAAD4R 0bYK/v1kCv79Aa3JAHsAOCXXGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAw3NuaDaoDgBaAAAAWgAAAB6FueR9xv5rd0uM5AgARbgATPe0QABAETHSCv79AQr+ /WQAe63JADgQrNwAAwAAAAAAAAAAAFJBVEUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA==
--000000000000ee258106398465d0--

--- Synchronet 3.21d-Linux NewsLink 1.2