[Bug 13056] New: ntpd: client msg refid incorrect

bugzilla at busybox.net bugzilla at busybox.net
Thu Jul 2 16:40:02 UTC 2020


            Bug ID: 13056
           Summary: ntpd: client msg refid incorrect
           Product: Busybox
           Version: 1.30.x
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Networking
          Assignee: unassigned at busybox.net
          Reporter: rfrankla at yahoo.com
                CC: busybox-cvs at busybox.net
  Target Milestone: ---

Currently the busybox ntpd, in server mode, returns the refid of the currently
selected upstream host in reply messages.

This is incorrect. It should return the currently selected reference server's
own id as a reference.
i.e. the reference servers own IP address converted into a 32bit unsigned int 
(or for IPv6; first four bytes of the (binary) md5 digest of the IPv6 address)


my home router
ntp peer -> (cdns01.plus.net) refid: C342F10A (->
-> ntp2.linx.net)

my home laptop
ntp peer -> SHOULD BE refid: D49F0D31 ( -> ->
cdns01.plus.net )

The busybox ntpd is sending a refid C342F10A to my laptop, this is incorrect.
Other ntp server software (chrony.tuxfamily.org and ntp.org) do send the
correct D49F0D31.

The purpose of refid is to prevent timing loops:

Above stratum 1 (secondary servers and clients): this is the
reference identifier of the server and can be used to detect timing
The purpose of the REFID is to prevent a one-degree "timing loop": where if A
has several timing sources that include B, if B decides to get its time from A,
then A should not then decide to get its time from B. The REFID is therefore a
vital core-component of the base NTP packet.

(This is a better, complete, explanation of how the refid is used).

I discovered this in Openwrt 19.07.3 
on... mvebu cortexa9 linksys_wrt1200ac

You are receiving this mail because:
You are on the CC list for the bug.

More information about the busybox-cvs mailing list