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: Kernel panic because AMD 5600XT GPU
On Wed, Jan 05, 2022 at 01:33:59PM -0500, fo...@dnmx.org wrote:
> Hello.
> I have installed OpenBSD a few times now, of course, latest 7.0 release, with
> FDE.
> Now, that was on literally every computer, but my main one. Now, I go to
> install it on my main computer - the beast..
> I have an AMD 5600XT GPU.
>
> I booted after a nice, successful, comfy install, and I get a kernel panic
> thing..
> I will write here what I can see on my screen (my keyboard doesn't work here
> for some reason). Unfortunately I am too dumb to figure out this without a
> mobile phone, but I think you'll get good information from this.
>
> So, after a FDE-unlock, blue text goes, goes, my speaker like turns on or
> some
> check goes by, then I get this:
Do you see this on first boot after install?
try either
boot -c (at boot prompt)
disable amdgpu*
quit
fw_update amdgpu
reboot
or a -current snapshot where the firmware is installed from
the installer
>
>
> ...
> drm:pid0:amdgpu_device_init *ERROR* amdgpu_device_ip_init failed
> drm:pid0:amdgpu_attackhook *ERROR* Fatal error during GPU init
> amdgpu_gem_force_release: stub
> Memory manager not clean during takedown.
> panic:pool_destroy: pool busy: still out: 30
> Stopped at db_enter+0x10: popq%rbp
> ID PIDUID PRFLAGS PFLAGS CPU COMMAND
> 384305 9453 0 0x14000 0x200 5 zerothread
> 335913 4065 0 0x14000 0x200 2 reaper
> * 0 0 0 0x1 0x200 1 swapper
> db_enter() at db_enter+0x10
> panic(81eb02ab) at panic+0xbf
> pool destroy(82297938) at pool_destroy+0x215
> drm_linux_exit() at drm_linux_exit+0x10
> drm_detach(80411000,0) at drm_detach+0x3e
> config_detach(80411000,0) at config_detach+0x142
> amdgpu_detach(803f9000,0) at amdgpu_detach+0xfd
> config_detach(803f9000,0) at config_detach+0x142
> amdgpu_attackhook(803f9000) at amdgpu_attackhook+0x2f0
> config_process_deferred_mountroot() at config_process_deferred_mountroot+0x6b
> main(0) at main+0x733
> end trace frame: 0x0, count: 4
> https://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports. Insufficient info makes it difficult to find and fix bugs.
> ddb{1}> (cannot type anything lol)
>
>
>
>
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 processor) > cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.15 MHz, 06-3d-04 > cpu1: >
Re: 7.0 install from install70.img no firmware for wifi (iwn-5000)
On Wed, Jan 05, 2022 at 03:11:47PM +0100, Marek Kozlowski wrote: > :-) > > On 1/5/22 11:42, Crystal Kolipe wrote: > > On Wed, Jan 05, 2022 at 09:12:48AM +0100, Marek Kozlowski wrote: > > > After I set up the ESSID and WPA-PSK the following message is displayed: > > > > > > iwn0: could not read firmware iwn-5000 (error 2) > > > > Your NIC requires firmware files which are available from: > > > > http://firmware.openbsd.org/firmware/ > > > > It's probably easiest to complete the install without setting it up, then > > install the firmware and configure the wireless adaptor manually afterwards. > > > > The iwn(4), and fw_update(1) manual pages have more relevant information. > > 1. Is it (missing firmware) intentional or is it a bug to be fixed? Intel wifi firmware cannot be distributed with the official installation media due to licensing conflicts. As a workaround, these firmware images are not distributed by OpenBSD, they are distributed by volunteers. Use the Ethernet interface (em0) during your install. Once you boot up the installed system firmware will be downloaded over Ethernet from one of the volunteer firmware mirrors. Once that has been done, wifi on iwn0 will work.
Re: 7.0 install from install70.img no firmware for wifi (iwn-5000)
On Wed, Jan 05, 2022 at 03:11:47PM +0100, Marek Kozlowski wrote: > 1. Is it (missing firmware) intentional or is it a bug to be fixed? The firmware cannot be distributed with the OpenBSD base system for licensing reasons. > 2. It informs that it cannot find formware - error 2... then it asks for > ESSID and a WPA passphrase for that interface..? I'm not sure if I > understand that idea... > > 3. Is there or isn't there any difference between installation with and > without working network connection? As you are using install70.img, you don't need a working network connection to complete the installation of the base system. All of the files you need are included in install70.img. > 4. Currently I have only Linux installed. I'm wondering what is the easiest > way of updating the install USB flash drive. If you really want to have the wireless NIC working during installation, you could manually download the firmware file from: http://firmware.openbsd.org/firmware/ and copy it to another USB flash drive. You can then exit to a shell in the installer, and mount the second flash drive on /etc/firmware/. However, it would be much easier to complete the installation first, then use fw_update with the -p option to install the firmware from a local copy that you have already downloaded separately.
Re: 7.0 install from install70.img no firmware for wifi (iwn-5000)
:-) On 1/5/22 11:42, Crystal Kolipe wrote: On Wed, Jan 05, 2022 at 09:12:48AM +0100, Marek Kozlowski wrote: After I set up the ESSID and WPA-PSK the following message is displayed: iwn0: could not read firmware iwn-5000 (error 2) Your NIC requires firmware files which are available from: http://firmware.openbsd.org/firmware/ It's probably easiest to complete the install without setting it up, then install the firmware and configure the wireless adaptor manually afterwards. The iwn(4), and fw_update(1) manual pages have more relevant information. 1. Is it (missing firmware) intentional or is it a bug to be fixed? 2. It informs that it cannot find formware - error 2... then it asks for ESSID and a WPA passphrase for that interface..? I'm not sure if I understand that idea... 3. Is there or isn't there any difference between installation with and without working network connection? 4. Currently I have only Linux installed. I'm wondering what is the easiest way of updating the install USB flash drive. Best regards, Marek smime.p7s Description: S/MIME Cryptographic Signature
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:
Re: 7.0 install from install70.img no firmware for wifi (iwn-5000)
On Wed, Jan 05, 2022 at 09:12:48AM +0100, Marek Kozlowski wrote: > After I set up the ESSID and WPA-PSK the following message is displayed: > > iwn0: could not read firmware iwn-5000 (error 2) Your NIC requires firmware files which are available from: http://firmware.openbsd.org/firmware/ It's probably easiest to complete the install without setting it up, then install the firmware and configure the wireless adaptor manually afterwards. The iwn(4), and fw_update(1) manual pages have more relevant information.
7.0 install from install70.img no firmware for wifi (iwn-5000)
:-) I'm trying to install OpenBSD 7.0 from a USB flash drive using install70.img. One of the very first steps is configuring the network connection. I have a quite old ThinkPad X200s with a pupular wifi NIC (according to Linux lspci command): Intel Corporation Ultimate N WiFi Link 5300. After I set up the ESSID and WPA-PSK the following message is displayed: iwn0: could not read firmware iwn-5000 (error 2) and setting up the interface fails. AFAIK a long long time ago around 4.x (the last time I had some experience with OpenBSD) there was such a problem.but it the subsequent releases it's been fixed..? I'd really appreciate some help with solving the problem, thank you, best regards, MArek smime.p7s Description: S/MIME Cryptographic Signature
