Re: ipmi driver broken

[Ted Unangst]

Paul B. Henson wrote:
> After applying this and installing the resulting kernel, ipmi worked
> fine. I skipped 6.0, but just updated my boxes to 6.1, and see the same
> ipmi failures. It looks like this fix hasn't been applied, the code in
> head is still missing this line. I applied it again to my 6.1 kernel and
> it still seems to make ipmi work fine as far as I can tell.
> 
> Is there anyone maintaining ipmi or someone with commit privs that might
> be kind enough to apply this so the next release version would have
> working ipmi?

i'm afraid i won't make a very good ipmi maintainer, but i think i applied the
patch in the right spot.

Re: ipmi driver broken

[Theo de Raadt]

> Anyway, thanks for the thoughts; but I do still want a working ipmi :).
> No biggie to add one line and recompile the kernel, but it would be nice
> to get fixed. It's still disabled by default out of the box, you have to
> explicitly reconfigure your kernel to enable it.

If you want it working, you will need to get it fixed.  On all
machines, so that we can renable it.  Or the process you just
described will go terribly wrong soon.

Let me explain how we work.

When we disable something -- as ipmi was handled -- it means we have
give up on trying to fix it.  This code was locking up some machines
and noone cared enough to find the problem and fix it permanently.

However, if code is disabled it also means people suddenly aren't
using it, being exposed to the bug, and caring about it.  Obviously a
majority of users don't use this code.  Also that means a majority of
developers aren't using it.  I'd say that number is ZERO.

So in more than 5 years, noone has arrived to take care for it.  But
someone needs to care for every piece of code in our tree.
Indications are noone will take care of ipmi.c

So before long, the tedu will arrive with his scythe and take the
code to the other world.  I predict it won't be long before the code
we don't use, don't maintain, and which noone else maintains is gone.

Actually, this may summon the tedu...

Re: ipmi driver broken

[Paul B. Henson]

On Wed, Jun 28, 2017 at 06:31:34PM -0400, Predrag Punosevac wrote:

> My understanding is that ipmi driver used by ipmitool is disabled
> intensionally due to the security problems. IPMI pose a grave security
> risk.

IPMI on the SP is available whether or not the openbsd driver is enabled
or in use; my understanding as to why it's disabled by default it that
it's not necessarily considered stable. I've never had an issue with it,
at least not for the limited use I make of it.

> As you probably know OpenBSD comes with its own sensoring
> framework. You probably want to check out

Yes; I actually want the ipmi driver loaded so it can supply data to
said framework:

hw.sensors.ipmi0.temp0=34.00 degC (System Temp), OK
hw.sensors.ipmi0.temp1=40.00 degC (Peripheral Temp), OK
hw.sensors.ipmi0.fan0=4875 RPM (FAN 1), OK
hw.sensors.ipmi0.fan1=3000 RPM (FAN 2), OK
hw.sensors.ipmi0.fan2=3150 RPM (FAN 3), OK
hw.sensors.ipmi0.fan3=5100 RPM (FAN 4), OK
hw.sensors.ipmi0.fan4=3300 RPM (FAN A), OK
hw.sensors.ipmi0.volt0=0.71 VDC (Vcore), OK
hw.sensors.ipmi0.volt1=3.23 VDC (3.3VCC), OK
hw.sensors.ipmi0.volt2=12.14 VDC (12V), OK
hw.sensors.ipmi0.volt3=1.53 VDC (VDIMM), OK
hw.sensors.ipmi0.volt4=4.99 VDC (5VCC), OK
hw.sensors.ipmi0.volt5=-12.49 VDC (-12V), OK
hw.sensors.ipmi0.volt6=3.17 VDC (VBAT), OK
hw.sensors.ipmi0.volt7=3.36 VDC (VSB), OK
hw.sensors.ipmi0.volt8=3.23 VDC (AVCC), OK
hw.sensors.ipmi0.indicator0=Off (Chassis Intru), OK

There's more sensor data available via the IPMI interface than the
kernel supplies without it. It's also useful to be able to view the SEL
without having to loop over the network to the SP management IP. On my
linux boxes I also use the ipmi hardware watchdog, but last time I tried
that on openbsd it just kept rebooting continuously 8-/. Guess that's
one of the parts that's not stable :), but I can't remember the last
time one of my openbsd boxes wedged up anyway.

