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 Or won't fix and the ntpd implementation in busybox is not suited to act as server? _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
