Otto Moerbeek <[email protected]> wrote: > On Wed, Jan 05, 2022 at 11:45:36AM +0100, Matthias Schmidt wrote: > > > >Synopsis: ntpd constraint validation shows timestamp from 1899 > > >Environment: > > System : OpenBSD 7.0 > > Details : OpenBSD 7.0-current (GENERIC.MP) #216: Mon Jan 3 > > 16:04:47 MST 2022 > > > > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > >Description: > > > > Yesterday, the following log message from OpenNTPD appeared for the first > > and > > only time in my logs: > > > > Jan 4 19:35:04 sigma ntpd[72304]: maximum length exceeded > > Jan 4 19:35:04 sigma ntpd[72304]: tls certificate not yet valid: 9.9.9.9 > > (9.9.9.9): not before 2021-07-27 00:00:00 UTC, now 1899-12-31 00:00:00 UTC > > > > It seems like some hiccup during constraint TLS certificate validation. > > > > Here are the log messages of the last two minutes BEFORE the lines above > > appeared: > > > > Jan 4 19:33:08 sigma ntpd[65131]: peer 134.76.249.201 now invalid > > Jan 4 19:33:16 sigma ntpd[65131]: peer 141.2.22.74 now invalid > > Jan 4 19:33:20 sigma ntpd[2066]: adjusting local clock by 0.468916s > > Jan 4 19:33:20 sigma ntpd[65131]: clock is now unsynced > > Jan 4 19:34:04 sigma ntpd[65131]: peer 134.76.249.201 now valid > > Jan 4 19:34:22 sigma ntpd[2066]: adjusting local clock by 0.153686s > > Jan 4 19:34:26 sigma ntpd[65131]: peer 134.76.249.201 now invalid > > Jan 4 19:34:54 sigma ntpd[65131]: clock is now synced > > Jan 4 19:34:54 sigma ntpd[65131]: constraint reply from 82.165.229.152: > > offset -0.891146 > > Jan 4 19:35:00 sigma ntpd[65131]: constraint reply from 82.165.229.87: > > offset -0.776174 > > > > The next time 9.9.9.9 appeared in the logs was around 15 minutes later: > > > > Jan 4 19:50:43 sigma ntpd[65131]: constraint reply from 2620:fe::fe: > > offset -0.848819 > > Jan 4 19:50:43 sigma ntpd[65131]: constraint reply from 9.9.9.9: offset > > -0.872381 > > The 1899 time is the time taken from the http reply headers received. > I suppose quad9 had a hickup and sent garbage. Likely the strptime() > call in ntpd/constraint.c went wrong but did not return an error in > some way. The answer to this contraint request was rejected. Other > constraints worked apparantly and after a while quad9 was reporting a > correct time in its http reply headers.
So in other words, the code worked precisely as intended. The constraint timestamp was not consumed, and the alert is simply amusing.
