Re: OpenBSD isakmpd and OS X El Capitan client

[dewey hylton]

Evgeniy Sudyr  gmail.com> writes:

> 
> I'm trying to establish IPSEC tunnel (for future usage with npppd
> L2TP) between -snapshot and OS X El Captain 10.11.5 and have issues
> when establishing phase1.
> 
> I searched in archives and suggestions doesn't work for me. I tried
> main/quick combinations from dumps (below), which make sense.
> 
> Current config is:
> 
> ipsec.conf
> 
> ike passive esp proto from x.x.x.x to any port 1701 \
> main auth hmac-sha1 enc 3des group modp1024 \
> quick auth hmac-sha1 enc 3des \
> psk "XXX"
...
> I tried all proposals from dump I got from both client packets and
> server site with no luck.
> 
> Anybody have success with OS X client and isakmpd? It will be nice to
> see working main and quick config parts.
> 

this is an older configuration, but worked for me:

ike passive esp transport \
proto udp from x.x.x.x to any port 1701 \
main auth "hmac-sha1" enc "aes" group modp1024 \
quick auth "hmac-sha1" enc "aes" group modp1024 \
psk "psk goes here"

pf / queuing / multiple ISP

[Dewey Hylton]

hi all. queueing question here ...

what i have is an openbsd 5.9 firewall with one physical external interface
and one physical internal interface. i have two vlans on the external
interface, each connecting to a different ISP. each ISP provides different
bandwidth.

in an attempt to provide a bit of qos, i've created queues and am assigning
conversations to those queues based on the their simple rules (eg. pass in
quick log proto tcp from  to any port ssh queue ssh). however,
the queues are created on the external physical interface, which means the
queue definitions apply to both ISP connections but only properly fit one of
them.

how would i go about correcting this?

if i create separate queues for each vlan interface to fit the different ISP
connections, it seems i would have to create multiple separate (and more
specific) rules for each allowed conversation. surely there is a smarter way ...

suggestions are welcomed.

Re: ipsec between three networks

[Dewey Hylton]

for us, ospf works fine. and in our testing, bgp was much slower to respond
to
network events. each of our sites has a pair of openbsd boxes clustered via
carp. each site has two different isps. this adds up to quite a few
different paths
to/from each site. on multiple occasions, we've received calls from our
providers
regarding outages on isp links that we use by default (weighted via ospf)
that we
weren't yet aware of because ospf just worked as it should have and nobody
had
noticed. of course, we now monitor such things, but the point is that ospf
has been
great for us in this configuration.

On Thu, Jan 28, 2016 at 2:30 AM, mxb <m...@alumni.chalmers.se> wrote:

> OSPF is not right protocol if you scale to more than 3 sites and want
> influence routing.
> BGP will do a better job in this situation.
>
> On 27 jan. 2016, at 03:39, Dewey Hylton <dewey.hyl...@gmail.com> wrote:
>
> my current working configuration has 3 sites; each site is connected to the
> others, and routing is handled via ospfd.

Re: Working on lpd,etc

[Dewey Hylton]

Chris Bennett  bennettconstruction.us> writes:

> 
> Is anyone still using a printer connected to a serial port or is that now
> removable?
> 
> Chris Bennett

We're still using zebra serial printers ...

Re: ipsec between three networks

[Dewey Hylton]

lilit-aibolit  mail.ru> writes:


> Suppose I have third endpoint in the Internet
> with public IP z.z.z.z and network 192.168.3.0/24.
> What is the way to establish extra tunnel with third endpoint?
> I need to be able to reach $net1 and $net2 networks from
> $net3 with is 192.168.3.0/24 and vice versa.
> 
> Is it enough to create tunnel between $net3 and $net2
> to reach $net1 from $net3 or I need to setup two tunnels
> on each endpoint?

if all sites are not directly connected to each other, you'll have to add
routes in various places.

my current working configuration has 3 sites; each site is connected to the
others, and routing is handled via ospfd. 

Re: compulab fitlet, non-working intel i211 ethernet, help requested

[Dewey Hylton]

On Sat, Oct 31, 2015 at 11:20 AM, Dewey Hylton <dewey.hyl...@gmail.com>
wrote:

