Re: LACP problem

[Lyndon Nerenberg]

> On Jun 8, 2017, at 7:47 PM, Charles Lecklider  wrote:
> 
> The trunk is there, seems to be configured the right way, but the second
> port doesn't come up. If I pull the cable on em0, em1 comes up, put the
> cable back, em0 doesn't join the trunk.

What you're showing looks fine.  We run this all over the place in house.  This 
points to the switch being confused about the configuration of the trunk.

> Have I botched the config somewhere? Or is there some incompatibility
> going on between OpenBSD and the switch? And if it's the latter, how do
> I get some diagnostic information to work out what's going on?

The first step is to have the switch display its idea of the LACP configuration 
and status.  I haven't a clue how a TP-LINK does that, but on our Junipers it's 
'show lacp interfaces'. E.g.:

> show lacp interfaces 
Aggregated interface: ae0
LACP state:   Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
  ge-0/0/0   ActorNoNo   Yes  Yes  Yes   Yes FastActive
  ge-0/0/0 PartnerNoNo   Yes  Yes  Yes   Yes FastActive
  ge-1/0/0   ActorNoNo   Yes  Yes  Yes   Yes FastActive
  ge-1/0/0 PartnerNoNo   Yes  Yes  Yes   Yes FastActive
LACP protocol:Receive State  Transmit State  Mux State 
  ge-0/0/0  Current   Fast periodic Collecting distributing
  ge-1/0/0  Current   Fast periodic Collecting distributing

Aggregated interface: ae1
LACP state:   Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
  ge-0/0/7   ActorNoNo   Yes  Yes  Yes   Yes FastActive
  ge-0/0/7 PartnerNoNo   Yes  Yes  Yes   Yes SlowActive
  ge-1/0/7   ActorNoNo   Yes  Yes  Yes   Yes FastActive
  ge-1/0/7 PartnerNoNo   Yes  Yes  Yes   Yes SlowActive
LACP protocol:Receive State  Transmit State  Mux State 
  ge-0/0/7  Current   Slow periodic Collecting distributing
  ge-1/0/7  Current   Slow periodic Collecting distributing

[...]

Re: LACP problem

[Lyndon Nerenberg]

> On Jun 8, 2017, at 7:54 PM, Lyndon Nerenberg  wrote:
> 
> Why do em0 and em1 have the same MAC address?

Oh shit, never mind - it's the trunk interface :-P  Sorry ...

Re: LACP problem

[Lyndon Nerenberg]

> On Jun 8, 2017, at 7:47 PM, Charles Lecklider  wrote:
> 
> em0: flags=8b43
> mtu 9000
>lladdr 0c:c4:7a:d9:ea:d0
>index 5 priority 0 llprio 3
>trunk: trunkdev trunk0
>media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
>status: active
> em1: flags=8b43
> mtu 9000
>lladdr 0c:c4:7a:d9:ea:d0
>index 6 priority 0 llprio 3
>trunk: trunkdev trunk0
>media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
>status: active

Why do em0 and em1 have the same MAC address?

LACP problem

[Charles Lecklider]

I'm trying to get LACP working over 2 ports (em0, em1). I've done this
successfully with FreeBSD and 4 ports on the same switch so I know it
can be done, I just can't get it working with OpenBSD. I'm hoping I've
just botched the config somewhere.

