Magnus Kroken <mkro...@gmail.com> wrote: > On 21.08.2017 16:34, Karl Palsson wrote: > > on master, even with the ntpd patch for busybox applied. > > # ntpdate -q localhost > > server ::1, stratum 0, offset 0.000000, delay 0.00000 > > server 127.0.0.1, stratum 0, offset 0.000000, delay 0.00000 21 > > Aug 14:26:24 ntpdate[1392]: no server suitable for > > synchronization found > > # echo $? > > 1 > > # ntpd -w -d -p localhost > > ntpd: sending query to 127.0.0.1 > > ntpd: reply from 127.0.0.1: peer is unsynced > > ntpd: sending query to 127.0.0.1 > > Thanks for the clarification. Running ntpd like before (-p > bad.example.org -p ntp.uio.no), LEDE master with Busybox 1.27.2 > does seem to work: > > root@LEDE:~# ntpdate -q ::1 > server ::1, stratum 3, offset 0.000028, delay 0.02777 > 23 Aug 19:12:55 ntpdate[5416]: adjust time server ::1 offset > 0.000028 sec root@LEDE:~# echo $? 0 > > I also tested against my OpenWrt 15.05 VM and the current LEDE > x86_64 snapshot (r4723), and they both give the expected output > as you describe (OpenWrt similar to above, LEDE fails). > > Note that my patch in Patchwork only updates to Busybox 1.27.1, > I will send the 1.27.2 patch shortly, after rebasing and > testing it. >
For a followup, on master, with busybox 1.27.2, busybox ntpd will sync with bad servers in the list, but only if they're not _first_ Further, "bad.example.org" won't count as "bad" for the purpose of these tests. Someone (presumably dnsmasq?) is responding instantly with failures there. Try something like /usr/sbin/ntpd -n -N -d -l -S /usr/sbin/ntpd-hotplug -p bad1.n otexample.notorg -p bad2.notexample.notorg -p good.working.server.here.com It appears that the dns resolution times out, and is ordered in such a way that busybox sends a request, and even though it gets a reply "instantly" it doesn't actually process it for several seconds. At that point, it .. fails? to process properly, and so just continues sending requests, getting replies, and never stepping or setting the stratum. (And hence, my tests with ntpdate -q never succeeded) I've filed https://bugs.busybox.net/show_bug.cgi?id=10466 with busybox for this. It's actually only a bother for me in my development environment, where the *.pool.ntp.org addresses aren't resolveable Sincerely, Karl Palsson
signature.html
Description: OpenPGP Digital Signature
_______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