> 2015-10-31 10:56 GMT-04:00 Dewey Hylton <dewey.hyl...@gmail.com>:
>
>> On Sat, Oct 31, 2015 at 12:49 AM, Jonathan Gray <j...@jsg.id.au> wrote:
>>
>>> On Fri, Oct 30, 2015 at 11:32:16AM -0400, Dewey Hylton wrote:
>>> > >
>>> > didn't have -current onhand, but was able to perform this function on
>>> a 5.8
>>> > system ... i have 3 of these devices i'd really like to get going on
>>> > openbsd. THANKS!
>>>
>>> ...
>>>
>>> > Invalid PHY ID 0xA0044E90
>>>
>>> This shouldn't be possible, perhaps something isn't powering up
>>> correctly.
>>>
>>> You could try the following patch which will force the id to a known one:
>>>
>>> Index: if_em_hw.c
>>> ===
>>> RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
>>> retrieving revision 1.88
>>> diff -u -p -r1.88 if_em_hw.c
>>> --- if_em_hw.c  12 Sep 2015 02:38:14 -  1.88
>>> +++ if_em_hw.c  31 Oct 2015 04:43:49 -
>>> @@ -5369,6 +5369,9 @@ em_match_gig_phy(struct em_hw *hw)
>>> hw->phy_id |= (uint32_t) (phy_id_low & PHY_REVISION_MASK);
>>> hw->phy_revision = (uint32_t) phy_id_low & ~PHY_REVISION_MASK;
>>>
>>> +   if (hw->phy_id == 0xA0044E90)
>>> +   hw->phy_id = I210_I_PHY_ID;
>>> +
>>> switch (hw->mac_type) {
>>> case em_82543:
>>> if (hw->phy_id == M88E1000_E_PHY_ID)
>>> Index: if_em_osdep.h
>>> ===
>>> RCS file: /cvs/src/sys/dev/pci/if_em_osdep.h,v
>>> retrieving revision 1.12
>>> diff -u -p -r1.12 if_em_osdep.h
>>> --- if_em_osdep.h   5 Oct 2011 02:52:10 -   1.12
>>> +++ if_em_osdep.h   29 Oct 2015 03:27:36 -
>>> @@ -44,7 +44,8 @@ POSSIBILITY OF SUCH DAMAGE.
>>>
>>>  #define MSGOUT(S, A, B)printf(S "\n", A, B)
>>>  #define DEBUGFUNC(F)   DEBUGOUT(F);
>>> -#ifdef DBG
>>> +//#ifdef DBG
>>> +#if 1
>>> #define DEBUGOUT(S) printf(S "\n")
>>> #define DEBUGOUT1(S,A)  printf(S "\n",A)
>>> #define DEBUGOUT2(S,A,B)printf(S "\n",A,B)
>>>
>>
>> THANKS for your time and assistance.
>>
>> i now have enough networking to commence an installation, which is in
>> progress. i'll have to build
>> and copy in a new kernel of course to use the booted system afterward.
>> assuming nothing is shown
>> broken in the dmesg below, what do i need to do in order to get this
>> change (or another fix which
>> would not require this change, if this was just an improper hack)
>> committed?
>>
>>
> HOLD THE PRESSES!
>
> after the installation and reboot, just prior to copying the rebuild
> kernel that was to provide networking,
> i notice that networking is in fact working. so somehow, with regard to
> this specific network interface,
> there was a disparity between bsd.rd and bsd (GENERIC) kernels. i'll try
> to run this through its paces
> with vlans and other such things, but at the moment it looks like GENERIC
> from 5.8 actually works as
> it should without any changes. perhaps it's time to dust off the old usb
> installer sticks and forgo pxe for
> these little devices. at least for the time being ...
>
> is it safe to assume that the disparity between bsd.rd and bsd is due to
> trimming to keep the image at
> a minimum? i know other things are removed from bsd.rd for this purpose
> ... and if not, does this point
> to a bug for which i need to make a report?
>
> thanks again for your assistance, Jonathan!
>
>
>
Jonathan wondered whether the issue was related to trimming of bsd.rd or
possibly
pxe leaving the interface in an incorrect state. the email never came to
me, but i saw
it on the list so i'll reply to this, the last message i do see in my inbox.

i installed 5.8 to a usb stick and used that to boot bsd.rd on the fitlet.
the problem
did not show up there - so the issue must be related to pxe.

if this means i should be reporting somehow, please point me in the right
direction;
i'm not sure if that would be a bug in the pxe code on the interface
firmware or in the
pxeboot code from openbsd. and i'd have no idea how to find the answer.

Re: compulab fitlet, non-working intel i211 ethernet, help requested

[Dewey Hylton]

On Sat, Oct 31, 2015 at 12:49 AM, Jonathan Gray <j...@jsg.id.au> wrote:

> On Fri, Oct 30, 2015 at 11:32:16AM -0400, Dewey Hylton wrote:
> > >
> > didn't have -current onhand, but was able to perform this function on a
> 5.8
> > system ... i have 3 of these devices i'd really like to get going on
> > openbsd. THANKS!
>
> ...
>
> > Invalid PHY ID 0xA0044E90
>
> This shouldn't be possible, perhaps something isn't powering up correctly.
>
> You could try the following patch which will force the id to a known one:
>
> Index: if_em_hw.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
> retrieving revision 1.88
> diff -u -p -r1.88 if_em_hw.c
> --- if_em_hw.c  12 Sep 2015 02:38:14 -  1.88
> +++ if_em_hw.c  31 Oct 2015 04:43:49 -
> @@ -5369,6 +5369,9 @@ em_match_gig_phy(struct em_hw *hw)
> hw->phy_id |= (uint32_t) (phy_id_low & PHY_REVISION_MASK);
> hw->phy_revision = (uint32_t) phy_id_low & ~PHY_REVISION_MASK;
>
> +   if (hw->phy_id == 0xA0044E90)
> +   hw->phy_id = I210_I_PHY_ID;
> +
> switch (hw->mac_type) {
> case em_82543:
> if (hw->phy_id == M88E1000_E_PHY_ID)
> Index: if_em_osdep.h
> ===
> RCS file: /cvs/src/sys/dev/pci/if_em_osdep.h,v
> retrieving revision 1.12
> diff -u -p -r1.12 if_em_osdep.h
> --- if_em_osdep.h   5 Oct 2011 02:52:10 -   1.12
> +++ if_em_osdep.h   29 Oct 2015 03:27:36 -
> @@ -44,7 +44,8 @@ POSSIBILITY OF SUCH DAMAGE.
>
>  #define MSGOUT(S, A, B)printf(S "\n", A, B)
>  #define DEBUGFUNC(F)   DEBUGOUT(F);
> -#ifdef DBG
> +//#ifdef DBG
> +#if 1
> #define DEBUGOUT(S) printf(S "\n")
> #define DEBUGOUT1(S,A)  printf(S "\n",A)
> #define DEBUGOUT2(S,A,B)printf(S "\n",A,B)
>

THANKS for your time and assistance.

i now have enough networking to commence an installation, which is in
progress. i'll have to build
and copy in a new kernel of course to use the booted system afterward.
assuming nothing is shown
broken in the dmesg below, what do i need to do in order to get this change
(or another fix which
would not require this change, if this was just an improper hack)
committed?

dmesg follows:

OpenBSD 5.8-stable (RAMDISK_CD) #1: Sat Oct 31 10:26:43 EDT 2015
root@openbsd-build.uxdev:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 3934593024 (3752MB)
avail mem = 3813629952 (3636MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xecbf0 (62 entries)
bios0: vendor American Megatrends Inc. version "SBCFLT_0.08.04" date
06/27/2015
bios0: CompuLab fitlet
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG ASF! HPET WDRT SSDT SSDT SSDT
SSDT SSDT SSDT SSDT SSDT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD A4 Micro-6400T APU + AMD Radeon R3 Graphics, 998.25 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPC
NT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPI
CSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 6 pa 0xfec01000, version 21, 32 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (GFX_)
acpiprt2 at acpi0: bus -1 (GPP0)
acpiprt3 at acpi0: bus -1 (GPP1)
acpiprt4 at acpi0: bus -1 (GPP2)
acpiprt5 at acpi0: bus 1 (GPP3)
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "AMD", unknown product 0x1566 rev 0x00
vga1 at pci0 dev 1 function 0 vendor "ATI", unknown product 0x9854 rev 0x02
vga1: aperture needed
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
pchb1 at pci0 dev 2 function 0 vendor "AMD", unknown product 0x156b rev 0x00
ppb0 at pci0 dev 2 function 5 "AMD AMD64 16h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel I211" rev 0x03em_set_mac_type
: msiem_init_eeprom_params
em_is_onboard_nvm_eeprom
em_get_flash_presence_i210
em_reset_hw
PCIe completion timeout resend disable

Re: compulab fitlet, non-working intel i211 ethernet, help requested

[Dewey Hylton]

2015-10-31 10:56 GMT-04:00 Dewey Hylton <dewey.hyl...@gmail.com>:

> On Sat, Oct 31, 2015 at 12:49 AM, Jonathan Gray <j...@jsg.id.au> wrote:
>
>> On Fri, Oct 30, 2015 at 11:32:16AM -0400, Dewey Hylton wrote:
>> > >
>> > didn't have -current onhand, but was able to perform this function on a
>> 5.8
>> > system ... i have 3 of these devices i'd really like to get going on
>> > openbsd. THANKS!
>>
>> ...
>>
>> > Invalid PHY ID 0xA0044E90
>>
>> This shouldn't be possible, perhaps something isn't powering up correctly.
>>
>> You could try the following patch which will force the id to a known one:
>>
>> Index: if_em_hw.c
>> ===
>> RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
>> retrieving revision 1.88
>> diff -u -p -r1.88 if_em_hw.c
>> --- if_em_hw.c  12 Sep 2015 02:38:14 -  1.88
>> +++ if_em_hw.c  31 Oct 2015 04:43:49 -
>> @@ -5369,6 +5369,9 @@ em_match_gig_phy(struct em_hw *hw)
>> hw->phy_id |= (uint32_t) (phy_id_low & PHY_REVISION_MASK);
>> hw->phy_revision = (uint32_t) phy_id_low & ~PHY_REVISION_MASK;
>>
>> +   if (hw->phy_id == 0xA0044E90)
>> +   hw->phy_id = I210_I_PHY_ID;
>> +
>> switch (hw->mac_type) {
>> case em_82543:
>> if (hw->phy_id == M88E1000_E_PHY_ID)
>> Index: if_em_osdep.h
>> ===
>> RCS file: /cvs/src/sys/dev/pci/if_em_osdep.h,v
>> retrieving revision 1.12
>> diff -u -p -r1.12 if_em_osdep.h
>> --- if_em_osdep.h   5 Oct 2011 02:52:10 -   1.12
>> +++ if_em_osdep.h   29 Oct 2015 03:27:36 -
>> @@ -44,7 +44,8 @@ POSSIBILITY OF SUCH DAMAGE.
>>
>>  #define MSGOUT(S, A, B)printf(S "\n", A, B)
>>  #define DEBUGFUNC(F)   DEBUGOUT(F);
>> -#ifdef DBG
>> +//#ifdef DBG
>> +#if 1
>> #define DEBUGOUT(S) printf(S "\n")
>> #define DEBUGOUT1(S,A)  printf(S "\n",A)
>> #define DEBUGOUT2(S,A,B)printf(S "\n",A,B)
>>
>
> THANKS for your time and assistance.
>
> i now have enough networking to commence an installation, which is in
> progress. i'll have to build
> and copy in a new kernel of course to use the booted system afterward.
> assuming nothing is shown
> broken in the dmesg below, what do i need to do in order to get this
> change (or another fix which
> would not require this change, if this was just an improper hack)
> committed?
>
>
HOLD THE PRESSES!

after the installation and reboot, just prior to copying the rebuild kernel
that was to provide networking,
i notice that networking is in fact working. so somehow, with regard to
this specific network interface,
there was a disparity between bsd.rd and bsd (GENERIC) kernels. i'll try to
run this through its paces
with vlans and other such things, but at the moment it looks like GENERIC
from 5.8 actually works as
it should without any changes. perhaps it's time to dust off the old usb
installer sticks and forgo pxe for
these little devices. at least for the time being ...

is it safe to assume that the disparity between bsd.rd and bsd is due to
trimming to keep the image at
a minimum? i know other things are removed from bsd.rd for this purpose ...
and if not, does this point
to a bug for which i need to make a report?

thanks again for your assistance, Jonathan!

fresh 5.8 dmesg follows:

OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3934593024 (3752MB)
avail mem = 3811454976 (3634MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xecbf0 (62 entries)
bios0: vendor American Megatrends Inc. version "SBCFLT_0.08.04" date
06/27/2015
bios0: CompuLab fitlet
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG ASF! HPET WDRT SSDT SSDT SSDT
SSDT SSDT SSDT SSDT SSDT
acpi0: wakeup devices LOM_(S4) SBAZ(S4) EHC1(S4) EHC2(S4) EHC3(S4) XHC0(S4)
ODD8(S3)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD A4 Micro-6400T APU + AMD Radeon R3 Graphics, 998.26 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPC
NT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPI
CSP,AMCR8,ABM,SSE4A,MASSE

Re: compulab fitlet, non-working intel i211 ethernet, help requested

[Dewey Hylton]

Jonathan Gray  jsg.id.au> writes:

> > > If you can get the dmesg output of a kernel built with the following
> > > diff it should indicate where the problem is:
> > >
> > > Index: sys/dev/pci/if_em_osdep.h
> > > ===
> > > RCS file: /cvs/src/sys/dev/pci/if_em_osdep.h,v
> > > retrieving revision 1.12
> > > diff -u -p -r1.12 if_em_osdep.h
> > > --- sys/dev/pci/if_em_osdep.h   5 Oct 2011 02:52:10 -   1.12
> > > +++ sys/dev/pci/if_em_osdep.h   29 Oct 2015 03:27:36 -
> > >  -44,7 +44,8  POSSIBILITY OF SUCH DAMAGE.
> > >
> > >  #define MSGOUT(S, A, B)printf(S "\n", A, B)
> > >  #define DEBUGFUNC(F)   DEBUGOUT(F);
> > > -#ifdef DBG
> > > +//#ifdef DBG
> > > +#if 1
> > > #define DEBUGOUT(S) printf(S "\n")
> > > #define DEBUGOUT1(S,A)  printf(S "\n",A)
> > > #define DEBUGOUT2(S,A,B)printf(S "\n",A,B)
> > >
> > 
> > 
> > 
> > 
> > i'll attempt to build a new bsd.rd with this patch and report back.
> > 
> > i've never done this, so it may take a bit of time to work out the
> > details. thanks for the suggestion.
> 
> It would be enough to log the serial output and boot a normal kernel
> with pxe.  Though it seems you may have the "fitlet-B" that doesn't
> have serial unlike the "fitlet-i" and "fitlet-X".  Or perhaps
> the output isn't so verbose that you could transcribe it.

this particular device is the "MintBox mini" with the slower processor.
i have two of these, as well as one fitlet-X with faster processor and
4x gigabit ethernet interfaces. all have serial.

> If you have a spare usb flash drive you could install to that on a
> different machine, put the test kernel on it, then boot it on the
> machine.

i may do that in the near future; before i started leveraging pxe, i
simply carried a usb stick containing a working i386 installation plus
everything needed to install i386/amd64 from their respective bsd.rd
images. but since i started using pxe, i have gotten a bit lazy from
a usb standpoint.

> It takes a while to test changes if you have to run make build and
> make release every time.

for my specific purpose, booting bsd.rd is all i need. i found this 
helpful: http://openbsd.wikia.com/wiki/Creating_a_custom_OpenBSD_RAM_disk

using information from that page, i was able to build a new bsd.rd very
quickly. i still haven't built "everything" yet so have no idea just how
much time i saved - but i'm guessing it was quite a bit.

Re: compulab fitlet, non-working intel i211 ethernet, help requested

[Dewey Hylton]

On Thu, Oct 29, 2015 at 10:15 AM, Dewey Hylton <dewey.hyl...@gmail.com>
wrote:

>
>
> On Wed, Oct 28, 2015 at 11:35 PM, Jonathan Gray <j...@jsg.id.au> wrote:
>
>> On Wed, Oct 28, 2015 at 10:18:26PM -0400, Dewey Hylton wrote:
>> > i like these little boxes; they are silent and stable and perfect for
>> plenty
>> > of my projects. this new version promises to be better than the several
>> fit2
>> > machines i have scattered around customer sites, affording more cores
>> and
>> > memory.
>> >
>> > the man page for em shows the i211 to be supported. this machine uses
>> that
>> > chip, and it is even reported by the kernel - but still does not work.
>> is it
>> > possible that its specific id is simply missing from the driver, or is
>> there
>> > more to it than that?
>> >
>> > i booted the computer via pxe, so the ethernet is clearly working. it
>> > shipped with linux, and networking worked there too.
>> >
>> > of course it'd be nice for all the other bits to be in working order as
>> > well, but at the moment ethernet is the most important for my purposes.
>> >
>> > please let me know what i can do to get this working, or how i can
>> assist
>> > otherwise.
>>
>> If you can get the dmesg output of a kernel built with the following
>> diff it should indicate where the problem is:
>>
>> Index: sys/dev/pci/if_em_osdep.h
>> ===
>> RCS file: /cvs/src/sys/dev/pci/if_em_osdep.h,v
>> retrieving revision 1.12
>> diff -u -p -r1.12 if_em_osdep.h
>> --- sys/dev/pci/if_em_osdep.h   5 Oct 2011 02:52:10 -   1.12
>> +++ sys/dev/pci/if_em_osdep.h   29 Oct 2015 03:27:36 -
>> @@ -44,7 +44,8 @@ POSSIBILITY OF SUCH DAMAGE.
>>
>>  #define MSGOUT(S, A, B)printf(S "\n", A, B)
>>  #define DEBUGFUNC(F)   DEBUGOUT(F);
>> -#ifdef DBG
>> +//#ifdef DBG
>> +#if 1
>> #define DEBUGOUT(S) printf(S "\n")
>> #define DEBUGOUT1(S,A)  printf(S "\n",A)
>> #define DEBUGOUT2(S,A,B)printf(S "\n",A,B)
>>
>
>
>
>
> i'll attempt to build a new bsd.rd with this patch and report back.
>
> i've never done this, so it may take a bit of time to work out the
> details. thanks for the suggestion.
>
>
didn't have -current onhand, but was able to perform this function on a 5.8
system ... i have 3 of these devices i'd really like to get going on
openbsd. THANKS!

dmesg follows:

OpenBSD 5.8-stable (RAMDISK_CD) #0: Fri Oct 30 11:15:47 EDT 2015
root@openbsd-build.uxdev:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 3934593024 (3752MB)
avail mem = 3813629952 (3636MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xecbf0 (62 entries)
bios0: vendor American Megatrends Inc. version "SBCFLT_0.08.04" date
06/27/2015
bios0: CompuLab fitlet
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG ASF! HPET WDRT SSDT SSDT SSDT
SSDT SSDT SSDT SSDT SSDT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD A4 Micro-6400T APU + AMD Radeon R3 Graphics, 998.27 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPC
NT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPI
CSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 6 pa 0xfec01000, version 21, 32 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (GFX_)
acpiprt2 at acpi0: bus -1 (GPP0)
acpiprt3 at acpi0: bus -1 (GPP1)
acpiprt4 at acpi0: bus -1 (GPP2)
acpiprt5 at acpi0: bus 1 (GPP3)
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "AMD", unknown product 0x1566 rev 0x00
vga1 at pci0 dev 1 function 0 vendor "ATI", unknown product 0x9854 rev 0x02
vga1: aperture needed
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
pchb1 at pci0 dev 2 function 0 vendor "AMD", unknown product 0x156b rev 0x00
ppb0 at pci0 dev 2 function 5 "

Re: compulab fitlet, non-working intel i211 ethernet, help requested

[Dewey Hylton]

On Wed, Oct 28, 2015 at 11:35 PM, Jonathan Gray <j...@jsg.id.au> wrote:

> On Wed, Oct 28, 2015 at 10:18:26PM -0400, Dewey Hylton wrote:
> > i like these little boxes; they are silent and stable and perfect for
> plenty
> > of my projects. this new version promises to be better than the several
> fit2
> > machines i have scattered around customer sites, affording more cores and
> > memory.
> >
> > the man page for em shows the i211 to be supported. this machine uses
> that
> > chip, and it is even reported by the kernel - but still does not work.
> is it
> > possible that its specific id is simply missing from the driver, or is
> there
> > more to it than that?
> >
> > i booted the computer via pxe, so the ethernet is clearly working. it
> > shipped with linux, and networking worked there too.
> >
> > of course it'd be nice for all the other bits to be in working order as
> > well, but at the moment ethernet is the most important for my purposes.
> >
> > please let me know what i can do to get this working, or how i can assist
> > otherwise.
>
> If you can get the dmesg output of a kernel built with the following
> diff it should indicate where the problem is:
>
> Index: sys/dev/pci/if_em_osdep.h
> ===
> RCS file: /cvs/src/sys/dev/pci/if_em_osdep.h,v
> retrieving revision 1.12
> diff -u -p -r1.12 if_em_osdep.h
> --- sys/dev/pci/if_em_osdep.h   5 Oct 2011 02:52:10 -   1.12
> +++ sys/dev/pci/if_em_osdep.h   29 Oct 2015 03:27:36 -
> @@ -44,7 +44,8 @@ POSSIBILITY OF SUCH DAMAGE.
>
>  #define MSGOUT(S, A, B)printf(S "\n", A, B)
>  #define DEBUGFUNC(F)   DEBUGOUT(F);
> -#ifdef DBG
> +//#ifdef DBG
> +#if 1
> #define DEBUGOUT(S) printf(S "\n")
> #define DEBUGOUT1(S,A)  printf(S "\n",A)
> #define DEBUGOUT2(S,A,B)printf(S "\n",A,B)
>




i'll attempt to build a new bsd.rd with this patch and report back.

i've never done this, so it may take a bit of time to work out the
details. thanks for the suggestion.

compulab fitlet, non-working intel i211 ethernet, help requested

[Dewey Hylton]

i like these little boxes; they are silent and stable and perfect for plenty
of my projects. this new version promises to be better than the several fit2
machines i have scattered around customer sites, affording more cores and
memory.

the man page for em shows the i211 to be supported. this machine uses that
chip, and it is even reported by the kernel - but still does not work. is it
possible that its specific id is simply missing from the driver, or is there
more to it than that?

i booted the computer via pxe, so the ethernet is clearly working. it
shipped with linux, and networking worked there too.

of course it'd be nice for all the other bits to be in working order as
well, but at the moment ethernet is the most important for my purposes.

please let me know what i can do to get this working, or how i can assist
otherwise.

dmesg follows; sd1 is the thumb drive i used to store the dmesg output:


OpenBSD 5.8-current (RAMDISK_CD) #1392: Wed Oct 28 16:07:09 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 3934593024 (3752MB)
avail mem = 3813629952 (3636MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xecbf0 (62 entries)
bios0: vendor American Megatrends Inc. version "SBCFLT_0.08.04" date
06/27/2015
bios0: CompuLab fitlet
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG ASF! HPET WDRT SSDT SSDT SSDT
SSDT SSDT SSDT SSDT SSDT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD A4 Micro-6400T APU + AMD Radeon R3 Graphics, 998.27 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPC
NT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPI
CSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 6 pa 0xfec01000, version 21, 32 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (GFX_)
acpiprt2 at acpi0: bus -1 (GPP0)
acpiprt3 at acpi0: bus -1 (GPP1)
acpiprt4 at acpi0: bus -1 (GPP2)
acpiprt5 at acpi0: bus 1 (GPP3)
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "AMD", unknown product 0x1566 rev 0x00
vga1 at pci0 dev 1 function 0 vendor "ATI", unknown product 0x9854 rev 0x02
vga1: aperture needed
wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
vendor "ATI", unknown product 0x9840 (class multimedia subclass hdaudio, rev
0x00) at pci0 dev 1 function 1 not configured
pchb1 at pci0 dev 2 function 0 vendor "AMD", unknown product 0x156b rev 0x00
ppb0 at pci0 dev 2 function 5 "AMD AMD64 16h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel I211" rev 0x03: msiem0: Hardware
Initialization Failedem0: Unable to initialize the hardware
vendor "AMD", unknown product 0x1537 (class crypto subclass miscellaneous,
rev 0x00) at pci0 dev 8 function 0 not configured
xhci0 at pci0 dev 16 function 0 vendor "AMD", unknown product 0x7814 rev
0x11: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 "AMD xHCI root hub" rev 3.00/1.00 addr 1
ahci0 at pci0 dev 17 function 0 "AMD Hudson-2 SATA" rev 0x40: msi, AHCI 1.3
ahci0: port 1: 6.0Gb/s
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 1 lun 0:  SCSI3 0/direct
fixed naa.5001b44e703a2201
sd0: 61057MB, 512 bytes/sector, 125045424 sectors, thin
ehci0 at pci0 dev 18 function 0 "AMD Hudson-2 USB2" rev 0x39: apic 5 int 18
usb1 at ehci0: USB revision 2.0
uhub1 at usb1 "AMD EHCI root hub" rev 2.00/1.00 addr 1
ehci1 at pci0 dev 19 function 0 "AMD Hudson-2 USB2" rev 0x39: apic 5 int 18
usb2 at ehci1: USB revision 2.0
uhub2 at usb2 "AMD EHCI root hub" rev 2.00/1.00 addr 1
"AMD Hudson-2 SMBus" rev 0x42 at pci0 dev 20 function 0 not configured
"AMD Hudson-2 HD Audio" rev 0x02 at pci0 dev 20 function 2 not configured
"AMD Hudson-2 LPC" rev 0x11 at pci0 dev 20 function 3 not configured
sdhc0 at pci0 dev 20 function 7 vendor "AMD", unknown product 0x7813 rev
0x01: apic 5 int 16
sdhc0 at 0x10: can't map registers
pchb2 at pci0 dev 24 function 0 vendor "AMD", unknown product 0x1580 rev
0x00
pchb3 at pci0 dev 24 function 1 vendor "AMD", unknown product 0x1581 rev
0x00
pchb4 at pci0 dev 24 function 2 vendor "AMD", unknown product 0x1582 rev
0x00
pchb5 at pci0 dev 24 function 3 vendor "AMD", unknown product 0x1583 rev
0x00
pchb6 at pci0 dev 24 function 4 vendor "AMD", unknown product 0x1584 rev
0x00
pchb7 at pci0 dev 24 function 5 vendor "AMD", unknown product 0x1585 rev

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

ah, well thanks for taking a look.

On Thu, Oct 8, 2015 at 3:09 PM, Mike Larkin <mlar...@azathoth.net> wrote:

> On Wed, Oct 07, 2015 at 11:17:25PM -0400, Dewey Hylton wrote:
> > you missed my update which followed that post. it did not survive the
> night
> > - even with lm disabled in the kernel, some number of reboots later i
> > encountered the same failure. that update is on the list, but i'll
> include
> > the copy/paste below.
> >
> > meanwhile, is there still hope for answers relating to acpi?
> >
>
> I doubt it. I took a look at your AML and it seemed reasonable.
>
> -ml
>
> > -- Forwarded message --
> > From: Dewey Hylton <dewey.hyl...@gmail.com>
> > To: misc@openbsd.org
> > Cc:
> > Date: Tue, 15 Sep 2015 19:19:10 + (UTC)
> > Subject: Re: requesting help working around boot failures with supermicro
> > atom board
> > Dewey Hylton  gmail.com> writes:
> >
> > >
> > > Mark Kettenis  xs4all.nl> writes:
> >
> > > > Oh that is interesting.  Can you try disabling the lm(4) driver in
> > > > your kernel?  You can do:
> > > >
> > > > # config -ef /bsd
> > > > ...
> > > > ukc> disable lm
> > > > 254 lm0 disabled
> > > > 255 lm* disabled
> > > > 256 lm* disabled
> > > > ukc> quit
> > > > Saving modified kernel.
> > > > # reboot
> > > >
> > > > That reboot will probably still hang.  But it'd be interesting to see
> > > > if any subsequent reboots work better.
> > >
> >
> >
> > sadly, the first thing i heard when entering the lab this morning was
> > BEP!
> >
> > so disabling the sensor drivers in the kernel did not do the trick.
> without
> > other ideas, i'm down to providing acpidump output and hoping someone can
> > tell me where to go next ...
> >
> >
> > On Wed, Oct 7, 2015 at 12:41 AM, Mike Larkin <mlar...@azathoth.net>
> wrote:
> >
> > > On Tue, Sep 15, 2015 at 02:45:02AM +, Dewey Hylton wrote:
> > > > Mark Kettenis  xs4all.nl> writes:
> > > >
> > > > >
> > > > > > # sysctl -a|grep 'sensors.*temp'
> > > > > > hw.sensors.cpu0.temp0=30.00 degC
> > > > > > hw.sensors.lm1.temp0=0.00 degC
> > > > > > hw.sensors.lm1.temp1=14.00 degC
> > > > > > hw.sensors.lm1.temp2=14.00 degC
> > > > > > # reboot
> > > > > >
> > > > > > BEEEP!
> > > > >
> > > > > Oh that is interesting.  Can you try disabling the lm(4) driver in
> > > > > your kernel?  You can do:
> > > > >
> > > > > # config -ef /bsd
> > > > > ...
> > > > > ukc> disable lm
> > > > > 254 lm0 disabled
> > > > > 255 lm* disabled
> > > > > 256 lm* disabled
> > > > > ukc> quit
> > > > > Saving modified kernel.
> > > > > # reboot
> > > > >
> > > > > That reboot will probably still hang.  But it'd be interesting to
> see
> > > > > if any subsequent reboots work better.
> > > >
> > > > *this* interests me, and was basically what i was asking in the
> original
> > > > post - except i had no idea what might need to be disabled. one step
> at a
> > > > time, it's been interesting the things that have popped up.
> > > >
> > > > still no idea whether this has anything to do with the seemingly
> > > > openbsd-only issue, but ...
> > > >
> > > > i made this change, booted the new kernel, ran 'cksum /dev/mem' a
> bunch
> > > of
> > > > times in hopes of raising the temperature somewhat (did get to 36C,
> > > which is
> > > > higher than in my previous tests). then i rebooted, and the box came
> > > back up
> > > > without incident.
> > > >
> > > > so i'm going to run through this several times with reboots in every
> 20
> > > > minutes or so and see if it survives the night.
> > > >
> > >
> > > Based on this and my previous email, my recommendation would be to
> disable
> > > lm(4) on this particular machine.

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

you missed my update which followed that post. it did not survive the night
- even with lm disabled in the kernel, some number of reboots later i
encountered the same failure. that update is on the list, but i'll include
the copy/paste below.

meanwhile, is there still hope for answers relating to acpi?

-- Forwarded message --
From: Dewey Hylton <dewey.hyl...@gmail.com>
To: misc@openbsd.org
Cc:
Date: Tue, 15 Sep 2015 19:19:10 + (UTC)
Subject: Re: requesting help working around boot failures with supermicro
atom board
Dewey Hylton  gmail.com> writes:

>
> Mark Kettenis  xs4all.nl> writes:

> > Oh that is interesting.  Can you try disabling the lm(4) driver in
> > your kernel?  You can do:
> >
> > # config -ef /bsd
> > ...
> > ukc> disable lm
> > 254 lm0 disabled
> > 255 lm* disabled
> > 256 lm* disabled
> > ukc> quit
> > Saving modified kernel.
> > # reboot
> >
> > That reboot will probably still hang.  But it'd be interesting to see
> > if any subsequent reboots work better.
>


sadly, the first thing i heard when entering the lab this morning was
BEP!

so disabling the sensor drivers in the kernel did not do the trick. without
other ideas, i'm down to providing acpidump output and hoping someone can
tell me where to go next ...


On Wed, Oct 7, 2015 at 12:41 AM, Mike Larkin <mlar...@azathoth.net> wrote:

> On Tue, Sep 15, 2015 at 02:45:02AM +, Dewey Hylton wrote:
> > Mark Kettenis  xs4all.nl> writes:
> >
> > >
> > > > # sysctl -a|grep 'sensors.*temp'
> > > > hw.sensors.cpu0.temp0=30.00 degC
> > > > hw.sensors.lm1.temp0=0.00 degC
> > > > hw.sensors.lm1.temp1=14.00 degC
> > > > hw.sensors.lm1.temp2=14.00 degC
> > > > # reboot
> > > >
> > > > BEEEP!
> > >
> > > Oh that is interesting.  Can you try disabling the lm(4) driver in
> > > your kernel?  You can do:
> > >
> > > # config -ef /bsd
> > > ...
> > > ukc> disable lm
> > > 254 lm0 disabled
> > > 255 lm* disabled
> > > 256 lm* disabled
> > > ukc> quit
> > > Saving modified kernel.
> > > # reboot
> > >
> > > That reboot will probably still hang.  But it'd be interesting to see
> > > if any subsequent reboots work better.
> >
> > *this* interests me, and was basically what i was asking in the original
> > post - except i had no idea what might need to be disabled. one step at a
> > time, it's been interesting the things that have popped up.
> >
> > still no idea whether this has anything to do with the seemingly
> > openbsd-only issue, but ...
> >
> > i made this change, booted the new kernel, ran 'cksum /dev/mem' a bunch
> of
> > times in hopes of raising the temperature somewhat (did get to 36C,
> which is
> > higher than in my previous tests). then i rebooted, and the box came
> back up
> > without incident.
> >
> > so i'm going to run through this several times with reboots in every 20
> > minutes or so and see if it survives the night.
> >
>
> Based on this and my previous email, my recommendation would be to disable
> lm(4) on this particular machine.

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Dewey Hylton  gmail.com> writes:

> 
> Mike Larkin  azathoth.net> writes:
> 
> > 
> > On Tue, Sep 15, 2015 at 07:16:40PM +, Dewey Hylton wrote:
> > > Dewey Hylton  gmail.com> writes:
> > > 
> > > > 
> > > > Mike Larkin  azathoth.net> writes:
> > > 
> > > > > acpidump please.

> motherboard: supermicro x7spe-hf-d525 rev 1.0
> bios: 1.2b
> 
> at the end of this link is an archive containing acpidump output for all
> three acpi settings in the bios (1.0, 2.0, 3.0). 
> 
> https://goo.gl/tWGL6C
> 
> i apologize for the somewhat hidden link; gmane wouldn't allow me to post
> the full link because it's greater than 80 characters.
> 
> please let me know if i can help in any way; i honestly know nothing about
> acpi but am willing to learn or assist otherwise if it means understanding
> and potentially fixing this issue.

i was able to export the DSDT files into something human-readable. while i
don't really understand much of what i'm seeing in the resulting text files,
diff shows that the differences between the three acpi versions are
nonexistent. i have no idea about the other files, of which there are several.

Mike, does the acpidump output help at all? if not, am i simply at the point
where this hardware is not compatible with OpenBSD?

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Mike Larkin  azathoth.net> writes:

> 
> On Tue, Sep 15, 2015 at 07:16:40PM +0000, Dewey Hylton wrote:
> > Dewey Hylton  gmail.com> writes:
> > 
> > > 
> > > Mike Larkin  azathoth.net> writes:
> > 
> > > > acpidump please.
> > > 
> > > my pleasure:
> > > 
> > > [demime removed a uuencoded section named
> > supermicro-X7SPE-HF-D525-acpidump.tgz which was 276 lines]
> > > 
> > > 
> > 
> > alright ... so this didn't work. i'll try to make the acpidump available via
> > another site somewhere. on that note, the bios allows selection between acpi
> > 1/2/3 - would it help at all to have acpidump for each of those three
settings?
> > 
> 
> Sure.
> 
> 

motherboard: supermicro x7spe-hf-d525 rev 1.0
bios: 1.2b

at the end of this link is an archive containing acpidump output for all
three acpi settings in the bios (1.0, 2.0, 3.0). 

https://goo.gl/tWGL6C

i apologize for the somewhat hidden link; gmane wouldn't allow me to post
the full link because it's greater than 80 characters.

please let me know if i can help in any way; i honestly know nothing about
acpi but am willing to learn or assist otherwise if it means understanding
and potentially fixing this issue.

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Dewey Hylton  gmail.com> writes:

> 
> Mark Kettenis  xs4all.nl> writes:

> > Oh that is interesting.  Can you try disabling the lm(4) driver in
> > your kernel?  You can do:
> > 
> > # config -ef /bsd
> > ...
> > ukc> disable lm
> > 254 lm0 disabled
> > 255 lm* disabled
> > 256 lm* disabled
> > ukc> quit
> > Saving modified kernel.
> > # reboot
> > 
> > That reboot will probably still hang.  But it'd be interesting to see
> > if any subsequent reboots work better.
> 


sadly, the first thing i heard when entering the lab this morning was BEP!

so disabling the sensor drivers in the kernel did not do the trick. without
other ideas, i'm down to providing acpidump output and hoping someone can
tell me where to go next ...

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Dewey Hylton  gmail.com> writes:

> 
> Mike Larkin  azathoth.net> writes:

> > acpidump please.
> 
> my pleasure:
> 
> [demime removed a uuencoded section named
supermicro-X7SPE-HF-D525-acpidump.tgz which was 276 lines]
> 
> 

alright ... so this didn't work. i'll try to make the acpidump available via
another site somewhere. on that note, the bios allows selection between acpi
1/2/3 - would it help at all to have acpidump for each of those three settings?

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Patrick Dohman  comcast.net> writes:

> 
> Any thermal settings in the bios? CPU performance, Fan Speed etc..
> 
> Does the fan idle correctly? Often intel chipsets will throttle the fan
during a bios test.
> 
> Perhaps ACPI is not routing an interrupt??

Not much is available to be tweaked in this particular setup, though i do
have the options of acpi 1, 2, 3. changing those doesn't appear to result in
any difference.

regarding ACPI not routing an interrupt ... can you be more specific? is
there some way i could test this?

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Kurt Mosiejczuk  se.rit.edu> writes:

> 
> On Sat, Sep 12, 2015 at 03:51:36PM +0000, Dewey Hylton wrote:
> 
> > the only real differences i see are:
> > 1) bios revision
> > 2) secondary disk attached to different sata port
> > 3) sensors only present on working machine
> 
> I've had this issue with the same systems.  Never guessed it would be OpenBSD
> specific.  What I've found to make it stop happening is pulling the board
> out and redoing the thermal paste for the CPU heatsink.  I had found 
> some reference indicating that the alarm I got might be because of
overheating.
> 
> The difference between the boxes may be the attention to detail the factory
> worker who put it together had that day.
> 
> Hearing that Linux doesn't trip it, I'm wondering if it's an ACPI difference
> between OpenBSD and Linux.  Perhaps OpenBSD runs the CPU hotter before
> turning it back over to the BIOS on reboot?
> 
> --Kurt

this is great information; thanks. any idea where the temperature reference
can be found?

i may be able to log the cpu temperature in both operating systems in order
to compare ...

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Kurt Mosiejczuk  se.rit.edu> writes:

> 
> On Mon, Sep 14, 2015 at 05:15:01PM +0000, Dewey Hylton wrote:
> 
> > > I've had this issue with the same systems.  Never guessed it would
> > > be OpenBSD specific.  What I've found to make it stop happening is
> > > pulling the board out and redoing the thermal paste for the CPU
> > > heatsink.  I had found some reference indicating that the alarm I
> > > got might be because of overheating.
> 
> > > The difference between the boxes may be the attention to detail the
> > > factory worker who put it together had that day.
> 
> > > Hearing that Linux doesn't trip it, I'm wondering if it's an ACPI
> > > difference between OpenBSD and Linux.  Perhaps OpenBSD runs the CPU
> > > hotter before turning it back over to the BIOS on reboot?
> 
> > this is great information; thanks. any idea where the temperature
> > reference can be found?
> 
> I don't remember, it was at least a couple years ago.  It was only one
> reference too.  Most talked about listening to beep codes, which this
> wasn't really beep codes...
> 
> > i may be able to log the cpu temperature in both operating systems in
> > order to compare ...
> 
> Possibly, but noticed I said "before turning it back over to the BIOS".
> If it's a difference in OS shutdown, it will be difficult to log the
> temperature.
> 
> --Kurt

understood, but i did uncover something that might provide a hint ... i
haven't duplicated the results more than half a dozen times, but so far it's
been consistent:

after first booting openbsd, i see the following output:

# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=31.00 degC
hw.sensors.lm1.temp0=48.00 degC
hw.sensors.lm1.temp1=52.50 degC
hw.sensors.lm1.temp2=36.00 degC
# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=30.00 degC
hw.sensors.lm1.temp0=48.00 degC
hw.sensors.lm1.temp1=52.50 degC
hw.sensors.lm1.temp2=36.00 degC
# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=31.00 degC
hw.sensors.lm1.temp0=48.00 degC
hw.sensors.lm1.temp1=52.50 degC
hw.sensors.lm1.temp2=36.00 degC
# reboot

and meet with success ... if i wait just a few minutes (2) i end up with this:

# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=30.00 degC
hw.sensors.lm1.temp0=48.00 degC
hw.sensors.lm1.temp1=52.00 degC
hw.sensors.lm1.temp2=35.50 degC
# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=30.00 degC
hw.sensors.lm1.temp0=0.00 degC
hw.sensors.lm1.temp1=14.00 degC
hw.sensors.lm1.temp2=14.00 degC
# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=30.00 degC
hw.sensors.lm1.temp0=0.00 degC
hw.sensors.lm1.temp1=14.00 degC
hw.sensors.lm1.temp2=14.00 degC
# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=30.00 degC
hw.sensors.lm1.temp0=0.00 degC
hw.sensors.lm1.temp1=14.00 degC
hw.sensors.lm1.temp2=14.00 degC
# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=30.00 degC
hw.sensors.lm1.temp0=0.00 degC
hw.sensors.lm1.temp1=14.00 degC
hw.sensors.lm1.temp2=14.00 degC
# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=30.00 degC
hw.sensors.lm1.temp0=0.00 degC
hw.sensors.lm1.temp1=14.00 degC
hw.sensors.lm1.temp2=14.00 degC
# reboot

BEEEP!

again, not a very scientific/exacting approach, but half a dozen times i've
seen the same results. i don't know what it is that trips up the sensors,
but that's when i seem to have the issue.

now, this is running the 5.4 installation (i downgraded at someone's
suggestion for testing) and i can easily reinstall from current snapshot to
see if this may be an unrelated bug.

but until then, does this scenario make sense to anyone?

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Mike Larkin  azathoth.net> writes:

> 
> On Fri, Sep 11, 2015 at 06:38:23PM -0400, dewey.hylton  gmail.com wrote:
> > hi all. i???m having difficulty with this board:
> > 
> > Supermicro X7SPE-HD-D525 rev1
> > 
> > i have several similar systems, each running an older version of OpenBSD
for a few years without incident.
> except this one ???
> > 
> > running OpenBSD 5.7 i386, from cold start it boots just fine and runs
until rebooted. once rebooted,
> however, prior to anything being displayed (i assume this is early in the
bios post phase) i get one very
> long beep. super micro tells me this indicates inability to correctly
initialize the memory. okay, so
> i???ve changed memory for known working components and have the same
issue. at this point, the only thing
> that gets me booting again is to remove power and then restore power. it
then boots fine from cold start, and
> fails on the next reboot (as in, ???reboot??? from the command line). once
in long-beep failure mode,
> neither the hardware reset button nor the power button can make the
machine boot again. the only thing that
> works is removing power. every once in a while it will reboot s
>  uccessfully, only to fail in the same manner on the next attempt.
> > 
> > super micro has had me flash bios, clear cmos, boot from different
devices and with nothing connected,
> etc. the results are the same: when rebooting from openbsd, next boot
fails until power is
> removed/restored. super micro blames openbsd.
> > 
> > i installed linux (same hardware, overwrite openbsd 5.7) and scheduled a
reboot every 5 minutes and left
> it overnight. i logged 554 successful reboots.
> > 
> > i have since installed the latest available openbsd amd64 snapshot, and
am seeing the same failures.
> > 
> > i???m wondering if something could be disabled (boot -c ?) or if
something else raises a red flag and might
> have a workaround. this has me stumped. i would very much appreciate a
clue stick. 
> > 
> > dmesg follows:
> > 
> 
> acpidump please.

my pleasure:

[demime removed a uuencoded section named supermicro-X7SPE-HF-D525-acpidump.tgz 
which was 276 lines]

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Dewey Hylton  gmail.com> writes:



> # sysctl -a|grep 'sensors.*temp'
> hw.sensors.cpu0.temp0=31.00 degC
> hw.sensors.lm1.temp0=48.00 degC
> hw.sensors.lm1.temp1=52.50 degC
> hw.sensors.lm1.temp2=36.00 degC
> # reboot
> 
> and meet with success ... if i wait just a few minutes (2) i end up with this:
> 
> # sysctl -a|grep 'sensors.*temp'
> hw.sensors.cpu0.temp0=30.00 degC
> hw.sensors.lm1.temp0=48.00 degC
> hw.sensors.lm1.temp1=52.00 degC
> hw.sensors.lm1.temp2=35.50 degC
> # sysctl -a|grep 'sensors.*temp'
> hw.sensors.cpu0.temp0=30.00 degC
> hw.sensors.lm1.temp0=0.00 degC
> hw.sensors.lm1.temp1=14.00 degC
> hw.sensors.lm1.temp2=14.00 degC
> # sysctl -a|grep 'sensors.*temp'
> hw.sensors.cpu0.temp0=30.00 degC
> hw.sensors.lm1.temp0=0.00 degC
> hw.sensors.lm1.temp1=14.00 degC
> hw.sensors.lm1.temp2=14.00 degC
> # sysctl -a|grep 'sensors.*temp'
> hw.sensors.cpu0.temp0=30.00 degC
> hw.sensors.lm1.temp0=0.00 degC
> hw.sensors.lm1.temp1=14.00 degC
> hw.sensors.lm1.temp2=14.00 degC
> # sysctl -a|grep 'sensors.*temp'
> hw.sensors.cpu0.temp0=30.00 degC
> hw.sensors.lm1.temp0=0.00 degC
> hw.sensors.lm1.temp1=14.00 degC
> hw.sensors.lm1.temp2=14.00 degC
> # sysctl -a|grep 'sensors.*temp'
> hw.sensors.cpu0.temp0=30.00 degC
> hw.sensors.lm1.temp0=0.00 degC
> hw.sensors.lm1.temp1=14.00 degC
> hw.sensors.lm1.temp2=14.00 degC
> # reboot
> 
> BEEEP!
> 
> again, not a very scientific/exacting approach, but half a dozen times i've
> seen the same results. i don't know what it is that trips up the sensors,
> but that's when i seem to have the issue.
> 
> now, this is running the 5.4 installation (i downgraded at someone's
> suggestion for testing) and i can easily reinstall from current snapshot to
> see if this may be an unrelated bug.
> 
> but until then, does this scenario make sense to anyone?

i now have a fresh install of current/amd64. the snapshot appears to be a
bit on the broken side, as some of the libcrypto/libssl stuff is missing
(this on both i386 and amd64 snapshots) and this prevents me from logging in
via ssh and copy/pasting from terminal. i see this has been reported on the
list already, so a newer snapshot (tomorrow?) may fix this.

but still i have several -current boots under my belt, and the sysctl
temperature thing appears to be similar to what it was with the 5.4
installation. the lm temps are showing negative numbers instead of 0 and 14,
but once that happens the box fails to reboot properly as before.

one other thing i've noticed now that i've reinstalled so many times in the
past few days: it does not matter how long i've been booted into the ramdisk
kernel for installation or whatever - it can sit for hours, and always
reboots properly. no support for sensors in the ramdisk kernel. coincidence?

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Mark Kettenis  xs4all.nl> writes:

> 
> > # sysctl -a|grep 'sensors.*temp'
> > hw.sensors.cpu0.temp0=30.00 degC
> > hw.sensors.lm1.temp0=0.00 degC
> > hw.sensors.lm1.temp1=14.00 degC
> > hw.sensors.lm1.temp2=14.00 degC
> > # reboot
> > 
> > BEEEP!
> 
> Oh that is interesting.  Can you try disabling the lm(4) driver in
> your kernel?  You can do:
> 
> # config -ef /bsd
> ...
> ukc> disable lm
> 254 lm0 disabled
> 255 lm* disabled
> 256 lm* disabled
> ukc> quit
> Saving modified kernel.
> # reboot
> 
> That reboot will probably still hang.  But it'd be interesting to see
> if any subsequent reboots work better.

*this* interests me, and was basically what i was asking in the original
post - except i had no idea what might need to be disabled. one step at a
time, it's been interesting the things that have popped up.

still no idea whether this has anything to do with the seemingly
openbsd-only issue, but ...

i made this change, booted the new kernel, ran 'cksum /dev/mem' a bunch of
times in hopes of raising the temperature somewhat (did get to 36C, which is
higher than in my previous tests). then i rebooted, and the box came back up
without incident.

so i'm going to run through this several times with reboots in every 20
minutes or so and see if it survives the night.

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Sonic  gmail.com> writes:

> On Sun, Sep 13, 2015 at 10:15 AM, Sonic  gmail.com> wrote:
> > I also have this issue with OpenBSD on this box. Every time I reboot
> > after updating a snapshot I need to power cycle to eliminate the long
> > beep error. For some reason I kept thinking it was due to my replacing
> > the stock PSU with a picoPSU for silent operation as a BIOS upgrade
> > did not solve the issue. Never had this problem with the previous
> > generation D510 based systems, only this D525 based version.
> 
> My mistake - the board I have trouble with is the X7SPE-HF-D525 and
> not the X7SPA-HF-D525.

this is the same board i have (X7SPE-HF-D525). what board and bios revision
do you have? my board is rev 1.0 and bios is 1.2b.

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Richard Laysell  xiphosura.co.uk> writes:

> 
> On Fri, 11 Sep 2015 18:38:23 -0400 (EDT)
> "dewey.hylton  gmail.com"  gmail.com> wrote:
> 
> > hi all. i’m having difficulty with this board:
> > 
> > Supermicro X7SPE-HD-D525 rev1
> > 
> > i have several similar systems, each running an older version of
> > OpenBSD for a few years without incident. except this one …
> > 
> 
> 
> Do you have Quick Boot enabled in the BIOS?  If so, try disabling it.
> 
> I have known this cause problems (on other boards - no experience with
> this one).  Quick Boot seems to do a quick and dirty setup and
> doesn't fully initialise all of the devices.  This may be why you are
> seeing it boot OK if you remove the power - the devices then either get
> reset to their default states or the BIOS has to set them up.
> 
> Regards,
> 
> Richard

i have indeed disabled quick/quiet boot options to no avail. i've also tried
failsafe mode, ide vs ahci, acpi v1/2/3. the issue does not present with
linux, which makes me wonder whether the openbsd kernel is somehow making
some kind of hardware setting change that is not cleared on reboot. despite
this only presenting in openbsd, i still blame hardware - but am hoping
there might be some openbsd-related tweak.

thanks for the idea.

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

  wrant.com> writes:

> 
> > Whether they are identical or not, showing us a dmesg diff with a known
> > working release booted from both a working and the non-working system
> > could also be helpful.
> 
> Another Supermicro X7SPA-HF-D525 board (same chipset/CPU combination)
> has been having the same issue since early 2011 (the entire life span
> of the system), always running a recent snapshot:
> 
> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA-HF-D525.cfm
> 
> There is absolutely no sense in running a 2010 snapshot now, except for
> experiments as suggested by Benny.
> 
> Please try and see if it makes a difference comparing reboots of the
> system over SSH, on the local console, over serial console, and with
> serial over LAN. I can provide test results over all these methods
> given some tech suggestion / solution.
> 
> You may want to have a DMI / PCI / ACPI dumps, let me know how / if you
> want these from my system too (attach brief newbie instructions please).
> 
> So far, nothing has solved it yet for me too, except power cycle via the
> PSU breaker each time this happens. Never tried any other OS except
> OpenBSD, thought it was the hardware (memory by the beep code) fault,
> but it's not (confirmed with long runs of memtest). The system
> runs for very long intervals without any other issues, except the
> reboot behaviour in the original post, confirming same problem. Running
> latest BIOS and IPMI firmwares.
> 
> Thanks, Dewey for testing this more extensively than I had the nerve to.

this is great information, and i've passed it along to supermicro as a "i'm
not the only one with this issue" datapoint.

since i'm apparently not alone, this looks more like a board/firmware design
issue - just curious why none of my other boards have this issue.

i'm not knowledgeable enough to provide newbie instructions on the dumps,
but if doing this makes sense to anyone here with more hardware experience
i'm certainly willing to try it.

regarding the comparison of reboots, do you mean testing reboots initiated
via different means (ssh/console/etc.)? if so, i've done that and ruled them
out. last test was a shell script with sleep/reboot commands which executed
via rc.local - meaning there was no user login prior to the failure.

thanks for this information.

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Benny Lofgren  lofgren.biz> writes:

> 
> Hi Dewey,
> 
> On 2015-09-12 00:38, dewey.hylton  gmail.com wrote:
> > hi all. i’m having difficulty with this board:
> 
> I noticed your mail somehow got posted twice, but I'm commenting on the
> first incarnation of it because the second had some characters like '\''
> mangled (UTF-8 copy/paste issue I presume).

i posted first via my normal zimbra server, which seemed to have gotten
hung up so i copied/pasted into the gmail web interface. i think the
second to show up may have been the original (via zimbra). no idea why
there's an issue. i only get daily digests via email so i'm posting this
via the gmane interface; if this doesn't work correctly i'll have to sit
down and figure out the best way to do this in the future.
> 
> > Supermicro X7SPE-HD-D525 rev1
> > i have several similar systems, each running an older version of OpenBSD
for a few years without incident.
> except this one …
> 
> You might already have tried this, but providing this information may
> give important clues to the rest of us trying to help you:
> 
> Since you say that your other similar systems are successfully running
> older versions of OpenBSD, have you tried running this new system with a
> version that you know works on the other boards?

i just installed 5.4 on this board, just as is running on its original
cluster mate (which is still running fine). same issue.

> 
> And if so, then have you tried moving on to subsequent versions in turn
> until you find the one which breaks? That is a really important piece of
> information.
> 
> Also, are those other systems "similar" or "identical"? If not
> identical, what differs? This is also important to get a grip on the
> problem.

these are identical in all ways, except for the current bios version
(which supermicro had me to update when troubleshooting). i'll attempt
to back it down to the same version present on the working board and 
see where that gets me.

> 
> Whether they are identical or not, showing us a dmesg diff with a known
> working release booted from both a working and the non-working system
> could also be helpful.

i'll post the diff below.
> 
> Regards,
> 
> /Benny

thanks for your input. i was shocked to find that linux didn't produce
this issue as well; i don't understand how a failure for a board to 
post could have anything to do with an os which is not running during
the post. that may just show how much i (don't) understand the hardware
and bios side of things.

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

John E.P. Hynes  hytronix.com> writes:

> 
> Try booting the SP kernel and see if that works.  If it does, you might
> be running into a variant of an issie I've had on my SuperMicro boxen...
> 
> -John

john, i tried this (5.4 bsd.sp) and i'm seeing the same result. it didn't
occur to me to try this; thanks for the idea.

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Dewey Hylton  gmail.com> writes:

> > Whether they are identical or not, showing us a dmesg diff with a known
> > working release booted from both a working and the non-working system
> > could also be helpful.
> 
> i'll post the diff below.

the only real differences i see are:
1) bios revision
2) secondary disk attached to different sata port
3) sensors only present on working machine

i'm having a hard time finding the older bios on the supermicro site, so i'm
reaching out to them.

i'm ignoring the disk channel difference.

i'm looking into the sensors - haven't found that in the bios yet.

here's the diff:

$ diff inf1.dmesg.54i inf2.dmesg.54i.good
8,9c8,9
< bios0 at mainbus0: AT/286+ BIOS, date 07/19/13, BIOS32 rev. 0 @ 0xf0010,
SMBIOS rev. 2.6 @ 0x9ac00 (19 entries)
< bios0: vendor American Megatrends Inc. version "1.2b" date 07/19/13
---
> bios0 at mainbus0: AT/286+ BIOS, date 02/21/12, BIOS32 rev. 0 @ 0xf0010,
SMBIOS rev. 2.6 @ 0x9ac00 (19 entries)
> bios0: vendor American Megatrends Inc. version "1.2a" date 02/21/12
18c18
< cpu0: apic clock running at 200MHz
---
> cpu0: apic clock running at 199MHz
20c20
< cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class) 1.81 GHz
---
> cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz
23c23
< cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class) 1.81 GHz
---
> cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz
26c26
< cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class) 1.81 GHz
---
> cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz
43c43
< bios0: ROM list: 0xc/0x8000 0xc8000/0x1000
---
> bios0: ROM list: 0xc/0x8000
57c57
< em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
0c:c4:7a:54:90:8e
---
> em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
00:25:90:97:49:e0
60c60
< em1 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
0c:c4:7a:54:90:8f
---
> em1 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
00:25:90:97:49:e1
75c75
< sd0 at scsibus0 targ 0 lun 0: <ATA, M4-CT128M4SSD2, 040H> SCSI3 0/direct
fixed naa.500a07510920882c
---
> sd0 at scsibus0 targ 0 lun 0: <ATA, M4-CT128M4SSD2, 040H> SCSI3 0/direct
fixed naa.500a075109208807
77c77
< sd1 at scsibus0 targ 2 lun 0: <ATA, Samsung SSD 840, EXT0> SCSI3 0/direct
fixed naa.50025388500930cc
---
> sd1 at scsibus0 targ 5 lun 0: <ATA, Samsung SSD 840, EXT0> SCSI3 0/direct
fixed naa.50025388a01274c6
107a108
> lm2 at wbsio0 port 0xca0/8: W83627DHG
109a111
> lm1: disabling sensors due to alias with lm2
118a121,138
> uhub8 at uhub5 port 1 "ATEN International product 0x8021" rev 1.10/1.00 addr 2
> uhidev2 at uhub8 port 1 configuration 1 interface 0 "ATEN International
Co. Ltd GCS1808 V3.2.313" rev 1.10/1.00 addr 3
> uhidev2: iclass 3/1
> ukbd1 at uhidev2: 8 variable keys, 6 key codes
> wskbd2 at ukbd1 mux 1
> wskbd2: connecting to wsdisplay0
> uhidev3 at uhub8 port 1 configuration 1 interface 1 "ATEN International
Co. Ltd GCS1808 V3.2.313" rev 1.10/1.00 addr 3
> uhidev3: iclass 3/1, 2 report ids
> uhid0 at uhidev3 reportid 1: input=2, output=0, feature=0
> uhid1 at uhidev3 reportid 2: input=1, output=0, feature=0
> uhidev4 at uhub8 port 1 configuration 1 interface 2 "ATEN International
Co. Ltd GCS1808 V3.2.313" rev 1.10/1.00 addr 3
> uhidev4: iclass 3/1
> ums1 at uhidev4: 5 buttons, Z dir
> wsmouse1 at ums1 mux 0
> uhidev5 at uhub8 port 1 configuration 1 interface 3 "ATEN International
Co. Ltd GCS1808 V3.2.313" rev 1.10/1.00 addr 3
> uhidev5: iclass 3/1
> ums2 at uhidev5: 3 buttons, Z dir
> wsmouse2 at ums2 mux 0
123c143,147
< root on sd0a (22cb25880c08c19f.a) swap on sd0b dump on sd0b
---
> root on sd0a (3a0229e574e4bfd1.a) swap on sd0b dump on sd0b

requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

hi all. i’m having difficulty with OpenBSD on this board:

Supermicro X7SPE-HD-D525 rev1

i have several similar systems, each running an older version of OpenBSD
for a few years without incident. except this one …

running OpenBSD 5.7 i386 as well as latest amd64 snapshot, from cold start
it boots just fine and runs until rebooted. once rebooted, however, prior
to anything being displayed (i assume this is early in the bios post phase)
i get one very long beep. super micro tells me this indicates inability to
correctly initialize the memory. okay, so i’ve changed memory for known
working components and have the same issue. at this point, the only thing
that gets me booting again is to remove power and then restore power. it
then boots fine from cold start, and fails on the next reboot (as in,
“reboot” from the command line). once in long-beep failure mode, neither
the hardware reset button nor the power button can make the machine boot
again. the only thing that works is removing power. every once in a while
it will reboot successfully, only to fail in the same manner on the next
attempt.

super micro has had me flash bios, clear cmos, boot from different devices
and with nothing connected, etc. the results are the same: when rebooting
from openbsd, next boot fails until power is removed/restored. super micro
blames openbsd.

i installed linux (same hardware, overwrite openbsd 5.7) and scheduled a
reboot every 5 minutes and left it overnight. i logged 554 successful
reboots.

i’m wondering if something could be disabled (boot -c ?) or if something
else raises a red flag and might have a workaround. this has me stumped. i
would very much appreciate a clue stick.