The switch is a TP-LINK TL-SG3424, latest firmware available, and LACP
is set to passive for the two ports (I've tried active, too).

hostname.em0:
mtu 9000 up

hostname,em1:
mtu 9000 up

hostname.trunk0:
trunkport em0 trunkport em1 trunkproto lacp
inet 10.1.2.1 255.255.255.0 NONE


>From my reading of the man pages that's all I need to do, and ifconfig
seems to agree:

em0: flags=8b43
mtu 9000
lladdr 0c:c4:7a:d9:ea:d0
index 5 priority 0 llprio 3
trunk: trunkdev trunk0
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
em1: flags=8b43
mtu 9000
lladdr 0c:c4:7a:d9:ea:d0
index 6 priority 0 llprio 3
trunk: trunkdev trunk0
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active

trunk0: flags=8843 mtu 9000
lladdr 0c:c4:7a:d9:ea:d0
index 11 priority 0 llprio 3
trunk: trunkproto lacp
trunk id: [(8000,0c:c4:7a:d9:ea:d0,405C,,),
 (8000,30:b5:c2:07:81:4a,0CF3,,)]
trunkport em1
trunkport em0 active,collecting,distributing
groups: trunk
media: Ethernet autoselect
status: active
inet 10.1.2.1 netmask 0xff00 broadcast 10.1.2.255


The trunk is there, seems to be configured the right way, but the second
port doesn't come up. If I pull the cable on em0, em1 comes up, put the
cable back, em0 doesn't join the trunk.


Have I botched the config somewhere? Or is there some incompatibility
going on between OpenBSD and the switch? And if it's the latter, how do
I get some diagnostic information to work out what's going on?

Thanks!




OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr  1 13:45:56 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17134788608 (16341MB)
avail mem = 16610807808 (15841MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7f4d8000 (53 entries)
bios0: vendor American Megatrends Inc. version "1.1a" date 08/27/2015
bios0: Supermicro A1SAi
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP FPDT FIDT SPMI MCFG WDAT UEFI APIC BDAT HPET
SSDT HEST BERT ERST EINJ
acpi0: wakeup devices PEX1(S0) PEX2(S0) PEX3(S0) PEX4(S0) EHC1(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C2550 @ 2.40GHz, 2400.44 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: TSC frequency 2400438240 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU C2550 @ 2.40GHz, 2400.01 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Atom(TM) CPU C2550 @ 2.40GHz, 2400.01 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu2: 1MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Atom(TM) CPU C2550 @ 2.40GHz, 2400.01 MHz
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu3: 1MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins

Re: booting 6.1

[Jonathan Gray]

On Thu, Jun 08, 2017 at 03:10:33PM -0300, Friedrich Locke wrote:
> Hi folks,
> 
> i burnt and install61.iso cd and tried to boot uefi, but could not.
> Does anybody know this amd64 6.1 install image support booting UEFI ?
> 
> Thanks in advance

The iso does not handle uefi at the moment.  Write install61.fs to a usb
stick instead.

Re: SCSI Enclosure Service

[David Gwynne]

hey jens,

from what i can tell, you talk to the ami mg9071 chips on that enclosure using 
sgpio, not in band using smp (sas mgmt protocol) or ses as a scsi device.

i get the impression that mpii hardware does have some understanding of 
enclosures connected via sgpio, but i'm not sure what benefit it would provide. 
it may affect addressing on the bus, but im not sure you'd get temperatures or 
fan speeds or anything off it.

cheers,
dlg

> On 9 Jun 2017, at 02:05, Jens A. Griepentrog  
> wrote:
> 
> Dear Listeners,
> 
> Let me know, please, if enclosure monitoring
> is supported for disks attached to Supermicro
> M28SAB drive cages (with two AMI MG9071 chips)
> or similar backplanes. Drives work fine when
> attached to some LSI 2008 controller but there
> appear no "ses* at scsibus?" boot messages
> (see below, disks attached to the drive cage
> are sd4 ... sd11), jumper settings on the cage:
> JP61 2-3: Fan disabled (there is no fan)
> JP62 1-2: Enclosure monitor enabled
> 
> With best regards,
> Jens
> 
> 
> 
> OpenBSD 6.1 (GENERIC.MP) #6: Mon May 22 20:34:30 CEST 2017
> rob...@syspatch-61-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 17154113536 (16359MB)
> avail mem = 16629547008 (15859MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf06f0 (62 entries)
> bios0: vendor American Megatrends Inc. version "0705" date 06/29/2010
> bios0: ASUSTeK Computer INC. P7F-M WS
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
> acpi0: wakeup devices BR1E(S4) UAR1(S4) PS2K(S4) EUSB(S4) USB0(S4) USB1(S4) 
> USB2(S4) USB3(S4) USBE(S4) USB4(S4) USB5(S4) USB6(S4) BR21(S4) BR22(S4) 
> BR23(S4) P0P1(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) Xeon(R) CPU L3426 @ 1.87GHz, 1867.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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: TSC frequency 1867000680 Hz
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 133MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU L3426 @ 1.87GHz, 1866.73 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR
> 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) Xeon(R) CPU L3426 @ 1.87GHz, 1866.73 MHz
> 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR
> 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) Xeon(R) CPU L3426 @ 1.87GHz, 1866.73 MHz
> 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 7 pa 0xfec0, version 20, 24 pins
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 7 (BR1E)
> acpiprt2 at acpi0: bus -1 (BR21)
> acpiprt3 at acpi0: bus -1 (BR22)
> acpiprt4 at acpi0: bus -1 (BR23)
> acpiprt5 at acpi0: bus -1 (P0P1)
> acpiprt6 at acpi0: bus 1 (P0P3)
> acpiprt7 at acpi0: bus -1 (P0P4)
> acpiprt8 at acpi0: bus -1 (P0P5)
> acpiprt9 at acpi0: bus -1 (P0P6)
> acpiprt10 at acpi0: bus 2 (BR20)
> acpiprt11 at acpi0: bus 5 (BR26)
> acpiprt12 at acpi0: bus 6 (BR27)
> acpicpu0 at acpi0: !C3(350@17 mwait.1@0x20), !C3(500@17 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: !C3(350@17 mwait.1@0x20), !C3(500@17 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0: !C3(350@17 mwait.1@0x20), !C3(500@17 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> acpicpu3 at acpi0: !C3(350@17 mwait.1@0x20), !C3(500@17 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> "PNP0501" at acpi0 not configured
> "PNP0303" at acpi0 not configured
> acpibtn0 at acpi0: PWRB
> ipmi at mainbus0 not configured
> cpu0: Enhanced SpeedStep 1867 MHz: speeds: 1868, 1867, 

Help setting up an IKEv2 IPSec Road Warrior VPN on OpenBSD

[thebloggu]

Hello!

I’m trying to build a road warrior style ikev2 ipsec vpn for my home
network on openbsd. The idea is to learn a bit of openbsd since its
something I've been meaning to do for some time now and to setup
a vpn for me to reach my home network as securely as possible
(even if I need to compromise some compatibility, although
macOS/iOS and linux/android support is required).

I’m just starting openbsd from a linux background and I have an idea
of how ipsec works but I don’t have a deep understanding of the
protocol nor do I have a strong network background.

I’m using openiked (which I assume is the standard for ikev2 in
openbsd) and I’ve read the man pages for iked, iked.conf and ikectl.

For setting the vpn up I have some questions, as follows:

I’ve chosen ecdsa ecp256 cipher and I’ll be using either aes-256 with
hmac-sha2-512 or aes-256-gcm.

 * Do you believe these fit my requirements of currently to be believed
   to be the most secure and supporting the systems I mentioned
   earlier? What about aes + hmac vs. aes-gcm?

About the certificates used I assume I can't use ikectl ca command to
issue certificates since it doesn't seem to support ecdsa (please
correct me if I'm wrong) so I copied some issued by an easy-rsa ca as
well as keys to /etc/iked/{private,certs} and the ca to
/etc/iked/ca/ca.crt.

 * Is this enough to make it work?
 * And does the CN of the cert have to be that user's IP address in
   the network? Do they need to have some other setting?

I have the following iked.conf:

> ikev2 "base" from any to any \
>   peer any \
>   ikesa enc aes-256 auth hmac-sha2-512 group ecp256 \
>   childsa enc aes-256 auth hmac-sha2-512 group ecp256 \
>   ecdsa256 \
>   config address  \
>   config name-server  \
>   config access-server 

 * Does this seem to configure iked correctly for my requirements?

 * Do I need to set any rule in pf.conf or change some other system
   setting apart from enabling ip forwarding and esp/ah in sysctl?

 * BTW, do I need something else like MOBIKE I keep hearing about,
   since it’s a road warrior style vpn? If so, how should I configure it?

Thank you for your help.

oss-sec use-after-free after mysql_stmt_close()

[Alceu R. de Freitas Jr.]

Hello folks,
I thought that you might be interested about that, and be glad to know that 
what helped discovering this bug was just setting up and running a CPAN Smoker 
on OpenBSD: this bug wasn't detected before in any other OS that supports Perl 
and DBD::Mysql.
http://seclists.org/oss-sec/2017/q2/443http://wiki.cpantesters.org/wiki/SmokerOnOpenBSD

Cheers,- Alceu

Re: re0 and re1 watchdog timeouts, and system freeze

[Björn Ketelaars]

On Thu 08/06/2017 16:55, Martin Pieuchot wrote:
> On 07/06/17(Wed) 09:43, Björn Ketelaars wrote:
> > On Sat 03/06/2017 08:44, Björn Ketelaars wrote:
> > > 
> > > Reverting back to the previous kernel fixed the issue above. Question: can
> > > someone give a hint on how to track this issue?
> > 
> > After a bit of experimenting I'm able to reproduce the problem. Summary is
> > that queueing in pf and use of a current (after May 30), multi processor
> > kernel (bsd.mp from snapshots) causes these specific watchdog timeouts
> > followed by a system freeze.
> > 
> > Issue is 'gone' when:
> > 1.) using an older kernel (before May 30);
> > 2.) removal of queueing statements from pf.conf. Included below the specific
> > snippet;
> > 3.) switch from MP kernel to SP kernel.
> > 
> > New observation is that while queueing, using a MP kernel, the download
> > bandwidth is only a fraction of what is expected. Exchanging the MP kernel
> > with a SP kernel restores the download bandwidth to expected level.
> > 
> > I'm guessing that this issue is related to recent work on PF?
> 
> It's certainly a problem in, or exposed by, re(4) with the recent MP work
> in the network stack.
> 
> It would help if you could build a kernel with MP_LOCKDEBUG defined and
> see if the resulting kernel enters ddb(4) instead of freezing.
> 
> Thanks,
> Martin

Thanks for the hint! It helped in entering ddb. I collected a bit of output,
which you can find below. If I read the trace correctly the crash is related
to line 1750 of sys/dev/ic/re.c:

d->rl_cmdstat |= htole32(RL_TDESC_CMD_EOF);


ddb{0}> show panic
the kernel did not panic

ddb{0}> trace
db_enter(8196acc0,80002200b8b8,8000e6a8,10,800022023c58
,282) at db_enter+0x9
x86_ipi_handler(8196acd0,819f26a0,14a2d1,c,800022023cd0,fff
f819f95a0) at x86_ipi_handler+0x85
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
--- interrupt ---
___mp_lock(819f26a0,818552f0,1,1,80002200b8b8,8000e
6a8) at ___mp_lock+0x4a
___mp_acquire_count(819f26a0,1,80002200b8b8,8000e6a8,ff
ff81a11680,81707182) at ___mp_acquire_count+0x33
mi_switch(0,0,8000e6a8,800022023ed0,8000e6a8,800022023e
c0) at mi_switch+0x22b
sleep_finish(800022023ed0,1,810b7110,800022023ed0,0,0) at sleep
_finish+0xc2
softclock_thread(8000e6a8,2a2,0,0,29e123d3cabb9a12,800022023f10) at
 softclock_thread+0x94
 end trace frame: 0x0, count: -8

 ddb{0}> machine ddbcpu 1
 Stopped at  re_encap+0x24d: movl0(%r15),%eax

 ddb{1}> show panic
 the kernel did not panic

 ddb{1}> trace
 re_encap(80084000,363,ff00d221cc00,800842c0,400,800
 84000) at re_encap+0x24d
 re_start(800842c0,7,ff00d171d000,80084338,800842c0,
 815fdbf0) at re_start+0x8c
 ifq_serialize(800842c0,80084360,80084090,ff00d2fbd0
 00,800842c0,0) at ifq_serialize+0xf8
 if_enqueue(80084090,ff00d2fbd000,8096a240,ff00d2fbd000,
 37,2) at if_enqueue+0x90
 ether_output(80084090,ff00d171d000,8096a240,ff011b66777
 8,804d1000,8096a240) at ether_output+0x1d6
 ip_output(ff00d171d000,0,800022032cc0,1,0,0) at ip_output+0x8a1
 ip_forward(ff00d171d000,802a4090,0,0,8244c78a,8244c78a) at ip_forwa
 rd+0x1e7
 ipv4_input(802a4090,ff00d171d000,800,800,ff000990ff80,8
 02a4090) at ipv4_input+0x4f7
 ether_input(802a4090,ff00d171d000,0,810afed0,802a42
 88,802a4090) at ether_input+0xbd
 if_input_process(2,800022032eb0,0,0,800022032eb0,80019080) at i
 f_input_process+0xfa
 taskq_thread(80019080,2a2,80019080,81493240,0,80002
 2032f10) at taskq_thread+0x79
 end trace frame: 0x0, count: -11

ddb{1}> dmesg
OpenBSD 6.1-current (GENERIC.MP) #7: Thu Jun  8 19:10:36 CEST 2017
b...@gateway.lan:/home/code/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4245995520 (4049MB)
avail mem = 4111519744 (3921MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (6 entries)
bios0: vendor coreboot version "SageBios_PCEngines_APU-45" date 04/05/2014
bios0: PC Engines APU
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE2
0(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) U
OH5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD G-T40E Processor, 1000.13 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,C
FLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB

booting 6.1

[Friedrich Locke]

Hi folks,

i burnt and install61.iso cd and tried to boot uefi, but could not.
Does anybody know this amd64 6.1 install image support booting UEFI ?

Thanks in advance

SCSI Enclosure Service

[Jens A. Griepentrog]

Dear Listeners,

Let me know, please, if enclosure monitoring
is supported for disks attached to Supermicro
M28SAB drive cages (with two AMI MG9071 chips)
or similar backplanes. Drives work fine when
attached to some LSI 2008 controller but there
appear no "ses* at scsibus?" boot messages
(see below, disks attached to the drive cage
are sd4 ... sd11), jumper settings on the cage:
JP61 2-3: Fan disabled (there is no fan)
JP62 1-2: Enclosure monitor enabled

With best regards,
Jens



OpenBSD 6.1 (GENERIC.MP) #6: Mon May 22 20:34:30 CEST 2017

rob...@syspatch-61-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17154113536 (16359MB)
avail mem = 16629547008 (15859MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf06f0 (62 entries)
bios0: vendor American Megatrends Inc. version "0705" date 06/29/2010
bios0: ASUSTeK Computer INC. P7F-M WS
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
acpi0: wakeup devices BR1E(S4) UAR1(S4) PS2K(S4) EUSB(S4) USB0(S4) 
USB1(S4) USB2(S4) USB3(S4) USBE(S4) USB4(S4) USB5(S4) USB6(S4) BR21(S4) 
BR22(S4) BR23(S4) P0P1(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) Xeon(R) CPU L3426 @ 1.87GHz, 1867.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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 1867000680 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU L3426 @ 1.87GHz, 1866.73 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR

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) Xeon(R) CPU L3426 @ 1.87GHz, 1866.73 MHz
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR

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) Xeon(R) CPU L3426 @ 1.87GHz, 1866.73 MHz
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR

cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 7 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 7 (BR1E)
acpiprt2 at acpi0: bus -1 (BR21)
acpiprt3 at acpi0: bus -1 (BR22)
acpiprt4 at acpi0: bus -1 (BR23)
acpiprt5 at acpi0: bus -1 (P0P1)
acpiprt6 at acpi0: bus 1 (P0P3)
acpiprt7 at acpi0: bus -1 (P0P4)
acpiprt8 at acpi0: bus -1 (P0P5)
acpiprt9 at acpi0: bus -1 (P0P6)
acpiprt10 at acpi0: bus 2 (BR20)
acpiprt11 at acpi0: bus 5 (BR26)
acpiprt12 at acpi0: bus 6 (BR27)
acpicpu0 at acpi0: !C3(350@17 mwait.1@0x20), !C3(500@17 mwait.1@0x10), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C3(350@17 mwait.1@0x20), !C3(500@17 mwait.1@0x10), 
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: !C3(350@17 mwait.1@0x20), !C3(500@17 mwait.1@0x10), 
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: !C3(350@17 mwait.1@0x20), !C3(500@17 mwait.1@0x10), 
C1(1000@1 mwait.1), PSS

"PNP0501" at acpi0 not configured
"PNP0303" at acpi0 not configured
acpibtn0 at acpi0: PWRB
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 1867 MHz: speeds: 1868, 1867, 1733, 1600, 1467, 
1333, 1200 MHz

pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core DMI" rev 0x11
ppb0 at pci0 dev 3 function 0 "Intel Core PCIE" rev 0x11: msi
pci1 at ppb0 bus 1
mpii0 at pci1 dev 0 function 0 "Symbios Logic SAS2008" rev 0x03: msi
mpii0: SAS9210-8i, firmware 16.0.0.0, MPI 2.0
scsibus1 at mpii0: 256 targets
"Intel Core Management" rev 0x11 at pci0 dev 8 function 0 not configured
"Intel Core Scratch" rev 0x11 at pci0 dev 8 function 1 not configured
"Intel Core Control" rev 0x11 at pci0 dev 8 function 2 not configured
"Intel Core Misc" rev 0x11 at pci0 dev 8 function 3 not configured
"Intel Core QPI Link" rev 0x11 at pci0 dev 16 function 0 not configured
"Intel Core QPI 

Re: re0 and re1 watchdog timeouts, and system freeze

[Martin Pieuchot]

On 07/06/17(Wed) 09:43, Björn Ketelaars wrote:
> On Sat 03/06/2017 08:44, Björn Ketelaars wrote:
> > 
> > Reverting back to the previous kernel fixed the issue above. Question: can
> > someone give a hint on how to track this issue?
> 
> After a bit of experimenting I'm able to reproduce the problem. Summary is
> that queueing in pf and use of a current (after May 30), multi processor
> kernel (bsd.mp from snapshots) causes these specific watchdog timeouts
> followed by a system freeze.
> 
> Issue is 'gone' when:
> 1.) using an older kernel (before May 30);
> 2.) removal of queueing statements from pf.conf. Included below the specific
> snippet;
> 3.) switch from MP kernel to SP kernel.
> 
> New observation is that while queueing, using a MP kernel, the download
> bandwidth is only a fraction of what is expected. Exchanging the MP kernel
> with a SP kernel restores the download bandwidth to expected level.
> 
> I'm guessing that this issue is related to recent work on PF?

