On Thu, Nov 30, 2023 at 11:43:12AM +0100, Otto Moerbeek wrote: > On Wed, Nov 29, 2023 at 07:43:57PM +0100, Otto Moerbeek wrote: > > > On Wed, Nov 29, 2023 at 11:57:15AM +0100, Otto Moerbeek wrote: > > > > > On Wed, Nov 29, 2023 at 08:49:55AM +0100, Otto Moerbeek wrote: > > > > > > > On Tue, Nov 28, 2023 at 04:19:07PM +0100, Paul de Weerd wrote: > > > > > > > > > Hi all, > > > > > > > > > > I have a few APU's I'm using to experiment with some stuff. I found > > > > > all > > > > > of them unable to sync with NTP because they don't have IPv4 > > > > > connectivity to the outside world. > > > > > > > > > > Digging a bit deeper, it turns out that v6 is only configured after > > > > > ntpd is started. This means the constraints cannot be reached (ntpd > > > > > logs "constraints configured but none available"). Even if v6 becomes > > > > > available (shortly after) ntpd is started, ntpd still refuses to try > > > > > to connect to the constraints over IPv6. > > > > > > > > > > Simply restarting ntpd when an IPv6 address is configured makes > > > > > everything go again: the constraint servers can be reached, so those > > > > > are checked, and then the regular NTP servers also work fine. > > > > > > > > > > Address configuration is dynamic: > > > > > > > > > > --- cat /etc/hostname.em0 -------------------------------------------- > > > > > up > > > > > inet autoconf > > > > > inet6 autoconf > > > > > ---------------------------------------------------------------------- > > > > > > > > > > I have confirmed the behaviour by removing all config from the > > > > > interface, stopping ntpd and then bringing up a v4 address (ifconfig > > > > > em0 inet autoconf), starting ntpd and bringing up a v6 address > > > > > (ifconfig em0 inet6 autoconf). ntpd never connects to the constraint > > > > > servers, despite having a v6 address (and the constraint servers have > > > > > AAAA records, obviously). Again, restarting ntpd when a v6 address is > > > > > configured gets things going: constraint servers are reached just > > > > > fine, and time is adjusted according to NTP. > > > > > > > > > > Paul 'WEiRD' de Weerd > > > > > > > > I'll see if I can find the root cuase of this. > > > > > > > > -Otto > > > > > > > > > > > > > So I tried a couple of configs--all with a v6 address coming up late-- > > > with both no v4 at all and v4 but not working, but in all cases > > > (though it may take a while) the contrainst *did* use v6 addresses, > > > both for the hardcoded case and retrieved via DNS case. > > > > > > So I like to see your config and also -vv log files to figure out > > > what's different in your setup. > > > > > > -Otto > > > > > > > With your config detail i managed to reproduce. > > > > What is happening is that the initial constraint DNS info which does > > not include v6 info gets re-used. The diff below resets the constraint > > DNS info immediately after first use and then periodically (but only > > after all constraint queries have been done). For constraints we do no > > want to stick to a DNS resolve result too long anyway. > > > > For NTP peers it worked already, since they redo DNS after they cycled > > though the list of available addresses. > > > > I'm doing some more tests, but here's the diff I'm using. > > > > -Otto > > > > Updated diff, previous diff has the effect that conststraints would > continue to be requested. This one only does that for constraints that > did not reply. Also including a few nits. > > Please test, > > -Otto
Paul tested and is happy, I'd like to get a review. -Otto > > Index: constraint.c > =================================================================== > RCS file: /home/cvs/src/usr.sbin/ntpd/constraint.c,v > diff -u -p -r1.54 constraint.c > --- constraint.c 27 Nov 2022 13:19:00 -0000 1.54 > +++ constraint.c 30 Nov 2023 10:40:34 -0000 > @@ -554,7 +554,6 @@ constraint_close(u_int32_t id) > return (1); > } > > - /* Go on and try the next resolved address for this constraint */ > return (constraint_init(cstr)); > } > > @@ -927,7 +926,7 @@ httpsdate_init(const char *addr, const c > * version is based on our wallclock, which may well be inaccurate... > */ > if (!synced) { > - log_debug("constraints: skipping time in certificate > validation"); > + log_debug("constraints: using received time in certificate > validation"); > tls_config_insecure_noverifytime(httpsdate->tls_config); > } > > Index: ntp.c > =================================================================== > RCS file: /home/cvs/src/usr.sbin/ntpd/ntp.c,v > diff -u -p -r1.170 ntp.c > --- ntp.c 27 Nov 2022 13:19:00 -0000 1.170 > +++ ntp.c 30 Nov 2023 10:40:34 -0000 > @@ -75,6 +75,7 @@ ntp_main(struct ntpd_conf *nconf, struct > int nullfd, pipe_dns[2], idx_clients; > int ctls; > int fd_ctl; > + int clear_cdns; > u_int pfd_elms = 0, idx2peer_elms = 0; > u_int listener_cnt, new_cnt, sent_cnt, trial_cnt; > u_int ctl_cnt; > @@ -89,7 +90,7 @@ ntp_main(struct ntpd_conf *nconf, struct > struct stat stb; > struct ctl_conn *cc; > time_t nextaction, last_sensor_scan = 0, now; > - time_t last_action = 0, interval; > + time_t last_action = 0, interval, last_cdns_reset = 0; > void *newp; > > if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, PF_UNSPEC, > @@ -326,9 +327,11 @@ ntp_main(struct ntpd_conf *nconf, struct > (peer_cnt == 0 && sensors_cnt == 0))) > priv_settime(0, "no valid peers configured"); > > + clear_cdns = 1; > TAILQ_FOREACH(cstr, &conf->constraints, entry) { > - if (constraint_query(cstr, conf->status.synced) == -1) > - continue; > + constraint_query(cstr, conf->status.synced); > + if (cstr->state <= STATE_QUERY_SENT) > + clear_cdns = 0; > } > > if (ibuf_main->w.queued > 0) > @@ -346,6 +349,13 @@ ntp_main(struct ntpd_conf *nconf, struct > ctls = i; > > now = getmonotime(); > + if (conf->constraint_median == 0 && clear_cdns && > + now - last_cdns_reset > CONSTRAINT_SCAN_INTERVAL) { > + log_debug("Reset constraint info"); > + constraint_reset(); > + last_cdns_reset = now; > + nextaction = now + CONSTRAINT_RETRY_INTERVAL; > + } > timeout = nextaction - now; > if (timeout < 0) > timeout = 0; >