Anyway, thanks for the thoughts; but I do still want a working ipmi :).
No biggie to add one line and recompile the kernel, but it would be nice
to get fixed. It's still disabled by default out of the box, you have to
explicitly reconfigure your kernel to enable it.

Re: ipmi driver broken

[Predrag Punosevac]

Paul B. Henson wrote:

> I noticed back when I upgraded to 5.9 the ipmi driver stopped working,
> it just said:
> 
> ipmi0: get header fails
> ipmi0: no SDRs IPMI disabled
> 
> I found the following post at the time which appeared to point out the
> issue and suggest a fix:
> 
> http://openbsd-archive.7691.n7.nabble.com/fix-for-quot-ipmi0-get-header-fails-quot-td299427.html
> 
> After applying this and installing the resulting kernel, ipmi worked
> fine. I skipped 6.0, but just updated my boxes to 6.1, and see the same
> ipmi failures. It looks like this fix hasn't been applied, the code in
> head is still missing this line. I applied it again to my 6.1 kernel
> and it still seems to make ipmi work fine as far as I can tell.
 
> Is there anyone maintaining ipmi or someone with commit privs that 
> might be kind enough to apply this so the next release version would 
> have working ipmi?
> 
> Thanks much...

My understanding is that ipmi driver used by ipmitool is disabled
intensionally due to the security problems. IPMI pose a grave security
risk. As you probably know OpenBSD comes with its own sensoring
framework. You probably want to check out

http://man.openbsd.org/OpenBSD-6.1/sensorsd

http://man.openbsd.org/OpenBSD-6.1/sensorsd.conf.5

Sensorsd comes with appropriate MIBs files the native SNMP daemon and it
really easy to poll with SNMP walk. I have really nice charts coming out
of LibreNMS. For instant report check out this 

# sysctl hw.sensors
hw.sensors.cpu0.temp0=27.00 degC
hw.sensors.lm2.temp0=47.00 degC
hw.sensors.lm2.temp1=47.00 degC
hw.sensors.lm2.temp2=31.00 degC
hw.sensors.lm2.volt0=1.16 VDC (VCore)
hw.sensors.lm2.volt1=6.86 VDC (+12V)
hw.sensors.lm2.volt2=3.31 VDC (+3.3V)
hw.sensors.lm2.volt3=3.30 VDC (+3.3V)
hw.sensors.lm2.volt4=-10.54 VDC (-12V)
hw.sensors.lm2.volt5=1.26 VDC
hw.sensors.lm2.volt6=1.86 VDC
hw.sensors.lm2.volt7=3.30 VDC (3.3VSB)
hw.sensors.lm2.volt8=1.59 VDC (VBAT)

and compare to Linux

root@ari$ ipmitool sdr
CPU1 Temp| 50 degrees C  | ok
CPU2 Temp| 51 degrees C  | ok
CPU3 Temp| 69 degrees C  | ok
CPU4 Temp| 62 degrees C  | ok
System Temp  | 29 degrees C  | ok
Peripheral Temp  | 44 degrees C  | ok
PCH Temp | 49 degrees C  | ok
FAN1 | no reading| ns
FAN2 | no reading| ns
FAN3 | 4800 RPM  | ok
FAN4 | 4800 RPM  | ok
FAN5 | 4650 RPM  | ok
FAN6 | no reading| ns
FAN7 | no reading| ns
FAN8 | no reading| ns
FAN9 | no reading| ns
FAN10| no reading| ns
VTT  | 0.99 Volts| ok
CPU1 Vcore   | 1.06 Volts| ok
CPU2 Vcore   | 1.06 Volts| ok
CPU3 Vcore   | 1.06 Volts| ok
CPU4 Vcore   | 1.06 Volts| ok
VDIMM ABCD   | 1.38 Volts| ok
VDIMM EFGH   | 1.38 Volts| ok
VDIMM JKLM   | 1.38 Volts| ok
VDIMM NPRT   | 1.38 Volts| ok
3.3V | 3.36 Volts| ok
+3.3VSB  | 3.26 Volts| ok
12V  | 11.87 Volts   | ok
VBAT | 3.22 Volts| ok
Chassis Intru| 0x01  | ok
PS1 Status   | 0x01  | ok
PS2 Status   | 0x01  | ok