It's certainly a problem in, or exposed by, re(4) with the recent MP work
in the network stack.

It would help if you could build a kernel with MP_LOCKDEBUG defined and
see if the resulting kernel enters ddb(4) instead of freezing.

Thanks,
Martin

> 
> 
> --- SNIP ---
> 
> # queueing
> #
> queue up on re0 bandwidth 15M max 15M
> queue up_def parent up bandwidth 1M qlimit 10 default
> queue up_dns parent up bandwidth 2M qlimit 20
> queue up_ssh parent up bandwidth 6M qlimit 50
> queue up_web parent up bandwidth 6M qlimit 50
> match on egress set queue up_def
> match out on egress proto {tcp, udp} to port 1:1024 set queue up_web
> match on egress proto tcp to port 22 set queue up_ssh
> match out on egress proto {tcp, udp} to port 53 set queue up_dns
> match on egress proto icmp set queue up_dns
> match out on egress proto tcp to port {119, 563} set queue up_def 
> 
> queue down on re1 bandwidth 150M max 150M
> queue down_def parent down bandwidth 10M qlimit 100 default
> queue down_dns parent down bandwidth 20M qlimit 200
> queue down_ssh parent down bandwidth 60M qlimit 500
> queue down_web parent down bandwidth 60M qlimit 500
> match on re1 set queue down_def
> match in on re1 proto {tcp, udp} to port 1:1024 set queue down_web
> match on re1 proto tcp to port 22 set queue down_ssh
> match in on re1 proto {tcp, udp} to port 53 set queue down_dns
> match on re1 proto icmp set queue down_dns
> match in on re1 proto tcp to port {119, 563} set queue down_def
> 
> --- SNIP ---
> 
> -- 
> Björn Ketelaars
> GPG key: 0x4F0E5F21
> 