dmesg follows:

OpenBSD 5.8-current (GENERIC.MP) #1364: Wed Sep  9 17:32:01 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4277665792  (4079MB)
avail mem = 4144070656  (3952MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET EINJ BERT ERST HEST
acpi0: wakeup devices P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4)
USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4) P0P4(S4) P0P5(S4)
P0P6(S4) P0P7(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) Atom(TM) CPU D525 @ 1.80GHz, 1800.23 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,
CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 512KB 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 199MHz
cpu0: mwait min=64, max=64, C-substates=0.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.00 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,
CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.00 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,
CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu2: 512KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.00 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,
CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu3: 512KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 1, remapped to apid 4
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P0P1)
acpiprt2 at acpi0: bus 1 (P0P4)
acpiprt3 at acpi0: bus 2 (P0P8)
acpiprt4 at acpi0: bus 3 (P0P9)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpicpu2 at acpi0: C1(@1 halt!)
acpicpu3 at acpi0: C1(@1 halt!)
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 4 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 4 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 4 int 19
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 4 int 18
usb0 at ehci0: USB revision 2.0

relayd, sshd, carp

[Dewey Hylton]

i have a pair of openbsd boxes, each running a secondary sshd service on
alternate port on their primary ip addresses. in addition to the primary
address, they also share a carp address.

