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;
>