My favorite remote telemetry daemon Collectd has an IPMI plug-in but it
is not functional on OpenBSD as you can see by reading configuration
file (has double ## in front of the plug-in which means not available).
Hopefully this will give you something to look at if the reporting is
what you are looking for. If you actually want to control machines
remotely via IPMI that is probably different story.

Cheers,
Predrag

Re: OpenBSD IPSec setup

[Rupert Gallagher]

You need a server-signed certificate.
Sent from ProtonMail Mobile

On Wed, Jun 28, 2017 at 11:18 AM, Liviu Daia  wrote:

> I'm trying to create a VPN between my home network (sitting behind an OpenBSD 
> router), and a remote server (also an OpenBSD machine). After reading many 
> man pages and searching previous posts, I'm still thoroughly confused. What I 
> have so far: (1) On the remote server: - fixed IP, let's call it x.y.z.t - 
> pf.conf: set skip on { lo, enc } pass in quick on egress inet proto udp to 
> any port { isakmp, ipsec-nat-t } - iked.conf: ikev2 "sb1" passive esp from 
> 10.0.0.102 to 10.0.0.1 local x.y.z.t peer any srcid x.y.z.t (2) On the home 
> router: - the internal network is 192.168.7.0/24, the external IP is dynamic 
> - pf.conf: set skip on { lo, enc } pass in quick on egress inet proto udp to 
> any port { isakmp, ipsec-nat-t } match out on enc inet to 10.0.0.102 nat-to 
> 10.0.0.1 match out on egress inet from !(egress:network) nat-to (egress:0) - 
> iked.conf: ikev2 "home" active esp from 10.0.0.1 (192.168.7.0/24) to 
> 10.0.0.102 local egress peer x.y.z.t srcid 10.0.0.1 Anyone, a clue stick 
> please? Regards, Liviu Daia

scsi_xfer pool exhausted

[Martijn van Duren]

Hello misc@,

A customer system of mine has problems with the system since this 
morning (happened 3 times so far).
The dmesg shows a large number "scsi_xfer pool exhausted" messages.

Right now I have no idea on how to debug this any further.

Cluestick more than welcome

$ dmesg 
OpenBSD 6.1 (GENERIC.MP) #7: Mon Jun 12 20:41:01 CEST 2017