the secondary sshd service listens on the primary address, and alternate
port
(10022). secondary sshd configuration, users, directories and such are
synchronized between the two boxes so that the secondary sshd services are
identical excepting for their listening address.

each of these boxes is also running relayd. the configurations are
identical,
being synchronized the same way as the secondary sshd services are. relayd
listens on the carp address, and relays inbound connections to the two
primary
addresses on the alternate ports.

the overall goal is to provide a clustered sftp service that protects
against
single points of failure and allows for growth and maintenance (eg. adding
more
cluster nodes and/or bringing one down for patching).

overall this appears to be working, but (and here is why i'm posting) ...

relayd has been failing its backend hosts at somewhat random intervals, with
complaints of timeouts. we don't always see these (though they are
definitely
being logged) because relayd simply relays connections to the boxes which
remain up ... however, we've seen periods where both backend services get
marked down at the same time and then our inbound transmissions fail. at
that
point it comes to everybody's attention.

initially i think we're having some kind of issue with our switching or
something. but then i realize that relayd is failing the service running on
the same host as well as other hosts on the network. if relayd is listening
on
address X on a carp interface and talking to address Y on the same physical
interface which is related to the carp interface, do these packets
physically
leave the box or does openbsd route those packets locally? if the former, we
could still have network switching issues. if the latter, i probably have an
issue with my configuration on openbsd. and in the case of the latter, i'll
show my configuration below in hopes that someone can point something out
that
i'm doing incorrectly. i'll also include dmesg. we do have cron jobs running
at 15-minute intervals, which very roughly equates to at least some of the
relayd messages shown below, so i have to wonder about limits, memory, etc.

i haven't seen anything listed in errata which leads me to believe it's a
problem with the code on the system, but i'm definitely not running the
latest
code. i'm more interested at this point in vetting out any configuration
issues or misconceptions on my part, and possibly ruling out these systems
as
causes of the problem.

help, as well as constructive criticism, will certainly be appreciated!




# w|grep load
11:47AM  up 24 days, 11:04, 2 users, load averages: 0.14, 0.27, 0.55

# uname -a
OpenBSD clusternode1 5.3 GENERIC.MP#58 i386

# vmstat
 procsmemory   pagediskstraps  cpu
 r b wavm fre  flt  re  pi  po  fr  sr cd0 sd0  int   sys   cs us
sy id
 1 7 0  24020 2403692  363   0   0   0   0   0   0   0   54  1186   79  1
1 98




/etc/hostname.em0

inet 10.11.12.102 255.255.255.0
-inet6





/etc/hostname.carp100

inet 10.11.12.100 255.255.255.0 NONE vhid 100 pass mycarppass advbase 1
advskew 1 description sftpcluster
-inet6





/usr/local/etc/sftp/run

#!/bin/sh
exec 21

