Global IPv4 with ARP and wireguard peers
Hi all, I'm trying to give my wireguard peer a global IPv4 and IPv6. The IPv6 is working fine, but the IPv4 doesn't work. My VPS host (frantech) has provided me with two IPv4s, 198.98.53.194 (main IP through dhcp) and 198.98.61.217 which I can get on my vio0 interface with the configuration /etc/hostname.vio0: inet autoconf inet alias 198.98.61.217 255.255.255.0 198.98.61.1 inet6 alias 2605:6400:10:c0::6942 48 inet6 alias 2605:6400:819e::6942 48 !route -n add -inet6 default 2605:6400:10::1 The above configuration works nicely if I want my VPS to get both the IPs. But I want the 198.98.61.217 to go to my wireguard peer. So I commented out the second line to get inet autoconf #inet alias 198.98.61.217 255.255.255.0 198.98.61.1 inet6 alias 2605:6400:10:c0::6942 48 inet6 alias 2605:6400:819e::6942 48 !route -n add -inet6 default 2605:6400:10::1 and in my wireguard config I have /etc/hostname.wg0: inet 10.42.69.1 255.255.255.255 10.42.69.1 inet6 alias 2605:6400:819e:4269:::4269 80 mtu 1420 wgkey wgport 6969 wgpeer wgpsk wgaip 198.98.61.217/32 wgaip 2605:6400:819e:4269:::1/80 up !route -n add -inet 198.98.61.217/32 -iface 10.42.69.1 !route -n add -inet6 2605:6400:819e:4269:::/80 -iface 2605:6400:819e:4269:::4269 After starting both the interfaces and wireguard interface on the peer, I am able to ping the peers global IPv6 from a different VPS on vultr, but not the IPv4. I am able to ping the peers IPv4 from the frantech VPS but I assume that is because I have a route set up. So for this I tried adding an arp proxy entry, but that gives an error $ arp -n -s 198.98.61.217 $(ifconfig vio0 | grep lladdr | awk '{print $2; }') pub set: proxy entry exists for non 802 device Now I tried to do weirder things, (1) I destroyed the wg0 interface, (2) added the arp entry, (3) deleted the arp entry, (4) started the wg0 interface - and now I can ping the IPv4 from outside!!! But this only stays for ~10-15 minutes and after which it again stops working?? $ ifconfig wg0 destroy $ arp -n -s 198.98.61.217 $(ifconfig vio0 | grep lladdr | awk '{print $2; }') pub $ arp -n -d 198.98.61.217 $ sh /etc/netstart wg0 Has anyone tried to get something like this to work? I dont get why it works for a while and then suddenly stops working!? At least the fact that it is working for a while means it should be possible to do this but my networking knowledge falls short, maybe I'm missing something obvious, so I'd appreciate the help. Thanks! Aisha
Re: 6.9 on VMware Workstation networking issues
Hi Moritz, I upgraded with the following command on my OpenBSD 6.8 release, and the network is working fine. $ doas sysupgrade I am using ESXi 6.7 and VMware Fusion 12.1.1 and em0 both environment, and network is working fine both environment. Isn't it a VMware Workstation problem? Can you try VirtualBox? -- ASOU Masato From: Moritz Grimm Date: Wed, 12 May 2021 00:32:42 +0200 > Hi, > > > Networking has become unusable in all of my virtual installs of 6.9 on > VMware Workstation after an (otherwise uneventful) sysupgrade from 6.8 > to 6.9. They've been working for years and I've upgraded them several > times without any issues so far. > > netstat -ni shows a huge number of Ofail and ping almost always prints > and error from sendmsg ("No buffer space available"), but the > occasional ping and DNS lookup does go through (at a success rate of > <5%). These are the only error messages I am getting. > > I'm using vmx(4), but also tried em(4) without any success. > > None of the upgrade69.html configuration changes are applicable, and > my pf.conf parses without errors in 6.9. > > The dmesg output (from version 6.8 below) is almost identical in 6.9, > which just shows slightly less memory available. > > I've run out of debugging ideas and would appreciate some help. My > only "solution" right now was to revert to a 6.8 snapshot. I'm also a > bit worried that I might run into similar issues on my bare metal > installs (which are all "production"), so I haven't tried those, yet. > > > Thanks, > > -Moritz > > > OpenBSD 6.8 (GENERIC.MP) #5: Mon Feb 22 04:36:10 MST 2021 > > r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 519962624 (495MB) > avail mem = 489213952 (466MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0010 (620 entries) > bios0: vendor Phoenix Technologies LTD version "6.00" date 02/27/2020 > bios0: VMware, Inc. VMware Virtual Platform > acpi0 at bios0: ACPI 4.0 > acpi0: sleep states S0 S1 S4 S5 > acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET > acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) > S8F0(S3) S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) > S25F(S3) PE40(S3) S1F0(S3) PE50(S3) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz, 2593.36 MHz, 06-9e-0d > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,XSAVEOPT,XSAVEC,XSAVES > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 65MHz > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz, 2593.40 MHz, 06-9e-0d > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,XSAVEOPT,XSAVEC,XSAVES > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 0, package 2 > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf000, bus 0-127 > acpihpet0 at acpi0: 14318179 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 > acpicmos0 at acpi0 > "PNP0A05" at acpi0 not configured > acpibat0 at acpi0: BAT1 model "VMware Virtual Batt" > acpiac0 at acpi0: AC unit online > "PNP0A05" at acpi0 not configured > "PNP0A05" at acpi0 not configured > "PNP0A05" at acpi0 not configured > "PNP0A05" at acpi0 not configured > "PNP0A05" at acpi0 not configured > acpicpu0 at acpi0: C1(@1 halt!) > acpicpu1 at acpi0: C1(@1 halt!) > pvbus0 at mainbus0: VMware > vmt0 at pvbus0 > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01 > ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01 > pci1 at ppb0 bus 1 > pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08 > pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, > channel 0 configured to compatibility, channel 1 configured to > compatibility > pciide0: channel 0 disabled (no drives) > pciide0: channel 1 disabled (no drives) > piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x08: SMBus > disabled > "VMware VMCI" rev 0x10 at pci0 dev 7
Sparc64 LDOM not working past OpenBSD 6.5
I have a SunFire T2000 that I originally installed 6.1 on. I set up LDOMs way back in May 2017. I kept all of the domains up to date until OpenBSD 6.6. After that, LDOMs would no longer work. The system would not boot unless I reverted back to the single domain default using bootmode config="factory-default" I kind of just forgot about the machine until 6.7 came out. I upgraded, and got the same errors upon trying to boot. I re-generated the LDOM config as outlined in this blog post I wrote: http://www.h-i-r.net/2017/05/logical-domains-on-sunfire-t2000-with.html That is, I dumped the factory-default config, used it as a template for the new LDOM configuration, edited a config file, applied the config to the directory and used ldomctl download to apply the LDOM config before resetting the system. Specifically, the errors I get now (and yes, some are repeats, but it's ALL I get from the console while booting) are: ERROR: /pci@780: Invalid hypervisor argument(s). function: b4 ERROR: /pci@780: Invalid hypervisor argument(s). function: b4 ERROR: /pci@780: Invalid hypervisor argument(s). function: b5 WARNING: /pci@7c0/pci@0/pci@1/network: Missing network-vpd MD node WARNING: /pci@7c0/pci@0/pci@1/network: Missing network-vpd MD node And after that, the system hangs and I must exit to the ALOM system controller prompt to do anything further, such as revert the configuration and reset to make the system able to boot again. I searched and found one other person with this problem a while back ago, but no resolution. I have hardware right here in front of me and I'm not afraid to run -CURRENT and/or test patches to help. I am also willing to provide remote SSH access to the system controller if someone wants to hack on the hardware directly if it would help, though I think there are a few LDOM-capable sparc64 machines in developers' hands already. dmesg: console is /virtual-devices@100/console@1 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2021 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.9 (GENERIC.MP) #794: Sun Apr 18 12:34:31 MDT 2021 dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP real mem = 34225520640 (32640MB) avail mem = 33608228864 (32051MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root: Sun Fire T200 cpu0 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu1 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu2 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu3 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu4 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu5 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu6 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu7 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu8 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu9 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu10 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu11 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu12 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu13 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu14 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu15 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu16 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu17 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu18 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu19 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu20 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu21 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu22 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu23 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu24 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu25 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu26 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu27 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu28 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu29 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu30 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz cpu31 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz vbus0 at mainbus0 "flashprom" at vbus0 not configured cbus0 at vbus0 vldc0 at cbus0 vldcp0 at vldc0 chan 0x0: ivec 0x0, 0x1 channel "hvctl" "ldom-primary" at vldc0 chan 0x1 not configured "fmactl" at vldc0 chan 0x3 not configured vldc1 at cbus0 "ldmfma" at vldc1 chan 0x4 not configured vldc2 at cbus0 vldcp1 at vldc2 chan 0x14: ivec 0x28, 0x29 channel "spds" "system-management" at vldc2 chan 0xd not configured vcons0 at vbus0: ivec 0x111: console vrtc0 at vbus0 "fma" at vbus0 not configured "sunvts" at vbus0 not configured "sunmc" at vbus0 not configured "explorer" at vbus0 not configured "led" at vbus0 not configured "flashupdate" at vbus0 not configured "ncp" at vbus0 not
6.9 on VMware Workstation networking issues
Hi, Networking has become unusable in all of my virtual installs of 6.9 on VMware Workstation after an (otherwise uneventful) sysupgrade from 6.8 to 6.9. They've been working for years and I've upgraded them several times without any issues so far. netstat -ni shows a huge number of Ofail and ping almost always prints and error from sendmsg ("No buffer space available"), but the occasional ping and DNS lookup does go through (at a success rate of <5%). These are the only error messages I am getting. I'm using vmx(4), but also tried em(4) without any success. None of the upgrade69.html configuration changes are applicable, and my pf.conf parses without errors in 6.9. The dmesg output (from version 6.8 below) is almost identical in 6.9, which just shows slightly less memory available. I've run out of debugging ideas and would appreciate some help. My only "solution" right now was to revert to a 6.8 snapshot. I'm also a bit worried that I might run into similar issues on my bare metal installs (which are all "production"), so I haven't tried those, yet. Thanks, -Moritz OpenBSD 6.8 (GENERIC.MP) #5: Mon Feb 22 04:36:10 MST 2021 r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 519962624 (495MB) avail mem = 489213952 (466MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0010 (620 entries) bios0: vendor Phoenix Technologies LTD version "6.00" date 02/27/2020 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) S1F0(S3) PE50(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz, 2593.36 MHz, 06-9e-0d cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,XSAVEOPT,XSAVEC,XSAVES cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 65MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz, 2593.40 MHz, 06-9e-0d cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,XSAVEOPT,XSAVEC,XSAVES cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 0, package 2 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-127 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "PNP0A05" at acpi0 not configured acpibat0 at acpi0: BAT1 model "VMware Virtual Batt" acpiac0 at acpi0: AC unit online "PNP0A05" at acpi0 not configured "PNP0A05" at acpi0 not configured "PNP0A05" at acpi0 not configured "PNP0A05" at acpi0 not configured "PNP0A05" at acpi0 not configured acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) pvbus0 at mainbus0: VMware vmt0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01 ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01 pci1 at ppb0 bus 1 pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08 pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x08: SMBus disabled "VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) mpi0 at pci0 dev 16 function 0 "Symbios Logic 53c1030" rev 0x01: apic 1 int 17 mpi0: 0, firmware 1.3.41.32 scsibus1 at mpi0: 16 targets, initiator 7 ppb1 at pci0 dev 17 function 0 "VMware PCI" rev 0x02 pci2 at ppb1 bus 2 uhci0 at pci2 dev 0 function 0 "VMware UHCI" rev 0x00: apic 1 int 18 ehci0 at pci2 dev 2 function 0 "VMware EHCI" rev 0x00: apic 1 int 16
Re: IKEv2: CHILD_SA is not created
>From my limited understanding of cisco ASA configs i can't see any obvious problems. You could try setting 'from any to any' on your side to see how the server responds. If the server is configured to narrow traffic selectors, the handshake should succeed and the log will tell you the exact traffic selectors you need in your config (look for ikev2_pld_ts in the verbose log). On Tue, May 11, 2021 at 01:47:53PM +0300, Денис Давыдов wrote: > Tobias, > > The remote side gave me their Cisco ASA 5585 settings and they showed the > logs: > > object network Svc_2_2_2_2 > host 2.2.2.2 > object network Svc_3_3_3_3 > host 3.3.3.3 > crypto ipsec ikev2 ipsec-proposal ESP-AES256-SHA2 > protocol esp encryption aes-256 > protocol esp integrity sha-256 > > object-group network Customer > description Customer > network-object 10.21.139.8 255.255.255.252 > object-group network ISP-to-Customer > description ISP-to-Customer > network-object object Svc_2_2_2_2 > network-object object Svc_3_3_3_3 > access-list outside_cryptomap_2470 extended permit ip object-group > ISP-to-Customer object-group Customer > crypto ipsec ikev2 ipsec-proposal ESP-AES256-SHA2 > crypto map outside_map 2470 match address outside_cryptomap_2470 > crypto map outside_map 2470 set pfs group14 > crypto map outside_map 2470 set connection-type answer-only > crypto map outside_map 2470 set peer 1.1.1.1 > crypto map outside_map 2470 set ikev2 ipsec-proposal ESP-AES256-SHA2 > crypto map outside_map 2470 set nat-t-disable > crypto map outside_map 2470 set reverse-route > crypto ikev2 policy 100 > encryption aes-256 > integrity sha > group 21 20 19 24 14 5 2 > prf sha > lifetime seconds 28800 > tunnel-group 1.1.1.1 type ipsec-l2l > tunnel-group 1.1.1.1 general-attributes > default-group-policy GroupPolicy-Def-IKE2 > tunnel-group 1.1.1.1 ipsec-attributes > ikev1 pre-shared-key * > ikev2 remote-authentication pre-shared-key * > ikev2 local-authentication pre-shared-key * > ikev2 local-authentication pre-shared-key * > > asa-8m-a5-820-l2l/sec/act# sh logg | i 1.1.1.1 > May 11 2021 13:35:11: %ASA-7-609001: Built local-host outside:1.1.1.1 > May 11 2021 13:35:11: %ASA-6-302015: Built inbound UDP connection > 1392894457 for outside:1.1.1.1/500 (1.1.1.1/500) to identity:7.7.7.7/500 ( > 7.7.7.7/500) > May 11 2021 13:35:11: %ASA-7-713906: IKE Receiver: Packet received on > 7.7.7.7:500 from 1.1.1.1:500 > May 11 2021 13:35:11: %ASA-5-750002: Local:7.7.7.7:500 Remote:1.1.1.1:500 > Username:Unknown IKEv2 Received a IKE_INIT_SA request > May 11 2021 13:35:11: %ASA-7-713906: IKE Receiver: Packet received on > 7.7.7.7:500 from 1.1.1.1:500 > May 11 2021 13:35:11: %ASA-5-750007: Local:7.7.7.7:500 Remote:1.1.1.1:500 > Username:1.1.1.1 IKEv2 SA DOWN. Reason: application initiated > May 11 2021 13:35:11: %ASA-4-113019: Group = 1.1.1.1, Username = 1.1.1.1, > IP = 1.1.1.1, Session disconnected. Session Type: LAN-to-LAN, Duration: > 0h:05m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: IKE Delete > May 11 2021 13:35:11: %ASA-5-750006: Local:7.7.7.7:500 Remote:1.1.1.1:500 > Username:1.1.1.1 IKEv2 SA UP. Reason: New Connection Established > May 11 2021 13:35:11: %ASA-6-113009: AAA retrieved default group policy > (GroupPolicy-Def-IKE2) for user = 1.1.1.1 > > > P.S. This is strange, but with another provider, which has the Cisco ASA > 5585-SSP10, there are no such problems. > > -- > Sincerely, > Denis > > On Fri, May 7, 2021 at 1:10 PM Tobias Heider > wrote: > > > On Fri, May 07, 2021 at 12:17:35PM +0300, Денис Давыдов wrote: > > > Hello all, > > > > > > I can't understand why I got SA_INIT timeout: > > > May 5 13:18:54 crypto-gw2 iked[65530]: spi=0x73bcd531eb2e8899: sa_free: > > > SA_INIT timeout > > > > > > 1.1.1.1 (crypto-gw2) - my host > > > 7.7.7.7 - our isp provider (some of cisco devices) > > > > > > /etc/iked.conf (on 1.1.1.1): > > > > > > ikev2 crypto-primary active esp \ > > > from 10.21.139.8/30 to 2.2.2.2 \ > > > from 10.21.139.8/30 to 3.3.3.3 \ > > > peer 7.7.7.7 \ > > > ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group > > modp2048 > > > \ > > > childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ > > > ikelifetime 86400 lifetime 28800 \ > > > psk "secret" > > > > > > The remote side claims to have the same settings. > > > > > > crypto-gw2# ikectl sh sa | grep 7.7.7.7 > > > iked_sas: 0xb0e1878b7d0 rspi 0x2d606f017d098928 ispi 0xd0497626849535cd > > > 1.1.1.1:500->7.7.7.7:500[] AUTH_SUCCESS i nexti 0x0 > > pol > > > 0xb0e9b38d000 > > > > > > Why CHILD_SA is not being created? I tried to figure it out from the logs > > > but couldn't. > > > > > > It looks like the peer sends its IKE_AUTH reply without SA payload but > > with a TS_UNACCEPTABLE notification. > > The most likely cause is that your "from ... to ..." configuration is > > incompatible with the configuration of your peer. > > > > Thanks for the report, I will see how I can make this error more obvious > > in the logs. > >
Re: Not possible to sysupgrade via snapshots right now?
On 5/11/2021 3:41 AM, Edgar Pettijohn wrote: On May 11, 2021 3:42 AM, Robert Klein wrote: On Sun, 9 May 2021 07:47:32 -0700 Scott Vanderbilt wrote: > On 5/9/2021 4:04 AM, Stuart Henderson wrote: > > On 2021-05-08, Scott Vanderbilt wrote: > >> Apologies if this is a question to which there is an obvious > >> answer, but I could not find one in the sysupgrade man page, in > >> the FAQ, or by Googling. > >> > >> Is it not possible to do a sysupgrade from 6.9-current to latest > >> using snapshots at the moment? When I try, I get the following > >> response from sysupgrade: > > > > This can only have happened if you were running a "6.9" kernel and > > not "6.9-current". You might still have the boot messages to > > confirm; zgrep OpenBSD /var/log/messages* > > > > I can assure you with absolute certainty that this machine in > question was running 6.9-current prior to the attempt to run > sysupgrade. > maybe you had a snapshot claiming to be “release”. This typically happened in the past a couple of days around the actual release. If you look at the history of sys/conf/newvers.sh (e.g. at the github mirror, if CVS is too much effort for one file) you'll see 6.9 went out of beta on April, 4 and into current on April 18. I'd guess snapshots made during this period all are marked “release”. This is similar to how pkg_* requires -Dsnap from time to time. I've just trained myself to always use the flags so as not to let the software have to decide for me. Excellent advice. I will make a habit of doing this going forward. Many thanks.
Re: Not possible to sysupgrade via snapshots right now?
On 5/11/2021 1:42 AM, Robert Klein wrote: On Sun, 9 May 2021 07:47:32 -0700 Scott Vanderbilt wrote: On 5/9/2021 4:04 AM, Stuart Henderson wrote: On 2021-05-08, Scott Vanderbilt wrote: Apologies if this is a question to which there is an obvious answer, but I could not find one in the sysupgrade man page, in the FAQ, or by Googling. Is it not possible to do a sysupgrade from 6.9-current to latest using snapshots at the moment? When I try, I get the following response from sysupgrade: This can only have happened if you were running a "6.9" kernel and not "6.9-current". You might still have the boot messages to confirm; zgrep OpenBSD /var/log/messages* I can assure you with absolute certainty that this machine in question was running 6.9-current prior to the attempt to run sysupgrade. maybe you had a snapshot claiming to be “release”. This typically happened in the past a couple of days around the actual release. If you look at the history of sys/conf/newvers.sh (e.g. at the github mirror, if CVS is too much effort for one file) you'll see 6.9 went out of beta on April, 4 and into current on April 18. I'd guess snapshots made during this period all are marked “release”. Bingo. The upgrade history on the machine in question went from: OpenBSD 6.9 (GENERIC.MP) #469: Fri Apr 16 11:07:03 MDT 2021 to: OpenBSD 6.9-current (GENERIC.MP) #9: Sat May 8 14:55:48 MDT 2021 So the Apr 16 snapshot I assumed to be 6.9-current was masquerading as 6.9 release. Now it's all making sense. Thanks for pointing that out.
Re: bitcoind out of memory
> > Always surprises me when people are willing to run things like that as > root.. This is a single purpose system so I'm not worried about collateral damage, although I agree it's best practice to use a limited account for usrland applications. I had thought it would be experimentally easier to try this using root. Did you logout and back in between updating login.conf and retrying? > (Needs to be a full logout; if you use an ssh persistent connection that > will need to be closed; if you use X that needs to be restarted). > Check what ulimit -a says. > Yes, I tried a full logoug and also running "cap_mkdb /etc/login.conf" after updating. > LONG in the cpu capabilities line means that the hardware can usually run > amd64. That would give you a few hundred MB more physical memory, and much > more available memory address space (and a lot of software is only really > tested on 64-bit archs these days anyway..) So you might possibly like > to try that. > Thanks, I overlooked this and thought it was a 32bit machine. After installing amd64 and running bitcoind under a limited user account, It's been working perfectly out of the box without any system modifications. Cheers, -Yancy On Sat, May 8, 2021 at 12:29 PM Stuart Henderson wrote: > On 2021-05-07, yancy ribbens wrote: > > I'm running 6.8 and trying to run bitcoind (C++), however, I continue to > > receive a core dump while running the application (out of memory). The > > dmesg file is below. > > Always surprises me when people are willing to run things like that as > root.. > > > The application is running as root and I've set datasize-max and > > datasize-cur to infinity in the login.conf daemon section as I suspect > the > > core dump is happening because of an upper memory bound enforced by the > OS. > > Did you logout and back in between updating login.conf and retrying? > (Needs to be a full logout; if you use an ssh persistent connection that > will need to be closed; if you use X that needs to be restarted). > Check what ulimit -a says. > > > running the application \time -l twice shows the resident set size each > > time to be: > > 662128 > > 650388 > > > > I've also observed "top" while running and there is more than 1GB free > and > > SWAP is not being used at the time it core dumps (out of memory). > > If it requests an allocation which fails, that memory won't be "used" to > show up in top / time -l. > > > Is this a problem with a login.conf parameter or something else? > > > > OpenBSD 6.8 (GENERIC.MP) #440: Sun Oct 4 18:33:20 MDT 2020 > > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP > ... > > cpu0: > > > FPU,V86,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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN > > LONG in the cpu capabilities line means that the hardware can usually run > amd64. That would give you a few hundred MB more physical memory, and much > more available memory address space (and a lot of software is only really > tested on 64-bit archs these days anyway..) So you might possibly like > to try that. > > >
Re: Editing boot.conf to set tty to fb0 in miniroot69.img
On 2021-05-11, Paul W. Rankin wrote: > Hello, > > I am trying to install OpenBSD on a Raspberry Pi 4B without the > assistance of the serial console. The Pi firmware is set to boot from > USB. I have arm64 miniroot69 on a USB and the system boots; I see the > "BOOT>" prompt, but my USB keyboard does not appear to be recognised at > this point in boot, so I cannot interrupt and set tty to fb0. The boot > then proceeds to the serial console (i.e. blank screen). > > The thought occurred that it may be possible to change boot.conf in the > miniroot69 image to set tty to fb0 but so far my attempts have been > unsuccessful. I have tried... > > ...on my macOS system, I tried many variations of the following without > success: > > # qemu-system-aarch64 -machine raspi3 -hda /dev/disk2 > # qemu-system-aarch64 -machine virt -hda /dev/disk2 > # qemu-system-aarch64 -machine raspi3 -drive > file=miniroot69.img,format=raw > # qemu-system-aarch64 -machine virt -drive file=/dev/disk2,format=raw > > The qemu system just presents a blank screen. Nothing on serial or > parallel screens. > > ...on my OpenBSD server, I tried mounting the miniroot69.img and > altering boot.conf directly: > > # vnconfig vnd0 miniroot69.img > # mount /dev/vnd0a /mnt > > But this just presents: > > # ls -1 > bsd > bsd.rd > > Does anyone have any suggestion of how I might achieve editing boot.conf > on the miniroot69 image or otherwise how to boot the Raspberry Pi 4B > into fb0? That would go on the booted disk, not inside the ramdisk kernel, so cd /mnt mkdir etc echo set tty fb0 > etc/boot.conf Pretty sure I tested that scenario and it worked without boot.conf though I'm not sure if it was with the pftf firmware or U-Boot.
Editing boot.conf to set tty to fb0 in miniroot69.img
Hello, I am trying to install OpenBSD on a Raspberry Pi 4B without the assistance of the serial console. The Pi firmware is set to boot from USB. I have arm64 miniroot69 on a USB and the system boots; I see the "BOOT>" prompt, but my USB keyboard does not appear to be recognised at this point in boot, so I cannot interrupt and set tty to fb0. The boot then proceeds to the serial console (i.e. blank screen). The thought occurred that it may be possible to change boot.conf in the miniroot69 image to set tty to fb0 but so far my attempts have been unsuccessful. I have tried... ...on my macOS system, I tried many variations of the following without success: # qemu-system-aarch64 -machine raspi3 -hda /dev/disk2 # qemu-system-aarch64 -machine virt -hda /dev/disk2 # qemu-system-aarch64 -machine raspi3 -drive file=miniroot69.img,format=raw # qemu-system-aarch64 -machine virt -drive file=/dev/disk2,format=raw The qemu system just presents a blank screen. Nothing on serial or parallel screens. ...on my OpenBSD server, I tried mounting the miniroot69.img and altering boot.conf directly: # vnconfig vnd0 miniroot69.img # mount /dev/vnd0a /mnt But this just presents: # ls -1 bsd bsd.rd Does anyone have any suggestion of how I might achieve editing boot.conf on the miniroot69 image or otherwise how to boot the Raspberry Pi 4B into fb0? Much thanks, -- Paul W. Rankin https://bydasein.com The single best thing you can do for the world is delete your social media accounts.
Re: DHCPd - option capwap (code 138)
Update. My conf seems to work as expected, but it took a few hours for APs to find the controller. Since then even new APs find the controlles in a few minutes. Controller: Alcatel-Lucent OmniVista 2500 APs: OAW-AP1321-RW Thanks for your help! On Mon, 10 May 2021 15:30:01 +0200 Radek wrote: > Thank you Denis,Stu, > > I added option-138, the syntax is correct now but the AP doesn't connect to > the Controller. > Did I missed any other option(s) in my dhcpd.conf or should I look for the > reason at the Controller side? > > subnet 10.109.3.0 netmask 255.255.255.0 { > option routers 10.109.3.254; > range 10.109.3.201 10.109.3.220; > #option option-138 10.109.3.100; > option option-138 A:6D:3:64; > > host [...] > > On Thu, 6 May 2021 11:45:43 +0200 > Denis Fondras wrote: > > > Le Thu, May 06, 2021 at 10:48:55AM +0200, Radek a écrit : > > > Hello, > > > I want to use dhcpd server to push Wireless Controller's IP address to > > > the APs. > > > > > > According to this: > > > http://systemnetworksecurity.blogspot.com/2013/02/adding-custom-options-in-isc-dhcpds.html > > > https://www.secuvera.de/blog/capwap-dhcp-option-138-auf-isc-dhcpd-server-einrichten/ > > > I need to add *option capwap* to /etc/dhcpd.conf > > > > > > option capwap code 138 = ip-address; #Custom Option capwap > > > option capwap 192.168.1.110; #WLAN-Controller-IP > > > > > > > Have you tried something like : > > > > option option-138 C0:A8:01:6E; > > > > ? > > > > > -- > Radek > -- Radek
Re: IKEv2: CHILD_SA is not created
Tobias, The remote side gave me their Cisco ASA 5585 settings and they showed the logs: object network Svc_2_2_2_2 host 2.2.2.2 object network Svc_3_3_3_3 host 3.3.3.3 crypto ipsec ikev2 ipsec-proposal ESP-AES256-SHA2 protocol esp encryption aes-256 protocol esp integrity sha-256 object-group network Customer description Customer network-object 10.21.139.8 255.255.255.252 object-group network ISP-to-Customer description ISP-to-Customer network-object object Svc_2_2_2_2 network-object object Svc_3_3_3_3 access-list outside_cryptomap_2470 extended permit ip object-group ISP-to-Customer object-group Customer crypto ipsec ikev2 ipsec-proposal ESP-AES256-SHA2 crypto map outside_map 2470 match address outside_cryptomap_2470 crypto map outside_map 2470 set pfs group14 crypto map outside_map 2470 set connection-type answer-only crypto map outside_map 2470 set peer 1.1.1.1 crypto map outside_map 2470 set ikev2 ipsec-proposal ESP-AES256-SHA2 crypto map outside_map 2470 set nat-t-disable crypto map outside_map 2470 set reverse-route crypto ikev2 policy 100 encryption aes-256 integrity sha group 21 20 19 24 14 5 2 prf sha lifetime seconds 28800 tunnel-group 1.1.1.1 type ipsec-l2l tunnel-group 1.1.1.1 general-attributes default-group-policy GroupPolicy-Def-IKE2 tunnel-group 1.1.1.1 ipsec-attributes ikev1 pre-shared-key * ikev2 remote-authentication pre-shared-key * ikev2 local-authentication pre-shared-key * ikev2 local-authentication pre-shared-key * asa-8m-a5-820-l2l/sec/act# sh logg | i 1.1.1.1 May 11 2021 13:35:11: %ASA-7-609001: Built local-host outside:1.1.1.1 May 11 2021 13:35:11: %ASA-6-302015: Built inbound UDP connection 1392894457 for outside:1.1.1.1/500 (1.1.1.1/500) to identity:7.7.7.7/500 ( 7.7.7.7/500) May 11 2021 13:35:11: %ASA-7-713906: IKE Receiver: Packet received on 7.7.7.7:500 from 1.1.1.1:500 May 11 2021 13:35:11: %ASA-5-750002: Local:7.7.7.7:500 Remote:1.1.1.1:500 Username:Unknown IKEv2 Received a IKE_INIT_SA request May 11 2021 13:35:11: %ASA-7-713906: IKE Receiver: Packet received on 7.7.7.7:500 from 1.1.1.1:500 May 11 2021 13:35:11: %ASA-5-750007: Local:7.7.7.7:500 Remote:1.1.1.1:500 Username:1.1.1.1 IKEv2 SA DOWN. Reason: application initiated May 11 2021 13:35:11: %ASA-4-113019: Group = 1.1.1.1, Username = 1.1.1.1, IP = 1.1.1.1, Session disconnected. Session Type: LAN-to-LAN, Duration: 0h:05m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: IKE Delete May 11 2021 13:35:11: %ASA-5-750006: Local:7.7.7.7:500 Remote:1.1.1.1:500 Username:1.1.1.1 IKEv2 SA UP. Reason: New Connection Established May 11 2021 13:35:11: %ASA-6-113009: AAA retrieved default group policy (GroupPolicy-Def-IKE2) for user = 1.1.1.1 P.S. This is strange, but with another provider, which has the Cisco ASA 5585-SSP10, there are no such problems. -- Sincerely, Denis On Fri, May 7, 2021 at 1:10 PM Tobias Heider wrote: > On Fri, May 07, 2021 at 12:17:35PM +0300, Денис Давыдов wrote: > > Hello all, > > > > I can't understand why I got SA_INIT timeout: > > May 5 13:18:54 crypto-gw2 iked[65530]: spi=0x73bcd531eb2e8899: sa_free: > > SA_INIT timeout > > > > 1.1.1.1 (crypto-gw2) - my host > > 7.7.7.7 - our isp provider (some of cisco devices) > > > > /etc/iked.conf (on 1.1.1.1): > > > > ikev2 crypto-primary active esp \ > > from 10.21.139.8/30 to 2.2.2.2 \ > > from 10.21.139.8/30 to 3.3.3.3 \ > > peer 7.7.7.7 \ > > ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group > modp2048 > > \ > > childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ > > ikelifetime 86400 lifetime 28800 \ > > psk "secret" > > > > The remote side claims to have the same settings. > > > > crypto-gw2# ikectl sh sa | grep 7.7.7.7 > > iked_sas: 0xb0e1878b7d0 rspi 0x2d606f017d098928 ispi 0xd0497626849535cd > > 1.1.1.1:500->7.7.7.7:500[] AUTH_SUCCESS i nexti 0x0 > pol > > 0xb0e9b38d000 > > > > Why CHILD_SA is not being created? I tried to figure it out from the logs > > but couldn't. > > > It looks like the peer sends its IKE_AUTH reply without SA payload but > with a TS_UNACCEPTABLE notification. > The most likely cause is that your "from ... to ..." configuration is > incompatible with the configuration of your peer. > > Thanks for the report, I will see how I can make this error more obvious > in the logs. >
Re: Not possible to sysupgrade via snapshots right now?
On May 11, 2021 3:42 AM, Robert Klein wrote: On Sun, 9 May 2021 07:47:32 -0700 Scott Vanderbilt wrote: > On 5/9/2021 4:04 AM, Stuart Henderson wrote: > > On 2021-05-08, Scott Vanderbilt wrote: > >> Apologies if this is a question to which there is an obvious > >> answer, but I could not find one in the sysupgrade man page, in > >> the FAQ, or by Googling. > >> > >> Is it not possible to do a sysupgrade from 6.9-current to latest > >> using snapshots at the moment? When I try, I get the following > >> response from sysupgrade: > > > > This can only have happened if you were running a "6.9" kernel and > > not "6.9-current". You might still have the boot messages to > > confirm; zgrep OpenBSD /var/log/messages* > > > > I can assure you with absolute certainty that this machine in > question was running 6.9-current prior to the attempt to run > sysupgrade. > maybe you had a snapshot claiming to be “release”. This typically happened in the past a couple of days around the actual release. If you look at the history of sys/conf/newvers.sh (e.g. at the github mirror, if CVS is too much effort for one file) you'll see 6.9 went out of beta on April, 4 and into current on April 18. I'd guess snapshots made during this period all are marked “release”. Best regards Robert This is similar to how pkg_* requires -Dsnap from time to time. I've just trained myself to always use the flags so as not to let the software have to decide for me. Edgar
Re: Not possible to sysupgrade via snapshots right now?
On Sun, 9 May 2021 07:47:32 -0700 Scott Vanderbilt wrote: > On 5/9/2021 4:04 AM, Stuart Henderson wrote: > > On 2021-05-08, Scott Vanderbilt wrote: > >> Apologies if this is a question to which there is an obvious > >> answer, but I could not find one in the sysupgrade man page, in > >> the FAQ, or by Googling. > >> > >> Is it not possible to do a sysupgrade from 6.9-current to latest > >> using snapshots at the moment? When I try, I get the following > >> response from sysupgrade: > > > > This can only have happened if you were running a "6.9" kernel and > > not "6.9-current". You might still have the boot messages to > > confirm; zgrep OpenBSD /var/log/messages* > > > > I can assure you with absolute certainty that this machine in > question was running 6.9-current prior to the attempt to run > sysupgrade. > maybe you had a snapshot claiming to be “release”. This typically happened in the past a couple of days around the actual release. If you look at the history of sys/conf/newvers.sh (e.g. at the github mirror, if CVS is too much effort for one file) you'll see 6.9 went out of beta on April, 4 and into current on April 18. I'd guess snapshots made during this period all are marked “release”. Best regards Robert
Dell M4700 laptop fan problem
Hi, the fan always on, any helps, Thanks On 5/10/21 7:10 AM, jacky wrote: OpenBSD 6.9 (GENERIC.MP) #473: Mon Apr 19 10:40:28 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34244227072 (32657MB) avail mem = 33191006208 (31653MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec110 (114 entries) bios0: vendor Dell Inc. version "A18" date 02/21/2018 bios0: Dell Inc. Precision M4700 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT ASF! SLIC BGRT SSDT acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB5(S3) USB6(S3) USB7(S3) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz, 2791.46 MHz, 06-3a-09 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz, 2790.95 MHz, 06-3a-09 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz, 2790.95 MHz, 06-3a-09 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz, 2790.95 MHz, 06-3a-09 cpu3: 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 2 (RP01) acpiprt3 at acpi0: bus 3 (RP02) acpiprt4 at acpi0: bus -1 (RP05) acpiprt5 at acpi0: bus -1 (RP06) acpiprt6 at acpi0: bus -1 (RP07) acpiprt7 at acpi0: bus 8 (RP08) acpiprt8 at acpi0: bus 1 (PEG0) acpiprt9 at acpi0: bus -1 (PEG1) acpiprt10 at acpi0: bus -1 (PEG2) acpiprt11 at acpi0: bus -1 (PEG3) acpiprt12 at acpi0: bus -1 (RP03) acpiprt13 at acpi0: bus 4 (RP04) acpiec0 at acpi0 acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001 acpicmos0 at acpi0 "SMO8810" at acpi0 not configured "*pnp0c14" at acpi0 not configured acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PBTN acpibtn2 at acpi0: SBTN acpiac0 at acpi0: AC unit offline acpibat0 at acpi0: BAT0 model "DELL HPNYM12" serial 1033 type LION oem "SMP" acpibat1 at acpi0: BAT1 not present "DELLABCE" at acpi0 not configured acpicpu0 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1) acpicpu1 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1) acpicpu2 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1) acpicpu3 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1) acpitz0 at acpi0: critical temperature is 107 degC acpivideo0 at acpi0: VID_ acpivout0 at acpivideo0: LCD_ acpivideo1 at acpi0: VID_ acpivout1 at acpivideo1: LCD_ cpu0: using VERW MDS workaround (except on vmm entry) pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G
Re: 'python3.8 setup.py install' gets 'ZIP does not support timestamps before 1980' at OpenBSD 6.9
On 2021-05-10, Roger Marsh wrote: > After upgrading to OpenBSD 6.9 'ValueError: ZIP does not support timestamps > before 1980' exceptions started occuring when installing python packages by: > > 'python3.8 setup.py install --user' where the package was built by: > > 'python3.8 setup.py sdist --formats gztar' and extracted from the archive on > OpenBSD 6.9 by: > > 'tar xzf *.tar.gz'. Python-created tars started storing timestamps in nanoseconds via pax extension headers which tar in base doesn't handle. You'll need to use another program to extract them for now; gtar works.
Re: Not possible to sysupgrade via snapshots right now?
On 2021-05-09, Scott Vanderbilt wrote: > On 5/9/2021 4:04 AM, Stuart Henderson wrote: >> On 2021-05-08, Scott Vanderbilt wrote: >>> Apologies if this is a question to which there is an obvious answer, but >>> I could not find one in the sysupgrade man page, in the FAQ, or by Googling. >>> >>> Is it not possible to do a sysupgrade from 6.9-current to latest using >>> snapshots at the moment? When I try, I get the following response from >>> sysupgrade: >> >> This can only have happened if you were running a "6.9" kernel and >> not "6.9-current". You might still have the boot messages to confirm; >> zgrep OpenBSD /var/log/messages* >> > > I can assure you with absolute certainty that this machine in question > was running 6.9-current prior to the attempt to run sysupgrade. Can you have a look at the shell script which is /usr/sbin/sysupgrade and see if you can figure out how? It doesn't seem possible to me (unless you're doing something you didn't mention, like using sysupgrade -r). > Is it possibly relevant that the upgrade files were "cached" to a host > on my LAN before the sysupgrade? I typically download all the upgrade > files to a local machine and sysupgrade that machine first. Then for two > other machines on my network, I sysupgrade with /etc/installurl pointing > to my local server. I do this to prevent multiple downloads from the > OpenBSD servers. That's not a problem as long as the normal directory structure is used. > Might having SHA256.sig come from one location while the other upgrade > files come from a second location possibly confuse sysupgrade? If SHA256.sig doesn't match the signature of the other files in the directory then it won't run the update, same as if a snapshot is only partially updated on a mirror server (which happens sometimes).
Re: Home Assistant
> On 11 May 2021, at 05:01, pas...@pascallen.nl wrote: > > Dear David, > > How do you start homeassistant after a reboot? Manually? i have these scripts. the pexp in the rc script doesnt work, but i havent needed it to yet. apathy$ cat /etc/rc.d/hass #!/bin/ksh daemon="/opt/local/sbin/hass --daemon" daemon_user="_hass" pexp="/opt/hass/bin/hass" . /etc/rc.d/rc.subr rc_reload=NO rc_cmd $1 apathy$ cat /opt/local/sbin/hass #!/bin/ksh . /opt/hass/bin/activate /opt/hass/bin/hass "$@"