rob...@syspatch-61-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2026598400 (1932MB)
avail mem = 1960488960 (1869MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7ad34018 (93 entries)
bios0: vendor FUJITSU // American Megatrends Inc. version "V4.6.5.4 R1.25.0 for 
D3230-A1x" date 06/24/2014
bios0: FUJITSU ESPRIMO P420
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT SSDT SSDT MCFG HPET SSDT SSDT MSDM SLIC
acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) 
PXSX(S4) RP04(S4) GLAN(S4) EHC1(S4) EHC2(S4) XHC_(S4) HDEF(S4) PEG0(S4) PEGP(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) Pentium(R) CPU G3220 @ 3.00GHz, 2993.54 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,ERMS,INVPCID,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2993537960 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Pentium(R) CPU G3220 @ 3.00GHz, 2993.06 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,ERMS,INVPCID,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus 6 (RP03)
acpiprt4 at acpi0: bus 7 (RP04)
acpiprt5 at acpi0: bus -1 (PEG0)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C2(350@117 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(350@117 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 105 degC
acpitz1 at acpi0: critical temperature is 105 degC
"INT3F0D" at acpi0 not configured
"PNP0303" at acpi0 not configured
acpibtn0 at acpi0: PWRB
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 2993 MHz: speeds: 3000, 2900, 2700, 2600, 2400, 2300, 
2100, 2000, 1800, 1700, 1500, 1400, 1200, 1100, 900, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x06
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x06
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1280x1024, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x06: msi
azalia0: No codecs found
xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x04: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 
addr 1
"Intel 8 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 "Intel 8 Series USB" rev 0x04: apic 8 int 16
usb1 at ehci0: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
azalia1 at pci0 dev 27 function 0 "Intel 8 Series HD Audio" rev 0x04: msi
azalia1: codecs: Realtek/0x0671
audio0 at azalia1
ppb0 at pci0 dev 28 function 0 "Intel 8 Series PCIE" rev 0xd4: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel 8 Series PCIE" rev 0xd4: msi
pci2 at ppb1 bus 2
ppb2 at pci2 dev 0 function 0 vendor "ASMedia", unknown product 0x1182 rev 0x00
pci3 at ppb2 bus 3
ppb3 at pci3 dev 3 function 0 vendor "ASMedia", unknown product 0x1182 rev 
0x00: msi
pci4 at ppb3 bus 4
re0 at pci4 dev 0 function 

Re: zzz issue

[Donald Allen]

On 28 June 2017 at 03:13, Mike Larkin  wrote:

> On Sun, Jun 25, 2017 at 11:31:24AM -0400, Donald Allen wrote:
> > I am running current (though not up-to-date) on the machine described
> > by the dmesg below.
> >
> > If I suspend the system with 'zzz' having started X, when I try to
> > revive it there is no video. The system is alive otherwise and I can
> > ssh in and reboot it. Just nothing on the screen.
> >
> > Otherwise, the system runs absolutely fine on this machine.
> >
> > Don Allen
> >
>
> Not sure if this was already answered, but this is a skylake CPU and needs
> a new inteldrm driver currently in the works. A snapshot release might
> or might not work, depending on when you pick it up.
>

Ok, thanks for the information. My system is due for an update. I'll keep
an eye on the check-ins and update (after a full backup) when it seems
appropriate. I will let you know if it wakeup works.

Don

>
> -ml
>
> > OpenBSD 6.1-current (GENERIC.MP) #69: Fri May 19 09:08:02 MDT 2017
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 8458735616 (8066MB)
> > avail mem = 8196587520 (7816MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xbd1b7000 (89 entries)
> > bios0: vendor LENOVO version "FWKT63A" date 12/08/2016
> > bios0: LENOVO 10HYCTO1WW
> > acpi0 at bios0: rev 2
> > acpi0: sleep states S0 S3 S4 S5
> > acpi0: tables DSDT FACP APIC FPDT FIDT TCPA MCFG HPET SSDT LPIT SSDT
> > SSDT SSDT DBGP DBG2 SSDT MSDM SSDT UEFI SSDT LUFT ASF! BGRT
> > acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4)
> > PEG2(S4) SIO1(S3) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4)
> > RP11(S4) PXSX(S4) RP12(S4) PXSX(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) Pentium(R) CPU G4400T @ 2.90GHz, 2904.00 MHz
> > cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,
> CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,
> PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,
> CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,
> DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,
> 3DNOWP,PERF,ITSC,FSGSBASE,SGX,ERMS,INVPCID,RDSEED,SMAP,
> CLFLUSHOPT,PT,SENSOR,ARAT
> > cpu0: 256KB 64b/line 8-way L2 cache
> > cpu0: TSC frequency 290400 Hz
> > cpu0: smt 0, core 0, package 0
> > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 23MHz
> > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
> > cpu1 at mainbus0: apid 2 (application processor)
> > cpu1: Intel(R) Pentium(R) CPU G4400T @ 2.90GHz, 2904.00 MHz
> > cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,
> CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,
> PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,
> CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,
> DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,
> 3DNOWP,PERF,ITSC,FSGSBASE,SGX,ERMS,INVPCID,RDSEED,SMAP,
> CLFLUSHOPT,PT,SENSOR,ARAT
> > cpu1: 256KB 64b/line 8-way L2 cache
> > cpu1: smt 0, core 1, package 0
> > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
> > acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> > acpihpet0 at acpi0: 2399 Hz
> > acpiprt0 at acpi0: bus 0 (PCI0)
> > acpiprt1 at acpi0: bus -1 (PEG0)
> > acpiprt2 at acpi0: bus -1 (PEG1)
> > acpiprt3 at acpi0: bus -1 (PEG2)
> > acpiprt4 at acpi0: bus -1 (RP09)
> > acpiprt5 at acpi0: bus -1 (RP10)
> > acpiprt6 at acpi0: bus -1 (RP11)
> > acpiprt7 at acpi0: bus -1 (RP12)
> > acpiprt8 at acpi0: bus -1 (RP13)
> > acpiprt9 at acpi0: bus -1 (RP01)
> > acpiprt10 at acpi0: bus -1 (RP02)
> > acpiprt11 at acpi0: bus -1 (RP03)
> > acpiprt12 at acpi0: bus -1 (RP04)
> > acpiprt13 at acpi0: bus -1 (RP05)
> > acpiprt14 at acpi0: bus -1 (RP06)
> > acpiprt15 at acpi0: bus -1 (RP07)
> > acpiprt16 at acpi0: bus -1 (RP08)
> > acpiprt17 at acpi0: bus -1 (RP17)
> > acpiprt18 at acpi0: bus -1 (RP18)
> > acpiprt19 at acpi0: bus -1 (RP19)
> > acpiprt20 at acpi0: bus -1 (RP20)
> > acpiprt21 at acpi0: bus -1 (RP14)
> > acpiprt22 at acpi0: bus -1 (RP15)
> > acpiprt23 at acpi0: bus -1 (RP16)
> > acpiec0 at acpi0: not present
> > acpicpu0 at acpi0: C3(200@256 mwait.1@0x40), C2(200@151 mwait.1@0x33),
> > C1(1000@1 mwait.1), PSS
> > acpicpu1 at acpi0: C3(200@256 mwait.1@0x40), C2(200@151 mwait.1@0x33),
> > C1(1000@1 mwait.1), PSS
> > acpipwrres0 at acpi0: PG00, resource for PEG0
> > acpipwrres1 at acpi0: PG01, resource for PEG1
> > acpipwrres2 at acpi0: PG02, resource for PEG2
> > acpipwrres3 at acpi0: WRST
> > acpipwrres4 at acpi0: WRST
> > acpipwrres5 at acpi0: WRST
> > acpipwrres6 at acpi0: WRST
> > acpipwrres7 at acpi0: WRST
> > acpipwrres8 at acpi0: WRST
> > acpipwrres9 at acpi0: WRST
> > acpipwrres10 at acpi0: WRST
> > acpipwrres11 at acpi0: WRST
> > acpipwrres12 at 

Re: OpenBSD IPSec setup

[Liviu Daia]

On 28 June 2017, Philipp Buehler  
wrote:
> Am 28.06.2017 11:18 schrieb Liviu Daia:
> > 
> > set skip on { lo, enc }
> > pass  in quick on egress inet proto udp to any port { isakmp,
> > ipsec-nat-t }
> 
> needs (on both) a 'pass quick inet proto esp', too

I addded that, and still no dice.

Logs on the server:

# iked -d   
 
ikev2_recv: IKE_SA_INIT request from initiator 89.136.163.27:500 to x.y.z.t:500 
policy 'sb1' id 0, 510 bytes
ikev2_msg_send: IKE_SA_INIT response from x.y.z.t:500 to 89.136.163.27:500 
msgid 0, 471 bytes
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
policy 'sb1' id 1, 1520 bytes
ikev2_msg_send: IKE_AUTH response from x.y.z.t:500 to 89.136.163.27:500 msgid 
1, 1440 bytes
sa_state: VALID -> ESTABLISHED from 89.136.163.27:500 to x.y.z.t:500 policy 
'sb1'
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
policy 'sb1' id 2, 1520 bytes
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
policy 'sb1' id 2, 1520 bytes
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
policy 'sb1' id 2, 1520 bytes
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
policy 'sb1' id 2, 1520 bytes
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
policy 'sb1' id 2, 1520 bytes

Logs on the home router:

# iked -d   
set_policy: could not find pubkey for /etc/iked/pubkeys/ipv4/x.y.z.t
ikev2_msg_send: IKE_SA_INIT request from 89.136.163.27:500 to x.y.z.t:500 msgid 
0, 510 bytes
ikev2_recv: IKE_SA_INIT response from responder x.y.z.t:500 to 
89.136.163.27:500 policy 'home' id 0, 471 bytes
ikev2_msg_send: IKE_AUTH request from 89.136.163.27:500 to x.y.z.t:500 msgid 1, 
1520 bytes
ikev2_recv: IKE_AUTH response from responder x.y.z.t:500 to 89.136.163.27:500 
policy 'home' id 1, 1440 bytes
ikev2_ike_auth_recv: unexpected auth method RSA_SIG, was expecting SIG
ikev2_msg_send: IKE_AUTH request from 89.136.163.27:500 to x.y.z.t:500 msgid 2, 
1520 bytes

Regards,

Liviu Daia

Re: OpenBSD IPSec setup

[Philipp Buehler]

Am 28.06.2017 11:18 schrieb Liviu Daia:


set skip on { lo, enc }
pass  in quick on egress inet proto udp to any port { isakmp,
ipsec-nat-t }


needs (on both) a 'pass quick inet proto esp', too


--
pb

ipmi driver broken

[Paul B. Henson]

I noticed back when I upgraded to 5.9 the ipmi driver stopped working,
it just said:

ipmi0: get header fails
ipmi0: no SDRs IPMI disabled

I found the following post at the time which appeared to point out the
issue and suggest a fix:

http://openbsd-archive.7691.n7.nabble.com/fix-for-quot-ipmi0-get-header-fails-quot-td299427.html

After applying this and installing the resulting kernel, ipmi worked
fine. I skipped 6.0, but just updated my boxes to 6.1, and see the same
ipmi failures. It looks like this fix hasn't been applied, the code in
head is still missing this line. I applied it again to my 6.1 kernel and
it still seems to make ipmi work fine as far as I can tell.

Is there anyone maintaining ipmi or someone with commit privs that might
be kind enough to apply this so the next release version would have
working ipmi?

Thanks much...

OpenBSD IPSec setup

[Liviu Daia]

I'm trying to create a VPN between my home network (sitting behind
an OpenBSD router), and a remote server (also an OpenBSD machine).
After reading many man pages and searching previous posts, I'm still
thoroughly confused.  What I have so far:

(1) On the remote server:

  - fixed IP, let's call it x.y.z.t

  - pf.conf:

set skip on { lo, enc }
pass  in quick on egress inet proto udp to any port { isakmp, 
ipsec-nat-t }

  - iked.conf:

ikev2 "sb1" passive esp \
from 10.0.0.102 to 10.0.0.1 \
local x.y.z.t peer any \
srcid x.y.z.t

(2) On the home router:

  - the internal network is 192.168.7.0/24, the external IP is dynamic

  - pf.conf:

set skip on { lo, enc }
pass  in quick on egress inet proto udp to any port { isakmp, 
ipsec-nat-t }
match out on enc inet to 10.0.0.102 nat-to 10.0.0.1
match out on egress inet from !(egress:network) nat-to (egress:0)

  - iked.conf:

ikev2 "home" active esp \
from 10.0.0.1 (192.168.7.0/24) to 10.0.0.102 \
local egress peer x.y.z.t \
srcid 10.0.0.1

Anyone, a clue stick please?

Regards,

Liviu Daia

Re: authpf error: failed to create table (Device busy)

[md . obsd . bugs]

Hi again

i was able to further track down the issue.

If i set ruleset-optimization to none everything works fine.
So it seems that the behavior is triggered somehow by the 
optimizer.