PORT=10022
MYDIR=`pwd`
HOSTKEYS=
for K in  ${MYDIR}/etc/*key ; do HOSTKEYS=${HOSTKEYS} -h ${K} ; done
SSHD=`which sshd`
MYIP=`ifconfig egress | awk '/inet / { print $2 }'`

exec ${SSHD} -f ${MYDIR}/sftp.config \
${HOSTKEYS} \
-o ListenAddress=${MYIP}:${PORT} \
-D -e





/usr/local/etc/sftp/sftp.config

Protocol 2
SyslogFacility AUTH
LogLevel INFO
PermitRootLogin no
StrictModes yes
MaxAuthTries 6
##MaxSessions 10
AuthorizedKeysFile  /usr/local/etc/sftp/authorized_keys/%u.pub
PasswordAuthentication yes
PermitEmptyPasswords no
AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
UsePrivilegeSeparation sandbox
PermitUserEnvironment no
Compression delayed
ClientAliveInterval 0
ClientAliveCountMax 3
PidFile /var/run/sftp.pid
##MaxStartups 10:30:100
PermitTunnel no
ChrootDirectory %h
#Port 10022
UseDNS no
Subsystem   sftpinternal-sftp
ForceCommand internal-sftp -l VERBOSE






/usr/local/etc/relayd/run

#!/bin/sh
exec 21

RELAYD=`which relayd`

sleep 1
exec ${RELAYD} -d -v -f ./relayd.conf





/usr/local/etc/relayd/relayd.conf

table sftpcluster { 10.11.12.102 10.11.12.103 } # sftpnode1/sftpnode2
relay sftpcluster {
listen on carp100 port 10022
forward to sftpcluster port 10022 mode loadbalance check send
'foo'
expect 'SSH-2*'
}


output from relayd:
/var/log/authlog:Mar 18 00:00:02 clusternode1 relayd: host 10.10.10.103,
check send expect (209ms), state 

Re: pf/queue questions

[Dewey Hylton]

 From: Daniel Melameth dan...@melameth.com
 Subject: Re: pf/queue questions
 
 On Tue, Sep 23, 2014 at 9:39 AM, Dewey Hylton dewey.hyl...@gmail.com wrote:
  i have a site-to-site vpn setup across a 40Mbps wan link (average ~30ms
  latency). one of its uses is for san replication, but of course management
  traffic (ssh sessions, etc.) have to cross the link as well. without using
  queues, at times the replication traffic is such that management traffic
  suffers to the point of being unusable.
 
  so i setup queues, which fixed the management problem. but despite the
  management bandwidth requirements being minimal, the san replication
  traffic was then seen to plateau well below where i believe it should have
  been.
 
  one specific thing i'm seeing with this particular configuration is that
  san replication traffic tops out at 24Mbps, as seen on the wan circuit
  itself (outside of openbsd). removing the queues results in 100% wan
  utilization, even up to 100Mbps when the circuit is temporarily
  reconfigured to allow it.
 
 It's not clear to me in which direction or on what interface the SAN
 traffic is, but your 20Mb queue on $INETIF might be limiting your
 maximum throughput.  That said, you might also want to consider
 configuring qlimit and you can tweak this based on QLEN in systat
 queues.  Lastly, I recall henning@ saying queuing on VLANs is mostly
 useless, so you only want to apply altq to physical interfaces.

daniel, thanks for your input. after going back and reading henning's comments 
regarding queuing on vlans, i moved the queue definition to the physical 
interface and things are now working as expected.

pf/queue questions

[Dewey Hylton]

i have a site-to-site vpn setup across a 40Mbps wan link (average ~30ms
latency). one of its uses is for san replication, but of course management
traffic (ssh sessions, etc.) have to cross the link as well. without using
queues, at times the replication traffic is such that management traffic
suffers to the point of being unusable.

so i setup queues, which fixed the management problem. but despite the
management bandwidth requirements being minimal, the san replication
traffic was then seen to plateau well below where i believe it should have
been.

one specific thing i'm seeing with this particular configuration is that
san replication traffic tops out at 24Mbps, as seen on the wan circuit
itself (outside of openbsd). removing the queues results in 100% wan
utilization, even up to 100Mbps when the circuit is temporarily
reconfigured to allow it.

i have to assume that i've misunderstood the documentation and am looking
for some help. i'll paste the pf.conf below, followed by dmesg. we have a
fairly complex network on each end of the vpn, and we do in fact need the
nat that you will see though not for reasons related to the san replication
traffic. i have no doubt that i've done things incorrectly even in areas
seemingly unrelated to san replication, so feel free to fire away ...


pf.conf:
===
##
# macros

LANIF   = em0
WANIF   = em1
PFSYNC  = em2
INETIF  = vlan2
TWP2PIF = vlan3

table vpnendpointspersist { $PUBLIC1 $PUBLIC2 $REMOTEPUB3 $REMOTEPUB4
172.30.255.240/28 }
table carpmembers persist { $PUBLIC1 $PUBLIC2 172.28.0.251
172.28.0.252 }
table trustednets persist { 10.200.0.0/16 192.168.0.0/16 172.16.0.0/12
}
table recoverpointpersist { 10.200.80.0/24 172.28.0.247 172.28.0.248
10.200.72.0/24 172.28.0.10 172.28.0.11 172.28.0.12 172.28.2.0/24 }

##
# queues

altq on $INETIF  cbq bandwidth 20Mb queue { ssh, sansync, std }
altq on $TWP2PIF cbq bandwidth 35Mb queue { ssh, sansync, std }

queue sansync   bandwidth 35%   priority 1  cbq(borrow ecn)
queue std   bandwidth 50%   priority 2  cbq(default borrow)
queue ssh   bandwidth 15%   priority 3  cbq(borrow ecn)

##
# options

set skip on lo
set skip on enc0
set skip on gif
set skip on $PFSYNC
set block-policy return
set loginterface $WANIF


##
# ftp proxy

anchor ftp-proxy/*
pass in quick on $LANIF inet proto tcp to any port ftp \
divert-to 127.0.0.1 port 8021


##
# match rules

match in from trustednets scrub (no-df random-id max-mss 1200)


##
# filter rules

block in log
pass out
pass out proto tcp all modulate state

# site-to-site vpn
pass in quick log proto esp from vpnendpoints
pass in quick log proto udp from vpnendpoints port isakmp

antispoof quick for { lo $LANIF }

pass in quick proto carp from any to any
pass in quick inet proto icmp from any to any icmp-type { echoreq echorep
timex unreach }

pass in quick on $LANIF to recoverpoint queue sansync label sansync
pass in quick on $LANIF proto tcp to port { ssh } queue ssh label ssh

pass in quick on $LANIF proto tcp to port { 3389 } queue ssh label rdp

pass in log on $LANIF queue std label std




dmesg:
=
OpenBSD 5.4 (GENERIC.MP) #41: Tue Jul 30 15:30:02 MDT 2013
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8403169280 (8013MB)
avail mem = 8171749376 (7793MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xb7fcb000 (82 entries)
bios0: vendor HP version P80 date 11/08/2013
bios0: HP ProLiant DL320e Gen8 v2
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP SPCR MCFG HPET  SPMI ERST APIC  BERT HEST
DMAR  SSDT SSDT SSDT SSDT SSDT
acpi0: wakeup devices PCI0(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xb800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz, 3492.44 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT
,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1
,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
cpu0: apic clock running at 99MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz, 3491.92 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT
,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1

pf/queue questions

[Dewey Hylton]

i have a site-to-site vpn setup across a 40Mbps wan link (average ~30ms 
latency). one of its uses is for san replication, but of course management 
traffic (ssh sessions, etc.) have to cross the link as well. without using 
queues, at times the replication traffic is such that management traffic 
suffers to the point of being unusable. 

so i setup queues, which fixed the management problem. but despite the 
management bandwidth requirements being minimal, the san replication traffic 
was then seen to plateau well below where i believe it should have been.

one specific thing i'm seeing with this particular configuration is that san 
replication traffic tops out at 24Mbps, as seen on the wan circuit itself 
(outside of openbsd). removing the queues results in 100% wan utilization, even 
up to 100Mbps when the circuit is temporarily reconfigured to allow it.

i have to assume that i've misunderstood the documentation and am looking for 
some help. i'll paste the pf.conf below, followed by dmesg. we have a fairly 
complex network on each end of the vpn, and we do in fact need the nat that you 
will see though not for reasons related to the san replication traffic. i have 
no doubt that i've done things incorrectly even in areas seemingly unrelated to 
san replication, so feel free to fire away ...


pf.conf:
===
##
# macros

LANIF   = em0
WANIF   = em1
PFSYNC  = em2
INETIF  = vlan2
TWP2PIF = vlan3

table vpnendpointspersist { $PUBLIC1 $PUBLIC2 $REMOTEPUB3 $REMOTEPUB4 
172.30.255.240/28 }
table carpmembers persist { $PUBLIC1 $PUBLIC2 172.28.0.251 172.28.0.252 }
table trustednets persist { 10.200.0.0/16 192.168.0.0/16 172.16.0.0/12 }
table recoverpointpersist { 10.200.80.0/24 172.28.0.247 172.28.0.248 
10.200.72.0/24 172.28.0.10 172.28.0.11 172.28.0.12 172.28.2.0/24 }

##
# queues

altq on $INETIF  cbq bandwidth 20Mb queue { ssh, sansync, std }
altq on $TWP2PIF cbq bandwidth 35Mb queue { ssh, sansync, std }

queue sansync   bandwidth 35%   priority 1  cbq(borrow ecn) 
queue std   bandwidth 50%   priority 2  cbq(default borrow)
queue ssh   bandwidth 15%   priority 3  cbq(borrow ecn)

##
# options

set skip on lo
set skip on enc0
set skip on gif
set skip on $PFSYNC
set block-policy return
set loginterface $WANIF


##
# ftp proxy

anchor ftp-proxy/*
pass in quick on $LANIF inet proto tcp to any port ftp \
divert-to 127.0.0.1 port 8021


##
# match rules

match in from trustednets scrub (no-df random-id max-mss 1200)


##
# filter rules

block in log
pass out 
pass out proto tcp all modulate state

# site-to-site vpn
pass in quick log proto esp from vpnendpoints
pass in quick log proto udp from vpnendpoints port isakmp

antispoof quick for { lo $LANIF }

pass in quick proto carp from any to any
pass in quick inet proto icmp from any to any icmp-type { echoreq echorep timex 
unreach }

pass in quick on $LANIF to recoverpoint queue sansync label sansync
pass in quick on $LANIF proto tcp to port { ssh } queue ssh label ssh

pass in quick on $LANIF proto tcp to port { 3389 } queue ssh label rdp

pass in log on $LANIF queue std label std




dmesg:
=
OpenBSD 5.4 (GENERIC.MP) #41: Tue Jul 30 15:30:02 MDT 2013
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8403169280 (8013MB)
avail mem = 8171749376 (7793MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xb7fcb000 (82 entries)
bios0: vendor HP version P80 date 11/08/2013
bios0: HP ProLiant DL320e Gen8 v2
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP SPCR MCFG HPET  SPMI ERST APIC  BERT HEST DMAR 
 SSDT SSDT SSDT SSDT SSDT
acpi0: wakeup devices PCI0(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xb800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz, 3492.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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
cpu0: apic clock running at 99MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz, 3491.92 MHz
cpu1: 

Re: 5.5 bsd.rd fails to boot on alix

[Dewey Hylton]

Christian Weisgerber:

   I vaguely remember that at some point there was a change that
   requires a new boot(8), otherwise a serial console won't be set
   correctly with a new kernel.
  
  hmmm ... would this affect both pxe and locally booting bsd.rd?
 
 It affects both pxeboot(8) and boot(8) on disk.
 
  where is this documented?
 
 I don't think it is explicitly documented anywhere, but this may
 be pertinent:
 
 Upgrades are only supported from one release to the release
 immediately
  following it. Do not skip releases. If you got lucky skipping
  releases
  in the past, you may not this time.

excellent, copying the updated pxeboot(8) into place was the ticket. 

as this was not an upgrade, but instead a wipe-and-reload it never occurred to 
me that the boot(8) blurb in the upgrading documentation would have been 
relevant. i now understand that pxeboot(8) is just a modified version of 
boot(8), but still may not have found it myself because i didn't make that 
connection.

thanks for pointing this out.

5.5 bsd.rd fails to boot on alix

[Dewey Hylton]

i have 3 alix 2d13 machines, all currently running something between 5.1 and 
5.3. each of these fails to boot the 5.5 bsd.rd (i386). bsd.rd checksums match. 
each time i attempt to boot the 5.5 bsd.rd on any of these 3 machines, i see 
the following two lines:

booting tftp:bsd.rd: snip
entry point at 0x200120

i've also booted the machines to their current openbsd install, downloaded the 
bsd.rd file locally, rebooted, and attempted to boot the new bsd.rd from the 
boot prompt. i get the same thing doing that, excepting for the tftp: blurb. 
for this reason i don't believe networking has anything to do with the failure. 
because i see the same thing via pxe, i don't believe the on-disk code has 
anything to do with the failure either.

i've run memtest, nothing bad to report. i've tried different serial speeds 
(9600, 38400, 115200), no changes. the 5.4 bsd.rd works just fine, while the 
latest snapshot yields the same problem.

i'm hoping this is a known behavior resulting from a change for which i've 
simply missed the clue. has something changed, and i am simply doing something 
wrong for the newer version of openbsd?

Re: 5.5 bsd.rd fails to boot on alix

[Dewey Hylton]

 From: Christian Weisgerber na...@mips.inka.de
 To: dewey hylton dewey.hyl...@gmail.com
 Sent: Sunday, June 29, 2014 10:10:35 AM
 Subject: Re: 5.5 bsd.rd fails to boot on alix
 
 [This message has also been posted to list.openbsd.misc.]
 On 2014-06-29, Dewey Hylton dewey.hyl...@gmail.com wrote:
 
  i have 3 alix 2d13 machines, all currently running something
  between 5.1 and 5.3. each of these fails to boot the 5.5 bsd.rd
  (i386). bsd.rd checksums match. each time i attempt to boot the 5.5
  bsd.rd on any of these 3 machines, i see the following two lines:
 
  booting tftp:bsd.rd: snip
  entry point at 0x200120
 
 Looks like the kernel doesn't switch to the serial console.
 If you boot from the network, make sure that you have an
 etc/boot.conf

agreed; yes, i have boot.conf in place, which is how the other 5.x versions of 
bsd.rd are working.

 file on the TFTP server.  Also, make sure that you use the 5.5
 pxeboot
 and not an old one, because...
 
  i've also booted the machines to their current openbsd install,
  downloaded the bsd.rd file locally, rebooted, and attempted to boot
  the new bsd.rd from the boot prompt. i get the same thing doing
  that, excepting for the tftp: blurb.
 
 I vaguely remember that at some point there was a change that
 requires a new boot(8), otherwise a serial console won't be set
 correctly with a new kernel.

hmmm ... would this affect both pxe and locally booting bsd.rd? if so, this is 
probably my issue. i'm betting that the current pxeboot version is from 4.7 or 
4.8, and the on-disk version of boot on all 3 boxes is 5.1 ... i can test this 
tomorow morning.

thanks for this pointer! where is this documented? 

 
 --
 Christian naddy Weisgerber
  na...@mips.inka.de

Re: getting apps en masse

[Dewey Hylton]

wget does the trick nicely for me ...

VER=5.2
ARCH=i386
BASE=ftp://ftp.openbsd.org/pub/OpenBSD/$VER
ARGS=--passive-ftp -r -N -nH
wget $ARGS -l inf $BASE/packages/$ARCH/


From: John Newton johnnewton98 at yahoo.com
Subject: getting apps en masse
Date: 2013-01-25 01:30:19 GMT (2 days, 1 hour and 12 minutes ago)
Sirs: Is there a way to download whole multipage chunks of the Apps from any
of the mirrors? I need to study them at my leisure offline and the one-by-one
method is tedious. Thanks from john

remote out-of-band management / intel vpro

[Dewey Hylton]

for some of my remote customers, as well as my own office, i'm looking for an 
out-of-band management solution that's cheaper than iLO or DRAC. remote power 
management would be nice, but network KVM is a must. i read about intel vpro / 
amt recently and just started looking into it; it seems to be baked into most 
of their q-series chipsets.

has anyone here successfully used the intel solution for KVM or anything else? 
how about unsuccessfully? having something baked into the chipset makes me 
worry about compatibility with openbsd, as i'm not sure just how 
transparent/non-invasive it is.

reports either way would be appreciated - as would another usable solution.

ipsec / ospf / multihoming - looking for recommendations

[Dewey Hylton]

hi all. i'm currently using two openbsd boxes to provide redundant site-to-site 
vpn connectivity between two geographically distant sites. each has both 
private (mpls ethernet handoff) and public (standard internet) connectivity. i 
have a pair of gif tunnels, one over each network, ospf to decide which route 
to take, and ipsec laid on top. this works so well that on more than one 
occasion we've been called by our provider (att for mpls) and given an apology 
for their circuit being down - our primary circuit - and we didn't even realize 
it had been down. we are thrilled  with this.

we are on the verge of rolling out several more remote sites, each with 
multiple network connections (one has three - one mpls and two separate isps). 
i want to cluster openbsd at each site for redundancy. i believe i can do this 
with relative ease by just extending my current   method (doubling the gifs at 
each site). but i just received a request to allow the remote sites to talk 
directly with each other as well. that points to gifs between each site, adding 
further complexity. now this is starting to look like a mesh, and i've never 
attempted that before - so i'm here asking for recommendations from those of 
you who are experienced with this and have the time to help. 

just trying to extend my current method ... each cluster will have two openbsd 
boxes. with main office having a single isp and mpls, and one remote site 
having two isps and mpls - that alone yields 12 gif tunnels. and that's just 
two sites. suddenly i'm not so sure i'm headed in the right direction. so now i 
have lots of questions ...

am i going about this all wrong?

do i need separate route tables for each isp connection at the remote site so 
that the gif tunnels are assured of going out the correct path?

should i be using (private) bgp instead of ospf?

and if bgp, should i be using it to push out the ipsec stuff? (i just read that 
openbgp has ipsec-related capability, but haven't dug into that yet.)

specific recommendations will be warmly welcomed, as i have a short timetable 
and a lot of these new requirements just came to light (scope creep at the last 
minute - gotta love that).

thanks in advance!

Re: Manual IPsec setup with ipsec.conf

[Dewey Hylton]

- Original Message -
 From: Girish Venkatachalam girishvenkatacha...@gmail.com
 To: OpenBSD general usage list misc@openbsd.org
 Sent: Wednesday, April 4, 2012 8:23:27 PM
 Subject: Manual IPsec setup with ipsec.conf
 
 Dear all,
 
 Such a silly thing is not documented anywhere, no vpn(8) man page and
  not on the Internet.
 
 I am forced to send this mail though it is embarrassing having worked
 on the
  internals of manual IPsec keying back in 2004. But well here goes.
 
 on peer A:
 
 remoteip=173.167.82.52
 remotenet=10.1.23.0/24
 
 flow esp from 59.99.242.167 to $remoteip
 flow esp from 192.168.1.0/24 to $remotenet peer $remoteip
 esp from 59.99.242.167 to $remoteip spi 0xdeadbeef:0xbeefdead auth
 hmac-sha1 \
authkey
0xeda8f06463b2d0fed008ccc474216dba8c463a7c:0x91c763de940ce1745215c84b7
 535269acaef516d
\
enckey
0xb341aa065c3850edd6a61e150d6a5fd3:0xf7795f6bdd697a43a4d28dcf1b79062d
 
 on peer B:
 
 localnet=192.168.0.0/16
 remoteip=59.99.242.167
 
 flow esp from 173.167.82.52 to 59.99.242.167
 flow esp from 10.1.23.0/24 to 192.168.1.0/24 peer $remoteip
 esp from 173.167.82.52 to 59.99.242.167 spi 0xbeefdead:0xdeadbeef
 auth
 hmac-sha1 \
authkey
0x91c763de940ce1745215c84b7535269acaef516d:0xeda8f06463b2d0fed008ccc47
 4216dba8c463a7c
\
enckey
0xf7795f6bdd697a43a4d28dcf1b79062d:0xb341aa065c3850edd6a61e150d6a5fd3
 
 
 It is a test. I don't care about the keys and IP addresses.
 
 pf(4) is disabled both sides and here is the output of
 
 #ipsecctl -sa on peer B
 
 # ipsecctl -sa -v
 FLOWS:
 flow esp in from 192.168.1.0/24 to 10.1.23.0/24 peer 59.99.242.167
 type
 require
 flow esp out from 10.1.23.0/24 to 192.168.1.0/24 peer 59.99.242.167
 type
 require
 flow esp in from 59.99.242.167 to 173.167.82.52 peer 59.99.242.167
 type
 require
 flow esp out from 173.167.82.52 to 59.99.242.167 peer 59.99.242.167
 type
 require
 
 SAD:
 esp tunnel from 173.167.82.52 to 59.99.242.167 spi 0xbeefdead auth
 hmac-sha1 enc aes
 sa: spi 0xbeefdead auth hmac-sha1 enc aes
 state mature replay 0 flags 4
 lifetime_cur: alloc 0 bytes 0 add 1333585323 first 0
 address_src: 173.167.82.52
 address_dst: 59.99.242.167
 esp tunnel from 59.99.242.167 to 173.167.82.52 spi 0xdeadbeef auth
 hmac-sha1 enc aes
 sa: spi 0xdeadbeef auth hmac-sha1 enc aes
 state mature replay 0 flags 4
 lifetime_cur: alloc 0 bytes 0 add 1333585323 first 0
 address_src: 59.99.242.167
 address_dst: 173.167.82.52
 
 And peer A:
 
 # ipsecctl -sa -v
 FLOWS:
 flow esp in from 10.1.23.0/24 to 192.168.1.0/24 peer 173.167.82.52
 type
 require
 flow esp out from 192.168.1.0/24 to 10.1.23.0/24 peer 173.167.82.52
 type
 require
 flow esp in from 173.167.82.52 to 59.99.242.167 peer 173.167.82.52
 type
 require
 flow esp out from 59.99.242.167 to 173.167.82.52 peer 173.167.82.52
 type
 require
 
 SAD:
 esp tunnel from 173.167.82.52 to 59.99.242.167 spi 0xbeefdead auth
 hmac-sha1 enc aes
 sa: spi 0xbeefdead auth hmac-sha1 enc aes
 state mature replay 0 flags 4
 lifetime_cur: alloc 0 bytes 0 add 1333585275 first 0
 address_src: 173.167.82.52
 address_dst: 59.99.242.167
 esp tunnel from 59.99.242.167 to 173.167.82.52 spi 0xdeadbeef auth
 hmac-sha1 enc aes
 sa: spi 0xdeadbeef auth hmac-sha1 enc aes
 state mature replay 0 flags 4
 lifetime_cur: alloc 0 bytes 196 add 1333585275 first
 1333585277
 address_src: 59.99.242.167
 address_dst: 173.167.82.52
 lifetime_lastuse: alloc 0 bytes 0 add 0 first 1333585277
 
 I cannot ping between 192.168.1.50 and 10.1.23.2
 
 What is going on?
 
 -Girish
 
 --
 G3 Tech
 Networking appliance company
 web: http://g3tech.in  mail: gir...@g3tech.in


two very basic questions, both of which have bitten me at some point:

1) is ip forwarding enabled on both boxes?
2) do you have the appropriate routes setup on both sides?

Re: openbsd / ipsec / hardware

[Dewey Hylton]

- Original Message -
 From: Ted Unangst t...@tedunangst.com
 To: Stuart Henderson s...@spacehopper.org
 Cc: misc@openbsd.org
 Sent: Monday, April 2, 2012 7:42:01 PM
 Subject: Re: openbsd / ipsec / hardware
 
 On Mon, Apr 02, 2012, Stuart Henderson wrote:
  i'm using a simple scp of a 100MB file. scp reports its
  transmission
  speed. and i'm comparing the same transmission of the same file
  between
  the same two hosts with and without vpn encryption. it may not be
  the best or most accurate measurement, but i believe it gives me
  the
  information i'm looking for.
  
  Sorry, this is a horrible way to measure connection speed.
  Plain ftp would be better, but something that doesn't also measure
  disk throughput would be better still (tcpbench, iperf etc).
 
 I'll take the dissenting view here.  We often criticize people for
 putting too much emphasis on fake benchmarks and ignoring real world
 performance data.  Here we have somebody actually testing the same
 thing he's going to be using (maybe).  A few other tests may provide
 a
 insight into the problem, but at the end of the day, they
 aren't going to determine whether the ipsec link is usable or not.
 
  Also if you're testing from the router itself note that results
  when testing from another machine which connects through the router
  are likely to be very different.
 
 This is very true.

ted, that was my thought as well ... i chose scp because this link will 
be used to sync data offsite via, rsync, and a few other methods. while
tcpbench is a nifty tool, it doesn't really show me what i need to see.

i currently have a freebsd box on one side of the connection and linux
on the other. i will eventually have openbsd on both sides with which
i could use tcpbench, but again that doesn't seem to matter at this time.
each box has 4GB of memory, so i figured the 100MB file would be 
transmitted to/from RAM in the first place. and as far as i'm aware 
even the slowest sata disk can handle the slow connection i'm attempting
to test, so disk throughput shouldn't be a factor. and i'm not testing
from router to router, but across both routers.

and of course, my measurements are comparisons between transmissions
with and without vpn. so the difference between the two shows the overhead
of the vpn, and that's what i'm trying to work on here.

i know that the alix has hardware crypto supporting aes-128-cbc. one thing
that was unclear to me was, on the openbsd ipsec side, whether 
aes == aes-128 == aes-128-cbc ... my assumption was YES, after seeing that
aes/aes-128 are both 3 times faster than des on this hardware - but then
i found that blowfish and aes-256 are both faster as well, so at this point
i'm still not sure i'm even getting anything out of the hardware crypto.

one ah-hah, though, was that the scp command was reporting megabytes
per second, not megabits per second as was being reported by another user
here. so there was confusion on my part.

Re: openbsd / ipsec / hardware

[Dewey Hylton]

- Original Message -
 From: James Shupe jsh...@hermetek.com
 To: Dewey Hylton dewey.hyl...@gmail.com
 Sent: Friday, March 30, 2012 4:40:23 PM
 Subject: Re: openbsd / ipsec / hardware
 
 On 03/30/2012 03:16 PM, Dewey Hylton wrote:
  i'm getting ready to implement a few new site-to-site vpns using
  openbsd, and am on the hunt for appropriate hardware. i have
  several alix (geode) and lanner (intel atom) boxes working
  wonderfully as firewalls and routers, but neither type are able to
  provide enough throughput when ipsec is added to their roles.
  
  the lanner boxes can't accept add-in cards. the alix can accept a
  minipci, and i know that soekris makes a crypto accelerator
  (hifn?) that may help - but i'm not sure that'll be enough oompf
  either. our site-to-site link will provide up to 20Mbps, but the
  lanner box is topping out at 3.3Mbps with ipsec and the alix is at
  1.5Mbps.
  
  can anyone point me to a matrix of hardware types and their crypto
  performance benchmarks with openbsd, or at least make
  recommendations based on real-world use?
  
  i'm using defaults for my ipsec configuration, so this is what i'm
  testing with: auth hmac-sha2-256 enc aes
  
  thanks for your time.
  
 
 The Alix has a crypto accelerator that supports AES-128-CBC. You
 should
 get around 14Mbps using aes-128 and turning on kern.usercrypto (speed
 tested with OpenVPN*).
 
 -J

would you mind posting your (sanitized) openvpn configuration, as well
as your bandwidth measuring method?

i attempted this today and am seeing much less than 14Mbps. i'm probably
not measuring the same way, however, as i'm using a simple scp which 
obviously has its own overhead - but does give me what i believe to be
a fair comparison (testing with and without vpn).

Re: openbsd / ipsec / hardware

[Dewey Hylton]

From: Stuart Henderson stu at spacehopper.org
Subject: Re: openbsd / ipsec / hardware
Newsgroups: gmane.os.openbsd.misc
Date: 2012-03-31 21:39:14 GMT (1 day, 22 hours and 53 minutes ago)
On 2012-03-30, Dewey Hylton dewey.hylton at gmail.com wrote:
 i'm getting ready to implement a few new site-to-site vpns using
 openbsd, and am on the hunt for appropriate hardware. i have several
 alix (geode) and lanner (intel atom) boxes working wonderfully as
 firewalls and routers, but neither type are able to provide enough
 throughput when ipsec is added to their roles.

 the lanner boxes can't accept add-in cards. the alix can accept
 a minipci, and i know that soekris makes a crypto accelerator (hifn?)
 that may help - but i'm not sure that'll be enough oompf either.
 our site-to-site link will provide up to 20Mbps, but the lanner box
 is topping out at 3.3Mbps with ipsec and the alix is at 1.5Mbps.

This seems a bit on the low side. How are you testing throughput?

i'm using a simple scp of a 100MB file. scp reports its transmission
speed. and i'm comparing the same transmission of the same file between
the same two hosts with and without vpn encryption. it may not be
the best or most accurate measurement, but i believe it gives me the
information i'm looking for.

openbsd / ipsec / hardware

[Dewey Hylton]

i'm getting ready to implement a few new site-to-site vpns using openbsd, and 
am on the hunt for appropriate hardware. i have several alix (geode) and lanner 
(intel atom) boxes working wonderfully as firewalls and routers, but neither 
type are able to provide enough throughput when ipsec is added to their roles. 

the lanner boxes can't accept add-in cards. the alix can accept a minipci, and 
i know that soekris makes a crypto accelerator (hifn?) that may help - but i'm 
not sure that'll be enough oompf either. our site-to-site link will provide up 
to 20Mbps, but the lanner box is topping out at 3.3Mbps with ipsec and the alix 
is at 1.5Mbps.

can anyone point me to a matrix of hardware types and their crypto performance 
benchmarks with openbsd, or at least make recommendations based on real-world 
use?

i'm using defaults for my ipsec configuration, so this is what i'm testing 
with: auth hmac-sha2-256 enc aes

thanks for your time.

Re: Failover VPN tunnels

[Dewey Hylton]

- Original Message -
 From: Jeff Simmons jsimm...@goblin.punk.net
 To: misc@openbsd.org
 Sent: Monday, March 12, 2012 8:27:51 PM
 Subject: Failover VPN tunnels
 
 I've got a setup with a central VPN gateway running a couple dozen
 IPSEC
 tunnels to remote locations. All the gateways are running current,
 and use
 very simple ipsec.conf entries to set things up. Works beautifully.
 
 ISPs are another matter. At two of the remotes, service is 'flaky' to
 say the
 least, and we lose connectivity due to network problems on a regular
 basis.
 Both sites have alternate ISPs available, but their service is also
 questionable (think mountaintop ski resort). I'd like to set up
 redundant
 connections to these two sites with automatic failover from ISP A
 (and all
 related IPSEC connections) to ISP B when A's network goes down, etc.
 
 I've found recommendations for using either GIF or GRE in the mailing
 list
 archives, but little on how to set it up or the relative
 advantages/disadvantages of these two proposals. It also seems that
 ifstated
 could be used to 'manually' insert/remove SAs and flows via ipsecctl.
 Does
 anyone have any thoughts as to which approach is preferable and the
 relative
 merits of each?
 
 --
 Jeff Simmons
   jsimm...@goblin.punk.net

i have one customer with similar flaky isp issues ... i've satisfactorily
handled it with a combination of separate ipsec tunnels and ospf. i'm
not even using ifstated. i can provide an example if needed, but it is so
simple i doubt you'd need to see it.

Re: ethernet-to-serial support

[Dewey Hylton]

- Original Message -
 From: Henning Brauer lists-open...@bsws.de
 To: misc@openbsd.org
 Sent: Thursday, February 23, 2012 10:45:52 AM
 Subject: Re: ethernet-to-serial support
 
 * Dewey Hylton dewey.hyl...@gmail.com [2012-02-23 15:21]:
  i used the digi equipment over a decade ago with both hpux and aix
  with success. i'd really like to access these from my openbsd
  workstation and laptop, though the documentation mentions support
  for just about everything other than bsd.
  are any of these usable with bsd? and by that i mean can openbsd
  connect to the serial ports via ethernet with cu or something
  similar?
 
 i dunno the digi stuff, but console servers usually provide access to
 the serial ports via telnet or ssh. in general you don't wanna expose
 these to the 'net, but it's good enough for a seperate vlan or the
 like to an openbsd box that you either run conserver on or just use
 to
 jump through.

ahhh, and now it is clear to me how much 'smarter' these devices have
become since i used them before. i'm relatively certain the ethernet
connectivity was limited to 10Mbps, and i certainly don't remember any
ssh options. that tidbit right there fixes all my worries. thanks!

ethernet-to-serial support

[Dewey Hylton]

i've been using usb-to-serial adapters to deal with equipment such as 
serial-console openbsd boxes and cisco devices. i'd like to move toward 
something like the digi or perle console servers. 

i used the digi equipment over a decade ago with both hpux and aix with 
success. i'd really like to access these from my openbsd workstation and 
laptop, though the documentation mentions support for just about everything 
other than bsd. 

are any of these usable with bsd? and by that i mean can openbsd connect to the 
serial ports via ethernet with cu or something similar?

Re: looking for hardware recommendations, x86 or otherwise.

[Dewey Hylton]

- Original Message -
 From: Theo de Raadt dera...@cvs.openbsd.org
 To: Dewey Hylton dewey.hyl...@gmail.com
 Cc: misc@openbsd.org
 Sent: Sunday, January 29, 2012 6:32:21 PM
 Subject: Re: looking for hardware recommendations, x86 or otherwise.
 
  i'm hoping the raspberrypi will eventually be supported on openbsd
  (if the hardware proves to be stable, $35 sounds GREAT) but i don't
  have the skills to go there myself.
 
 Wow.   Dream on.  It is a mess of firmware.  You know nothing of our
 history?

i know a bit of the history, sure. i know nothing of the raspberrypi firmware, 
however. :)

Re: looking for hardware recommendations, x86 or otherwise.

[Dewey Hylton]

- Original Message -
 From: corey clingo clinge...@gmail.com
 To: misc@openbsd.org
 Sent: Sunday, January 29, 2012 7:05:17 PM
 Subject: Re: looking for hardware recommendations, x86 or otherwise.
 
 On Sun, Jan 29, 2012 at 4:06 PM, Dewey Hylton
 dewey.hyl...@gmail.com wrote:
  if you feel this is a tired and worn-out question, then please just
  move
 along.
 
  two systems on which i'm happily running openbsd on are:
  alix and mac mini. alix for firewalls/thin clients, and the mac
  mini can
 handle pretty much anything i throw at it. both are relatively cheap
 (new alix
 and used minis) and function well. in addition to firewalls/thin
 clients, my
 needs do not include anything high-performance or high-bandwidth -
 mostly
 infrastructure services such as dns/dhcp/web for small companies.
 
  so what i'm looking for is something small like (or smaller than)
  these two
 systems, and just as stable, while being cheaper. and i'm looking for
 recommendations, not just suggestions - if you haven't tried it and
 loved it,
 don't bother mentioning it.
 
  i'm hoping the raspberrypi will eventually be supported on openbsd
  (if the
 hardware proves to be stable, $35 sounds GREAT) but i don't have the
 skills to
 go there myself.
 
 
 Alixes are pretty cheap. Not Sheevaplug or RasberryPi cheap, but
 cheap
 for the capabilities they have. I mean, at the end of the day, your
 clients are relying on these devices for potentially
 business-critical
 services. How much do they really want to skimp?
 
 Personally I've lately been moving upmarket with this kind of device.
 You get better performance (e.g., faster CPUs, Intel GbE rather than
 Via, etc.), a more solid build, and I've never had to solder my own
 surface mount caps on
 one to fix a clock oscillator issue as I did with my home Soekris
 once
 :)
 
 All that said, one day when I retire and want to stretch my brain to
 keep from getting senile, I'll probably try to port OpenBSD to a
 couple of embedded-ish devices I currently use. The hardware is
 generally decent from the outside, but I can't help but believe
 they'd
 be better, faster, and more secure with OpenBSD than the iffy
 Linux+vendor enhancements that they typically come with.
 
 Corey

is it safe to assume your upmarket devices meet the first two criteria, but are 
more expensive? i'm still interested in hearing your recommendation; most of my 
servers are much larger and more expensive than the alix solutions - having 
something in the middle could certainly be useful. thanks for your input.

looking for hardware recommendations, x86 or otherwise.

[Dewey Hylton]

if you feel this is a tired and worn-out question, then please just move along. 

two systems on which i'm happily running openbsd on are:
alix and mac mini. alix for firewalls/thin clients, and the mac mini can handle 
pretty much anything i throw at it. both are relatively cheap (new alix and 
used minis) and function well. in addition to firewalls/thin clients, my needs 
do not include anything high-performance or high-bandwidth - mostly 
infrastructure services such as dns/dhcp/web for small companies.

so what i'm looking for is something small like (or smaller than) these two 
systems, and just as stable, while being cheaper. and i'm looking for 
recommendations, not just suggestions - if you haven't tried it and loved it, 
don't bother mentioning it.

i'm hoping the raspberrypi will eventually be supported on openbsd (if the 
hardware proves to be stable, $35 sounds GREAT) but i don't have the skills to 
go there myself.

Re: roundcubemail packet

[Dewey Hylton]

- Original Message -
 From: Wesley M. open...@e-solutions.re
 To: misc@openbsd.org
 Sent: Monday, December 5, 2011 3:03:25 AM
 Subject: roundcubemail packet
 
 Hi,
 
 I have the following error :
 
 Check DB config
 DSN (write):  NOT OK(MDB2 Error: connect failed)
 Make sure that the configured database exists and that the user has
 write
 privileges
 DSN: mysql://roundcube:pass@localhost/roundcubemail
 
 Using http://mailserver_ip/roundcubemail/installer/
 I have a user roundcube in mysql, with a roundcubemail database.
 I don't understand why it stops here... If someone can help me?
 
 What is installed on this machine (OpenBSD 5.0) :
 aspell-0.60.6p4; bzip2-1.0.6; curl-7.21.7; cvsps-2.1
 dovecot-2.0.13p5; femail-0.97p1; femail-chroot-0.97p3;
 gettext-0.18.1p0; git-1.7.6p0; libiconv-1.13p2; libidn-1.22
 libltdl-1.5.26p0; libmagic-5.00; libmcrypt-2.5.8p1; libxml-2.7.8p2
 mysql-client-5.1.54p0; mysql-server-5.1.54p9; p5-Clone-0.31p1;
 p5-DBD-mysql-4.019
 p5-DBI-1.616; p5-Error-0.17016p0; p5-FreezeThaw-0.43p2; p5-MLDBM-2.04
 p5-Net-Daemon-0.43p0; p5-Params-Util-1.00p2; p5-PlRPC-0.2018p1;
 p5-SQL-Statement-1.33
 pecl-fileinfo-1.0.4p0; php-5.2.17p5; php-mcrypt-5.2.17p3;
 php-mysql-5.2.17p3
 php-pspell-5.2.17p3; roundcubemail-0.5.3p1; rsync-3.0.8p0
 
 Also, i want to buil a mailserver (multi-domains) using sendmail(with
 virtusertable)
 and dovecot. But i want to use pop3/pop3s does this working with
 roundcubemail-0.5.3p1 ?
 
 Thank you very much for your help.
 
 Cheers,
 
 Wesley.

my recommendation would be to look at a finished product which seems to do 
everything you're looking for. since it's open source, you can poke around and 
find how it is put together. or of course you can just use it as-is - i used it 
for several years for myself and a couple of my customers, and was completely 
satisfied with it.

http://mailserv.github.com/

Re: Daily digest, Issue 1989 (27 messages)

[Dewey Hylton]

 From: shweg...@gmail.com
 Date: December 3, 2010 6:28:19 AM EST
 To: misc@openbsd.org
 Subject: soekris + openbsd server buy question

 Hello, I'm considering buying a Soekris net5501-70 and install OpenBSD on it
to make myself a small server and use it as a proxy (ssh tunnel), it might
serve as backup file sever as well. I guess at the most there will be
two-three computers connnected at the same time, and there might be some
streaming video going through, like the videos you find on online newspapers.
I have googled around, and read that this kind of hardware is fine as a router
but not so much as a server. Is it true?
 Thank you for any suggestions.
 I was also considering using a netbook for the task. What about it?
 Thanks in advance.

after several years of decent service, i've replaced all my soekris boxes with
ones built around the alix boards. for low-power openbsd usage, the alix
boards are great. they provide built-in hardware crypto, which openbsd is
happy with, and are able to handle site-to-site vpn, firewalling, etc.

http://pcengines.ch/alix.htm
http://store.netgate.com/ALIX2D3-2D13-Kit-Red-Unassembled-P174C82.aspx

Re: Daily digest, Issue 1944 (42 messages)

[Dewey Hylton]

 -Original Message-
 From: Brad Tilley [mailto:b...@16systems.com]
 Sent: den 14 oktober 2010 13:36
 To: Leif Blixt; openbsd-misc
 Subject: Re: Force passwordcheck in login.conf

 Leif Blixt wrote:

 We are currently being reviewed for PCI DSS compliance, and the big
 problems
 we have right now with the combination of PCI DSS and OpenBSD is the
 following
 PCI DSS requirements:
 8.5.12 Password history check - you may not use the last 4 passwords.
 8.5.13 Lockout after 6 failed attempts - OpenBSD does not lock accounts
 automatically.
 8.5.14 If 8.5.13 takes affect, the account must be locked for at least 30
 minutes.

 I concluded the same for requirement 8. See my rough notes here. I plan
 to add to that page as I do more testing:

 http://16systems.com/OpenBSD/pci.html

 How have you addressed these requirements? I'm starting to think we need a
 RADIUS solution, which seems a bit redundant working with OpenBSD...

 Regards, Leif

 RADIUS may do it if the backend can enforce those things (I don't know
 enough about this to comment, but OpenLDAP may work). If that cannot do
 it, read Appendix B of the PCI DSS carefully. They allow compensating
 controls when the requirements cannot be followed precisely.

 Brad

just a quick note on how we addressed 8.5.13 ... yes, it requires python, but
we are
a python shop so this was not an issue for us. i'm just posting it for the
purpose of
sharing ideas.

http://www.deweyonline.com/files/openbsd/login_-custompasswd

Re: Force passwordcheck in login.conf

[Dewey Hylton]

sorry for the subject goof ...

On Oct 17, 2010, at 11:51 AM, Dewey Hylton wrote:


 -Original Message-
 From: Brad Tilley [mailto:b...@16systems.com]
 Sent: den 14 oktober 2010 13:36
 To: Leif Blixt; openbsd-misc
 Subject: Re: Force passwordcheck in login.conf

 Leif Blixt wrote:

 We are currently being reviewed for PCI DSS compliance, and the big
 problems
 we have right now with the combination of PCI DSS and OpenBSD is the
 following
 PCI DSS requirements:
 8.5.12 Password history check - you may not use the last 4 passwords.
 8.5.13 Lockout after 6 failed attempts - OpenBSD does not lock accounts
 automatically.
 8.5.14 If 8.5.13 takes affect, the account must be locked for at least 30
 minutes.

 I concluded the same for requirement 8. See my rough notes here. I plan
 to add to that page as I do more testing:

 http://16systems.com/OpenBSD/pci.html

 How have you addressed these requirements? I'm starting to think we need
a
 RADIUS solution, which seems a bit redundant working with OpenBSD...

 Regards, Leif

 RADIUS may do it if the backend can enforce those things (I don't know
 enough about this to comment, but OpenLDAP may work). If that cannot do
 it, read Appendix B of the PCI DSS carefully. They allow compensating
 controls when the requirements cannot be followed precisely.

 Brad

 just a quick note on how we addressed 8.5.13 ... yes, it requires python,
but we are
 a python shop so this was not an issue for us. i'm just posting it for the
purpose of
 sharing ideas.

 http://www.deweyonline.com/files/openbsd/login_-custompasswd

gre over ipsec - mtu issues?

[Dewey Hylton]

hi all. implemented ospf routing between two gre-over-ipsec segments. failover
finally works beautifully. having comms issues where connecting to standard
web services across gre/ipsec seem to timeout, when connecting to tomcat apps
work fine. any clues where i should be looking for the problem? does this
sound like an mtu issue? my google-fu is rusty; some of what i'm seeing is
contradictory. help is appreciated.

ipsec / trunk / failover

[Dewey Hylton]

hi all. i have two sites connected by a slow mpls connection, each
having faster connections to the internet. both are viewed as
untrusted, so site-to-site traffic flowing over either mpls or
internet needs to be encrypted.

1) my minimum requirement at this point is for an encrypted connection
over mpls, with an encrypted connection over internet as failover. i
know it seems backwards, but since the mpls connection is guaranteed
bandwidth management prefers it over the internet connection.

2) my optimum setup would be to use both connections in order to
improve bandwidth, and having the connection simply get slower if one
of the links goes down.

i've already implemented ipsec tunnels in openbsd so i favor that
method, but am willing to go with openvpn if it proves to be more
beneficial. i am inexperienced with the rest of the equation, so have
plenty of questions and am in need of guidance.

in order to achieve #1, it seems that i might be able to create two
ipsec tunnels, one mpls and one internet, and route traffic across
them via ospf. is that right? any pointers/corrections there?

in order to achieve #2 ... could i create two ipsec tunnels and trunk
them? or could i create some kind of unencrypted tunnel over each
link, trunk them, and run ipsec on the trunk? if trunking is even
possible in either of these situations, how do i best utilize the
links (they are different speeds)?

i believe i understand the purpose and rough workings of ospf/bgp/etc
but have no experience with them or with the gif/gre/tun devices.
suggestions/pointers/links/howtos will be greatly appreciated.