1.30.1 [ntpd] - not able to query

[Denys Vlasenko]

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