Having a look at where the EBUSY is triggered, it looks like 
pf_find_ruleset in pfr_ina_define (sys/net/pf_table.c) does 
not return anything. I did not get any further yet, but possibly
others can?

Can anyone else confirm this behavior?

regards
\md
 
 
 Forwarded Message 
Date: Donnerstag, 22. Juni 2017 um 10:27 Uhr
From: md.obsd.b...@gmx.at
To: misc@openbsd.org
Subject: authpf error: failed to create table (Device busy)
Hi

I recently transmitted a bug report concerning an authpf issue in 6.1
(see also [1]) where loading the rules in the authpf anchor fails like
this:

"pfctl: failed to create table __automatic_ba6b4284_0 in /newuser(25710): \
Device busy" Unable to modify filters


I've not been able to reproduce the error using another set of source IPs.
Maybe I'm overlooking an syntax/config error, but using the same rule in the
base pf.conf file does not result in an evaluation error using pfctl -nf.

Is any one able to reproduce the error either using the info in [1]
or by it's own ruleset?

I'd love to deliver additional debug info.

Looking forward for feedback.
\md

[1] https://marc.info/?l=openbsd-bugs=149613063520544

Re: zzz issue

[Mike Larkin]

On Sun, Jun 25, 2017 at 11:31:24AM -0400, Donald Allen wrote:
> I am running current (though not up-to-date) on the machine described
> by the dmesg below.
> 
> If I suspend the system with 'zzz' having started X, when I try to
> revive it there is no video. The system is alive otherwise and I can
> ssh in and reboot it. Just nothing on the screen.
> 
> Otherwise, the system runs absolutely fine on this machine.
> 
> Don Allen
> 

