On Tue, Jul 2, 2019 at 2:42 PM <[email protected]> wrote: > On 02/07/2019 14:36, Denys Vlasenko wrote: > > 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 > > It is like a bug that can be fixed? > https://bugs.busybox.net/show_bug.cgi?id=12001
Sure, send patches. > 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. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
