1. Forum
  2. USENET
  3. comp.protocols.time.ntp

  • Re: ntpd returns Leap indicator: clock unsynchronized (192) intermittently - need troubleshooting advice

    From Peter Volkov@peter.volkov@gmail.com to Martin Burnicki on Wed Jul 9 19:53:00 2025
    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