Not sure if this was already answered, but this is a skylake CPU and needs
a new inteldrm driver currently in the works. A snapshot release might
or might not work, depending on when you pick it up.

-ml

> OpenBSD 6.1-current (GENERIC.MP) #69: Fri May 19 09:08:02 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8458735616 (8066MB)
> avail mem = 8196587520 (7816MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xbd1b7000 (89 entries)
> bios0: vendor LENOVO version "FWKT63A" date 12/08/2016
> bios0: LENOVO 10HYCTO1WW
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT TCPA MCFG HPET SSDT LPIT SSDT
> SSDT SSDT DBGP DBG2 SSDT MSDM SSDT UEFI SSDT LUFT ASF! BGRT
> acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4)
> PEG2(S4) SIO1(S3) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4)
> RP11(S4) PXSX(S4) RP12(S4) PXSX(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) Pentium(R) CPU G4400T @ 2.90GHz, 2904.00 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,ERMS,INVPCID,RDSEED,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: TSC frequency 290400 Hz
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 23MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Pentium(R) CPU G4400T @ 2.90GHz, 2904.00 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,ERMS,INVPCID,RDSEED,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 2399 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEG0)
> acpiprt2 at acpi0: bus -1 (PEG1)
> acpiprt3 at acpi0: bus -1 (PEG2)
> acpiprt4 at acpi0: bus -1 (RP09)
> acpiprt5 at acpi0: bus -1 (RP10)
> acpiprt6 at acpi0: bus -1 (RP11)
> acpiprt7 at acpi0: bus -1 (RP12)
> acpiprt8 at acpi0: bus -1 (RP13)
> acpiprt9 at acpi0: bus -1 (RP01)
> acpiprt10 at acpi0: bus -1 (RP02)
> acpiprt11 at acpi0: bus -1 (RP03)
> acpiprt12 at acpi0: bus -1 (RP04)
> acpiprt13 at acpi0: bus -1 (RP05)
> acpiprt14 at acpi0: bus -1 (RP06)
> acpiprt15 at acpi0: bus -1 (RP07)
> acpiprt16 at acpi0: bus -1 (RP08)
> acpiprt17 at acpi0: bus -1 (RP17)
> acpiprt18 at acpi0: bus -1 (RP18)
> acpiprt19 at acpi0: bus -1 (RP19)
> acpiprt20 at acpi0: bus -1 (RP20)
> acpiprt21 at acpi0: bus -1 (RP14)
> acpiprt22 at acpi0: bus -1 (RP15)
> acpiprt23 at acpi0: bus -1 (RP16)
> acpiec0 at acpi0: not present
> acpicpu0 at acpi0: C3(200@256 mwait.1@0x40), C2(200@151 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(200@256 mwait.1@0x40), C2(200@151 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: PG00, resource for PEG0
> acpipwrres1 at acpi0: PG01, resource for PEG1
> acpipwrres2 at acpi0: PG02, resource for PEG2
> acpipwrres3 at acpi0: WRST
> acpipwrres4 at acpi0: WRST
> acpipwrres5 at acpi0: WRST
> acpipwrres6 at acpi0: WRST
> acpipwrres7 at acpi0: WRST
> acpipwrres8 at acpi0: WRST
> acpipwrres9 at acpi0: WRST
> acpipwrres10 at acpi0: WRST
> acpipwrres11 at acpi0: WRST
> acpipwrres12 at acpi0: WRST
> acpipwrres13 at acpi0: WRST
> acpipwrres14 at acpi0: WRST
> acpipwrres15 at acpi0: WRST
> acpipwrres16 at acpi0: WRST
> acpipwrres17 at acpi0: WRST
> acpipwrres18 at acpi0: WRST
> acpipwrres19 at acpi0: WRST
> acpipwrres20 at acpi0: WRST
> acpipwrres21 at acpi0: WRST
> acpipwrres22 at acpi0: WRST
> acpipwrres23 at acpi0: FN00, resource for FAN0
> acpipwrres24 at acpi0: FN01, resource for FAN1
> acpipwrres25 at acpi0: FN02, resource for FAN2
> acpipwrres26 at acpi0: FN03,