Global IPv4 with ARP and wireguard peers

2021-05-11 Thread Aisha Tammy

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

2021-05-11 Thread Masato Asou
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

2021-05-11 Thread Ax0n
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

2021-05-11 Thread Moritz Grimm

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

2021-05-11 Thread Tobias Heider
>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?

2021-05-11 Thread Scott Vanderbilt

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?

2021-05-11 Thread Scott Vanderbilt

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

2021-05-11 Thread yancy ribbens
>
> 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

2021-05-11 Thread Stuart Henderson
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

2021-05-11 Thread Paul W. Rankin

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)

2021-05-11 Thread Radek
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

2021-05-11 Thread Денис Давыдов
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?

2021-05-11 Thread Edgar Pettijohn
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?

2021-05-11 Thread Robert Klein
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

2021-05-11 Thread jacky

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

2021-05-11 Thread Stuart Henderson
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?

2021-05-11 Thread Stuart Henderson
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

2021-05-11 Thread David Gwynne



> 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 "$@"