Re: Unable to establish ikev2 vpn with ios using current - OpenBSD 6.1 GENERIC.MP#106 amd64 - can anyone help?

[Stuart Henderson]

On 2017-06-07, Theodore Wynnychenko  wrote:
> I have updated to the last several snapshots as they have come out, but 
> continue
> to be unable to establish a VPN between iOS and OpenBSD.  As the iOS device 
> has
> not been updated recently, the "problem" appears to relate to something that
> changed on the OpenBSD side.
..
> I have been a bit remiss, and have not updated my system in a couple of 
> months.
> I have been following current for a year or two, in general, without incident.
>
> Anyway, after updating last night, I am unable to establish a ikev2 vpn with 
> an
> ios 10.3.2 device.  A OBSD6.1<->OBSD6.1 ikev2 vpn is working fine.

Does 6.1 work to your ios device? (fwiw I do have various ios and windows
devices connecting to 6.1 iked here).

Can you work backwards, updating iked source to earlier dates, building and
testing until you find the commit which broke it?

cd /usr/src
cvs up -D 2017/05/01 -P sbin/iked usr.sbin/ikectl
cd sbin/iked
make obj && make && sudo make install
cd ../../usr.sbin/ikectl
make obj && make && sudo make install
(restart iked/test)

Dates to try

2017/04/28
2017/04/25
2017/04/20
2017/04/15

And before this it's 6.1.

Re: nc in inetd - under which account?

[Stuart Henderson]

On 2017-06-07, Marko Cupać  wrote:
> Now as for relayd, I never used it. If someone gave me working example
> and an explanation why it is better than my current solution, I'd be
> glad to switch, and pass the word around :)

When your proxy is nc run from inetd, you have to fork when answering
each connection, and the timeout handling using -w is a complete bodge.

relayd uses a pool of pre-forked processes (quicker connection setup),
and once the connection is setup "socket splicing" is used so shunting
packets between connections is more efficient (zero copy).

But unless you need relayd features (adjusting tcp parameters, checking
that backends are up, etc) it's lighter-weight again to just keep it in
the kernel by using PF as I described.