On Tue, Jul 2, 2019 at 12:03 PM <[email protected]> wrote: > > On 02/07/2019 11:26, Denys Vlasenko wrote: > > On Mon, Jul 1, 2019 at 3:09 PM <[email protected]> wrote: > >> On 01/07/2019 12:51, Denys Vlasenko wrote: > >>> On Sat, Jun 29, 2019 at 4:12 PM <[email protected]> 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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
