1.30.1 [ntpd] - not able to query

Tue Jul 2 13:20:00 UTC 2019

On 02/07/2019 15:07, Denys Vlasenko wrote:
> On Tue, Jul 2, 2019 at 2:42 PM <vtolkm at googlemail.com> wrote:
>> 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
> Sure, send patches.

I would if I had coding skills. As a end user it is however vital to
have confidence that the ntpd implementation is actually serving queries.

>
>> Or won't fix and the ntpd implementation in busybox is not suited to act
>> as server?
> It does act as server - you can query time from it and syncronize with it.
> Support of mode6 requests is not mandatory for server implementation.

I am afraid that is rather questionable considering that none of the
querying tools (below) imply that queries are actually being served.
Do you reckon that all those querying apps are reliant on NTPv2 mode 6
then, none producing an output from ntpd -dddd?

Started thread started because I am concerned that it actually serves
queries, considering:

# ntpdate localhost
no server suitable for synchronization found

# ntpdc -lnps
localhost: timed out, nothing received
***Request timed out
localhost: timed out, nothing received
***Request timed out
localhost: timed out, nothing received
***Request timed out

# ntptime -r
ntp_gettime() returns code 5 (ERROR)
ntp_adjtime() returns code 5 (ERROR)