Re: ntpd constraint validation shows timestamp from 1899
On 2022-01-07 08:02 +01, Otto Moerbeek wrote:
> On Thu, Jan 06, 2022 at 04:02:20PM +0100, Florian Obser wrote:
>
>> On 2022-01-06 08:44 +01, Otto Moerbeek wrote:
>> > On Thu, Jan 06, 2022 at 08:38:37AM +0100, Otto Moerbeek wrote:
>> >> Looking at the loop again and seeing the "maximum length exceeded" I
>> >> think what has happened is that the loop exited without reading the
>> >> Date: line and so no call to strptime() happened at all.
>> >>
>> >> The code could be improved a bit by returning -1 in that case.
>> >>
>> >> -Otto
>> >>
>> >
>> > Like this
>> >
>>
>> OK florian
>>
>> p.s.: I have to say I find this code rather convoluted, figuring out
>> that this is actually correct took me way too long. (httpsdate is
>> allocated with calloc one function up and one to the left and nothing
>> touches tls_tm in between).
>
> I thought about introducing a local var that gets set on a succesful
> strptime() call but decided against that as their *should* only be one
> source for it to be filled in. As for the
>
> allocate()
> call some functions and cleanup() in the last
>
> I like this structure better:
>
> allocate()
> call some deep functions
> cleanup()
>
> Dunno if the current code allows restructuring in this way.
Yeah, I undestand this is just how you found it...
Maybe someday someone finds the time and energy to shine this turd a bit
more. Heck, might even be me ;)
>
> -Otto
>
>>
>> > Index: constraint.c
>> > ===
>> > RCS file: /cvs/src/usr.sbin/ntpd/constraint.c,v
>> > retrieving revision 1.52
>> > diff -u -p -r1.52 constraint.c
>> > --- constraint.c 16 Jul 2021 13:59:10 - 1.52
>> > +++ constraint.c 6 Jan 2022 07:43:52 -
>> > @@ -1019,7 +1019,7 @@ httpsdate_request(struct httpsdate *http
>> >>tls_tm) == NULL) {
>> >log_warnx("unsupported date format");
>> >free(line);
>> > - return (-1);
>> > + goto fail;
>> >}
>> >
>> >free(line);
>> > @@ -1027,6 +1027,8 @@ httpsdate_request(struct httpsdate *http
>> > next:
>> >free(line);
>> >}
>> > + if (httpsdate->tls_tm.tm_year == 0)
>> > + goto fail;
>> >
>> >/*
>> > * Now manually check the validity of the certificate presented in the
>> >
>>
>> --
>> I'm not entirely sure you are real.
>>
--
I'm not entirely sure you are real.
Re: ntpd constraint validation shows timestamp from 1899
On Thu, Jan 06, 2022 at 04:02:20PM +0100, Florian Obser wrote:
> On 2022-01-06 08:44 +01, Otto Moerbeek wrote:
> > On Thu, Jan 06, 2022 at 08:38:37AM +0100, Otto Moerbeek wrote:
> >> Looking at the loop again and seeing the "maximum length exceeded" I
> >> think what has happened is that the loop exited without reading the
> >> Date: line and so no call to strptime() happened at all.
> >>
> >> The code could be improved a bit by returning -1 in that case.
> >>
> >>-Otto
> >>
> >
> > Like this
> >
>
> OK florian
>
> p.s.: I have to say I find this code rather convoluted, figuring out
> that this is actually correct took me way too long. (httpsdate is
> allocated with calloc one function up and one to the left and nothing
> touches tls_tm in between).
I thought about introducing a local var that gets set on a succesful
strptime() call but decided against that as their *should* only be one
source for it to be filled in. As for the
allocate()
call some functions and cleanup() in the last
I like this structure better:
allocate()
call some deep functions
cleanup()
Dunno if the current code allows restructuring in this way.
-Otto
>
> > Index: constraint.c
> > ===
> > RCS file: /cvs/src/usr.sbin/ntpd/constraint.c,v
> > retrieving revision 1.52
> > diff -u -p -r1.52 constraint.c
> > --- constraint.c16 Jul 2021 13:59:10 - 1.52
> > +++ constraint.c6 Jan 2022 07:43:52 -
> > @@ -1019,7 +1019,7 @@ httpsdate_request(struct httpsdate *http
> > >tls_tm) == NULL) {
> > log_warnx("unsupported date format");
> > free(line);
> > - return (-1);
> > + goto fail;
> > }
> >
> > free(line);
> > @@ -1027,6 +1027,8 @@ httpsdate_request(struct httpsdate *http
> > next:
> > free(line);
> > }
> > + if (httpsdate->tls_tm.tm_year == 0)
> > + goto fail;
> >
> > /*
> > * Now manually check the validity of the certificate presented in the
> >
>
> --
> I'm not entirely sure you are real.
>
Re: ntpd constraint validation shows timestamp from 1899
On 2022-01-06 08:44 +01, Otto Moerbeek wrote:
> On Thu, Jan 06, 2022 at 08:38:37AM +0100, Otto Moerbeek wrote:
>> Looking at the loop again and seeing the "maximum length exceeded" I
>> think what has happened is that the loop exited without reading the
>> Date: line and so no call to strptime() happened at all.
>>
>> The code could be improved a bit by returning -1 in that case.
>>
>> -Otto
>>
>
> Like this
>
OK florian
p.s.: I have to say I find this code rather convoluted, figuring out
that this is actually correct took me way too long. (httpsdate is
allocated with calloc one function up and one to the left and nothing
touches tls_tm in between).
> Index: constraint.c
> ===
> RCS file: /cvs/src/usr.sbin/ntpd/constraint.c,v
> retrieving revision 1.52
> diff -u -p -r1.52 constraint.c
> --- constraint.c 16 Jul 2021 13:59:10 - 1.52
> +++ constraint.c 6 Jan 2022 07:43:52 -
> @@ -1019,7 +1019,7 @@ httpsdate_request(struct httpsdate *http
> >tls_tm) == NULL) {
> log_warnx("unsupported date format");
> free(line);
> - return (-1);
> + goto fail;
> }
>
> free(line);
> @@ -1027,6 +1027,8 @@ httpsdate_request(struct httpsdate *http
> next:
> free(line);
> }
> + if (httpsdate->tls_tm.tm_year == 0)
> + goto fail;
>
> /*
>* Now manually check the validity of the certificate presented in the
>
--
I'm not entirely sure you are real.
Re: ntpd constraint validation shows timestamp from 1899
On Thu, Jan 06, 2022 at 08:38:37AM +0100, Otto Moerbeek wrote:
> On Wed, Jan 05, 2022 at 02:19:28PM -0700, Theo de Raadt wrote:
>
> > Otto Moerbeek 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
> > > >
> > > > dera...@amd64.openbsd.org:/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.
> >
>
> Yep.
>
> Looking at the loop again and seeing the "maximum length exceeded" I
> think what has happened is that the loop exited without reading the
> Date: line and so no call to strptime() happened at all.
>
> The code could be improved a bit by returning -1 in that case.
>
> -Otto
>
Like this
Index: constraint.c
===
RCS file: /cvs/src/usr.sbin/ntpd/constraint.c,v
retrieving revision 1.52
diff -u -p -r1.52 constraint.c
--- constraint.c16 Jul 2021 13:59:10 - 1.52
+++ constraint.c6 Jan 2022 07:43:52 -
@@ -1019,7 +1019,7 @@ httpsdate_request(struct httpsdate *http
>tls_tm) == NULL) {
log_warnx("unsupported date format");
free(line);
- return (-1);
+ goto fail;
}
free(line);
@@ -1027,6 +1027,8 @@ httpsdate_request(struct httpsdate *http
next:
free(line);
}
+ if (httpsdate->tls_tm.tm_year == 0)
+ goto fail;
/*
* Now manually check the validity of the certificate presented in the
Re: ntpd constraint validation shows timestamp from 1899
On Wed, Jan 05, 2022 at 02:19:28PM -0700, Theo de Raadt wrote: > Otto Moerbeek 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 > > > > > > dera...@amd64.openbsd.org:/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. > Yep. Looking at the loop again and seeing the "maximum length exceeded" I think what has happened is that the loop exited without reading the Date: line and so no call to strptime() happened at all. The code could be improved a bit by returning -1 in that case. -Otto
Re: ntpd constraint validation shows timestamp from 1899
Otto Moerbeek 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 > > > > dera...@amd64.openbsd.org:/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.
Re: ntpd constraint validation shows timestamp from 1899
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 > > dera...@amd64.openbsd.org:/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. -Otto > > I attached the full ntpd log in case that helps. > > Here's my ntpd.conf > > servers time.uni-paderborn.de > servers ntp.1und1.de > server ntp1.uni-ulm.de > server ntp2.uni-ulm.de > server ntp.uni-osnabrueck.de > server times.tubit.tu-berlin.de > > constraint from "9.9.9.9" # quad9 v4 without DNS > constraint from "2620:fe::fe" # quad9 v6 without DNS > constraints from "gmx.de" > > >How-To-Repeat: > > Sorry, no idea. Happened for the first time. > > >Fix: > > Unknown as well. > > dmesg: > OpenBSD 7.0-current (GENERIC.MP) #216: Mon Jan 3 16:04:47 MST 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 12765257728 (12173MB) > avail mem = 12362371072 (11789MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9cbfd000 (65 entries) > bios0: vendor LENOVO version "JBET73WW (1.37 )" date 08/14/2019 > bios0: LENOVO 20BX0049GE > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT > SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI DMAR > acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpiec0 at acpi0 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.44 MHz, 06-3d-04 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > cpu1 at mainbus0: apid 1 (application
ntpd constraint validation shows timestamp from 1899
>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 dera...@amd64.openbsd.org:/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 I attached the full ntpd log in case that helps. Here's my ntpd.conf servers time.uni-paderborn.de servers ntp.1und1.de server ntp1.uni-ulm.de server ntp2.uni-ulm.de server ntp.uni-osnabrueck.de server times.tubit.tu-berlin.de constraint from "9.9.9.9" # quad9 v4 without DNS constraint from "2620:fe::fe" # quad9 v6 without DNS constraints from "gmx.de" >How-To-Repeat: Sorry, no idea. Happened for the first time. >Fix: Unknown as well. dmesg: OpenBSD 7.0-current (GENERIC.MP) #216: Mon Jan 3 16:04:47 MST 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 12765257728 (12173MB) avail mem = 12362371072 (11789MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9cbfd000 (65 entries) bios0: vendor LENOVO version "JBET73WW (1.37 )" date 08/14/2019 bios0: LENOVO 20BX0049GE acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI DMAR acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.44 MHz, 06-3d-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.15 MHz, 06-3d-04 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.15 MHz, 06-3d-04 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PC
