1.30.1 [ntpd] - not able to query

Tue Jul 2 12:42:08 UTC 2019

On 02/07/2019 14:36, Denys Vlasenko wrote:
> On Tue, Jul 2, 2019 at 12:03 PM <vtolkm at googlemail.com> wrote:
>> On 02/07/2019 11:26, Denys Vlasenko wrote:
>>> On Mon, Jul 1, 2019 at 3:09 PM <vtolkm at googlemail.com> wrote:
>>>> On 01/07/2019 12:51, Denys Vlasenko wrote:
>>>>> On Sat, Jun 29, 2019 at 4:12 PM <vtolkm at googlemail.com> wrote:
>>>>>> ntpd appears to be up and running/listening
>>>>>>
>>>>>> ss -tulpn | grep 123
>>>>>> udp   UNCONN 0  0    *:123   *:*  users:(("ntpd",pid=7589,fd=3))
>>>>>>
>>>>>> However, querying the server appears not working, as if queries being
>>>>>> refused and thus wondering what could be causing this, let alone
>>>>>> resolving it?
>>>>> Crank up log verbosity, it will tell you:
>>>>>
>>>>> $ ntpd --help
>>>>> BusyBox v1.31.0 (2019-06-10 12:10:11 CEST) multi-call binary.
>>>>>
>>>>> Usage: ntpd [-dnqNwl] [-I IFACE] [-S PROG] [-k KEYFILE] [-p [keyno:N:]PEER]...
>>>>>
>>>>> NTP client/server
>>>>>
>>>>>     -d    Verbose (may be repeated)
>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>     -n    Do not daemonize
>>>>>     -q    Quit after clock is set
>>>>>     -N    Run at high priority
>>>>>     -w    Do not set time (only query peers), implies -n
>>>>>     -S PROG    Run PROG after stepping time, stratum change, and every 11 min
>>>>>     -k FILE    Key file (ntp.keys compatible)
>>>>>     -p [keyno:NUM:]PEER
>>>>>         Obtain time from PEER (may be repeated)
>>>>>         Use key NUM for authentication
>>>>>     -l    Also run as server on port 123
>>>>>     -I IFACE Bind server to IFACE, implies -l
>>>> ran > /sbin/ntpd -nNlSddddp 1.openwrt.pool.ntp.org  < and then
>>> In this form, "ddddp" is the PROG parameter of the -S option.
>>> "1.openwrt.pool.ntp.org gets" ignored, as ntpd takes no args.
>>> (I'll add code to abort if unexpectedly, args are given).
>>> Try:
>>> ntpd -nNldddd -p 1.openwrt.pool.ntp.org
>> I am afraid the outcome, as described in my previous message, is the
>> same however for all client queries being made to the server (see bottom
>> for ntpq -p)
>>
>> It is as if the server is emulating the behaviour of a fully fledged
>> ntpd daemon when set to
>>
>> restrict source notrap nomodify noquery
>>
>> I would not know whether any sort of compiling flags could play into
>> that, that is when compiling ntpd into busybox and then busybox being
>> compiled by downstream.
>>
>> For the latter busybox source repo
>> https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=package/utils/busybox;h=1afd34d34e837107ea5ae3ed88dd986ce7fb2a96;hb=refs/heads/openwrt-19.07
>>
>> ------------------------
>> ntpd: '1.openwrt.pool.ntp.org' is 131.234.137.64
>> ntpd: sending query to 131.234.137.64
>> ntpd: reply from 131.234.137.64: offset:-0.055474 delay:0.018320
>> status:0x24 strat:1 refid:0x00464344 rootdelay:0.000000 reach:0x01
>> ntpd: no valid datapoints, no peer selected
>> ntpd: poll:1s sockets:1 interval:1s
>> ntpd: sending query to 131.234.137.64
>> ntpd: reply from 131.234.137.64: offset:-0.055564 delay:0.018381
>> status:0x24 strat:1 refid:0x00464344 rootdelay:0.000000 reach:0x03
>> ntpd: poll:1s sockets:1 interval:1s
>> ntpd: sending query to 131.234.137.64
>> ntpd: reply from 131.234.137.64: offset:-0.052473 delay:0.024619
>> status:0x24 strat:1 refid:0x00464344 rootdelay:0.000000 reach:0x07
>> ntpd: update from:131.234.137.64 offset:-0.052473 delay:0.024619
>> jitter:0.024111 clock drift:+182.593ppm tc:4
>> ntpd: poll:2s sockets:1 interval:1s
>> ntpd: sending query to 131.234.137.64
>> ntpd: reply from 131.234.137.64: offset:-0.051623 delay:0.024598
>> status:0x24 strat:1 refid:0x00464344 rootdelay:0.000000 reach:0x0f
>> ntpd: update from:131.234.137.64 offset:-0.051623 delay:0.024598
>> jitter:0.020860 clock drift:+182.593ppm tc:4
>> ntpd: poll:2s sockets:1 interval:1s
>> ntpd: sending query to 131.234.137.64
>> ntpd: reply from 131.234.137.64: offset:-0.050299 delay:0.024645
>> status:0x24 strat:1 refid:0x00464344 rootdelay:0.000000 reach:0x1f
>> ntpd: update from:131.234.137.64 offset:-0.050299 delay:0.024645
>> jitter:0.018066 clock drift:+182.593ppm tc:4
>> ntpd: poll:33s sockets:1 interval:32s
>> ntpd: malformed packet received from ::1: size 12
> Yes, here ntpq sends a packet with m_status of 0x16,
> which is NTPv2, "reserved1" mode (6).
>
> Probably described here:
> https://docs.ntpsec.org/latest/mode6.html
>
> and in this case, it is probably used to get peer list.
>
> busybox does not understand these extensions.
>
>
>> ntpd: poll:19s sockets:1 interval:32s
>> ntpd: malformed packet received from ::1: size 12
>> ntpd: poll:14s sockets:1 interval:32s

It is like a bug that can be fixed?
https://bugs.busybox.net/show_bug.cgi?id=12001

Or won't fix and the ntpd implementation in busybox is not suited to act
as server?