Re: Hardware recommendation for small form factor, noiseless, server

[James Johnson]

Thanks a lot to you all for these recommendations.

Re: Hardware recommendation for small form factor, noiseless, server

[Страхиња Радић]

Дана 24/05/08 02:37PM, Karsten Pedersen написа:
> [...] The C program can be as simple as compiling "Hello World" to exhibit the
> issue. Takes about 15 seconds to compile "Hello World". [...]

On a Lenovo IdeaPad 3-15IGL05 81WQ[1] laptop:

$ time sh -c "printf '#include \\nint main() { puts(\"Hello,\
 world!\"); }\\n' | cc -o hello -xc -"
0m01.24s real 0m00.16s user 0m00.42s system

15 seconds? What is happening in the background? Ports compilation while 
encoding video?

[1]: https://psref.lenovo.com/Product/IdeaPad/IdeaPad_3_15IGL05

Re: Hardware recommendation for small form factor, noiseless, server

[Karsten Pedersen]

> What exactly is "good" with OpenBSD?

I summarize the issues in my last email

> So again, what is "slow"?

The machine running OpenBSD. Compared to similar ThinkCenters I have
(m73 Tiny and m92 Tiny). Also a Raspberry Pi 3 (running OpenBSD at lowest freq).
It seems not to be the SSD disk because the "slowness" is present when writing 
to
MFS mounts.

> 14 Watts for compilation or just idling?

Just at idle. Granted OpenBSD tends to run quite hot compared to alternatives
it still seems to draw more than the m73 and m93p.

> What issues?

I mention them in the last email

> Might be, but you didn't checked by tests. Yes, of course you have to
> use the same "C program" as before.

I tested against different operating systems and different hardware. As 
mentioned there
is definitely something up with this combo but I haven't had time to explore 
further. Hence
my general note to avoid this machine if people can for now (if they want 
something
guaranteed working). The C program can be as simple as compiling "Hello World" 
to exhibit the
issue. Takes about 15 seconds to compile "Hello World". It doesn't need to be a 
"test" to suspect
things aren't quite right here.

> I suspect something different, I guess it is from the black / red
> combination of the case colors. This is a broken combination and a
> dangerous one in art and design.

The m73 and m92 have similar case colors. So it is definitely not that ;)

Re: Hardware recommendation for small form factor, noiseless, server

[Johannes Thyssen Tishman]

2024-05-07T09:54:23Z "Karsten Pedersen" :
> > Second-hand Lenovo M710q tiny with a wifi-card could also work:
> > https://dmesgd.nycbug.org/index.cgi?do=view=5296
>
> A quick note that the slightly older M625q (with an AMD processor) isn't 
> quite so good with OpenBSD.
> It runs overly slow and I have yet had time to figure out why. Interestingly, 
> even on apm -H it takes
> longer to compile a C program than a Raspberry Pi 3. It also takes 14 Watts 
> so the power management
> isn't quite there yet. These issues aren't present with Linux or FreeBSD.
>
> It was ~£30 and completely fanless, so will almost be the perfect hardware 
> for a home server once
> these issues can be resolved.
>
> In short, the M710q with Intel processor might be the better choice. I 
> suspect it is to do with the
> pstate  stuff that the issues are arrising from.
>
> Karsten

I have an M700 10J0 and it works great. I don't use a wifi card so I
can't say anything about that. I believe hibernation doesn't work very
well (it gets stuck with unpacking or something like that when booting),
but other than that I haven't had any issues with it. It's a solid
machine I can recommend.

Re: Hardware recommendation for small form factor, noiseless, server

[Mihai Popescu]

> A quick note that the slightly older M625q (with an AMD processor) isn't 
> quite so good with OpenBSD.

What exactly is "good" with OpenBSD?

> It runs overly slow and I have yet had time to figure out why.

So again, what is "slow"?

> Interestingly, even on apm -H it takes longer to compile a C program than a 
> Raspberry Pi 3. It also takes 14 Watts so the power management
isn't quite there yet. These issues aren't present with Linux or FreeBSD.

"A C program"? Well, that is interesting. 14 Watts for compilation or
just idling?

> It was ~ Ł30 and completely fanless, so will almost be the perfect hardware 
> for a home server once these issues can be resolved.

What issues?

> In short, the M710q with Intel processor might be the better choice.

Might be, but you didn't checked by tests. Yes, of course you have to
use the same "C program" as before.

> I suspect it is to do with the pstate  stuff that the 
> issues are arrising from.

I suspect something different, I guess it is from the black / red
combination of the case colors. This is a broken combination and a
dangerous one in art and design.

> Karsten

You are welcome.

Re: Hardware recommendation for small form factor, noiseless, server

[Karsten Pedersen]

> Second-hand Lenovo M710q tiny with a wifi-card could also work:
> https://dmesgd.nycbug.org/index.cgi?do=view=5296

A quick note that the slightly older M625q (with an AMD processor) isn't quite 
so good with OpenBSD.
It runs overly slow and I have yet had time to figure out why. Interestingly, 
even on apm -H it takes
longer to compile a C program than a Raspberry Pi 3. It also takes 14 Watts so 
the power management
isn't quite there yet. These issues aren't present with Linux or FreeBSD.

It was ~£30 and completely fanless, so will almost be the perfect hardware for 
a home server once
these issues can be resolved.

In short, the M710q with Intel processor might be the better choice. I suspect 
it is to do with the
pstate  stuff that the issues are arrising from.

Karsten

Re: Hardware recommendation for small form factor, noiseless, server

[Mizsei Zoltán]

Second-hand Lenovo M710q tiny with a wifi-card could also work:
https://dmesgd.nycbug.org/index.cgi?do=view=5296

Jan Stary írta 2024. máj.. 7, K-n 08:47 órakor:
> On May 06 21:03:17, mytraddr...@gmail.com wrote:
>> Hi all,
>> 
>> can anyone please advise on what computer I can purchase with the following 
>> requirements:
>> 
>> - fully supports OpenBSD
>> - no noise
>> - good quality wifi
>> - small form factor preferably
>> - processor does not need to be fast (no highly intensive compute load)
>> - low RAM need
>> - needs 1 TB of hard drive at least
>> - will be used only remotely, for basic and low-intensity server-type 
>> applications (no desktop use)
>> - under $500
>
> PC Engiunes APU2, with a wifi card plugged in,
> and most of the $500 buying the 1 TB storage.
>
>
>
> OpenBSD 7.5-current (GENERIC.MP) #34: Sat Apr 27 21:19:57 MDT 2024
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 2112446464 (2014MB)
> avail mem = 2027487232 (1933MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7ee97040 (13 entries)
> bios0: vendor coreboot version "v4.19.0.1" date 01/31/2023
> bios0: PC Engines apu2
> acpi0 at bios0: ACPI 6.0
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST IVRS SSDT SSDT DRTM 
> HPET
> acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) 
> UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4)
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf800, bus 0-63
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD GX-412TC SOC, 998.17 MHz, 16-30-01, patch 07030105
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,HWPSTATE,ITSC,BMI1,XSAVEOPT
> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 
> 64b/line 16-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 99MHz
> cpu0: mwait min=64, max=64, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD GX-412TC SOC, 998.44 MHz, 16-30-01, patch 07030105
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,HWPSTATE,ITSC,BMI1,XSAVEOPT
> cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 
> 64b/line 16-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: AMD GX-412TC SOC, 998.37 MHz, 16-30-01, patch 07030105
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,HWPSTATE,ITSC,BMI1,XSAVEOPT
> cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 
> 64b/line 16-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: AMD GX-412TC SOC, 998.31 MHz, 16-30-01, patch 07030105
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,HWPSTATE,ITSC,BMI1,XSAVEOPT
> cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 
> 64b/line 16-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins
> ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins
> acpihpet0 at acpi0: 14318180 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PBR4)
> acpiprt2 at acpi0: bus 1 (PBR5)
> acpiprt3 at acpi0: bus -1 (PBR6)
> acpiprt4 at acpi0: bus 2 (PBR7)
> acpiprt5 at acpi0: bus -1 (PBR8)
> acpicpu0 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
> acpicpu1 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
> acpicpu2 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
> acpicpu3 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
> acpicpu4 at acpi0: no cpu matching ACPI ID 4
> acpicpu5 at acpi0: no cpu matching ACPI ID 5
> acpicpu6 at acpi0: no cpu matching ACPI ID 6
> acpicpu7 at acpi0: no cpu matching ACPI ID 7
> acpipci0 at acpi0 PCI0: 

Re: Hardware recommendation for small form factor, noiseless, server

[Jan Stary]

On May 06 21:03:17, mytraddr...@gmail.com wrote:
> Hi all,
> 
> can anyone please advise on what computer I can purchase with the following 
> requirements:
> 
> - fully supports OpenBSD
> - no noise
> - good quality wifi
> - small form factor preferably
> - processor does not need to be fast (no highly intensive compute load)
> - low RAM need
> - needs 1 TB of hard drive at least
> - will be used only remotely, for basic and low-intensity server-type 
> applications (no desktop use)
> - under $500

PC Engiunes APU2, with a wifi card plugged in,
and most of the $500 buying the 1 TB storage.



OpenBSD 7.5-current (GENERIC.MP) #34: Sat Apr 27 21:19:57 MDT 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2112446464 (2014MB)
avail mem = 2027487232 (1933MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7ee97040 (13 entries)
bios0: vendor coreboot version "v4.19.0.1" date 01/31/2023
bios0: PC Engines apu2
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST IVRS SSDT SSDT DRTM HPET
acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) 
UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD GX-412TC SOC, 998.17 MHz, 16-30-01, patch 07030105
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,HWPSTATE,ITSC,BMI1,XSAVEOPT
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 64b/line 
16-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 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD GX-412TC SOC, 998.44 MHz, 16-30-01, patch 07030105
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,HWPSTATE,ITSC,BMI1,XSAVEOPT
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 64b/line 
16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD GX-412TC SOC, 998.37 MHz, 16-30-01, patch 07030105
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,HWPSTATE,ITSC,BMI1,XSAVEOPT
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 64b/line 
16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD GX-412TC SOC, 998.31 MHz, 16-30-01, patch 07030105
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,HWPSTATE,ITSC,BMI1,XSAVEOPT
cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 64b/line 
16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PBR4)
acpiprt2 at acpi0: bus 1 (PBR5)
acpiprt3 at acpi0: bus -1 (PBR6)
acpiprt4 at acpi0: bus 2 (PBR7)
acpiprt5 at acpi0: bus -1 (PBR8)
acpicpu0 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu1 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu2 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu3 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu4 at acpi0: no cpu matching ACPI ID 4
acpicpu5 at acpi0: no cpu matching ACPI ID 5
acpicpu6 at acpi0: no cpu matching ACPI ID 6
acpicpu7 at acpi0: no cpu matching ACPI ID 7
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at acpi0 COM2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo
amdgpio0 at acpi0 GPIO uid 0 addr 0xfed81500/0x300 irq 7, 184 pins
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not 

Re: Hardware recommendation for small form factor, noiseless, server

[Martin]

On Mon, May 06, 2024 at 09:03:17PM +0100, James Johnson wrote:
> Hi all,
> 
> can anyone please advise on what computer I can purchase with the following \
> requirements: 
> - fully supports OpenBSD
> - no noise
> - good quality wifi
> - small form factor preferably
> - processor does not need to be fast (no highly intensive compute load)
> - low RAM need
> - needs 1 TB of hard drive at least
> - will be used only remotely, for basic and low-intensity server-type 
> applications \
> (no desktop use)
> - under $500
> 
> Thanks!
> James

The recommendation on the OpenBSD Router Guide site works really well:

https://openbsdrouterguide.net/#the-hardware

There are several different models.

Re: Hardware recommendation for small form factor, noiseless, server

[Zé Loff]

On Mon, May 06, 2024 at 09:03:17PM +0100, James Johnson wrote:
> Hi all,
> 
> can anyone please advise on what computer I can purchase with the following 
> requirements:
> 
> - fully supports OpenBSD
> - no noise
> - good quality wifi
> - small form factor preferably
> - processor does not need to be fast (no highly intensive compute load)
> - low RAM need
> - needs 1 TB of hard drive at least
> - will be used only remotely, for basic and low-intensity server-type 
> applications (no desktop use)
> - under $500
> 
> Thanks!
> James

You can get a Fujistu Futro S920 with a quad-core AMD GX-424GC @2.4GHz,
up to 8Gb RAM, for around €75.  Models with a GX-222GC (dual-core
@2.1GHz) or a GX-415GA (quad-core @1.5Ghz) go for even less.  Stick a
wifi card and a 2.5" disk in it, and bob's your uncle.

I have one as (very) low traffic web + mail server, and another as a
development machine running a VM with Alpine Linux hosting docker
containers (which works better than I anticipated, honestly).

dmesg for a model with a GX-222CG dual-core @2.2GHz (no wifi, though):

OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8213266432 (7832MB)
avail mem = 7943299072 (7575MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xacfdc018 (55 entries)
bios0: vendor FUJITSU // American Megatrends Inc. version "V4.6.5.4 R1.16.0 for 
D3313-G1x" date 08/13/2018
bios0: FUJITSU FUTRO S920
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT TCPA MCFG HPET SSDT SSDT SSDT SSDT SSDT
acpi0: wakeup devices LAN1(S4) LAN2(S4) LAN3(S4) SBAZ(S4) EHC1(S4) EHC2(S4) 
EHC3(S4) XHC0(S4) GFX_(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 GX-222GC SOC with Radeon(TM) R5E Graphics, 2196.02 MHz, 16-30-01, 
patch 07030106
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POP
 
CNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL
 3,HWPSTATE,ITSC,BMI1,IBPB,XSAVEOPT
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 1MB 64b/line 
16-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 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD GX-222GC SOC with Radeon(TM) R5E Graphics, 2196.05 MHz, 16-30-01, 
patch 07030106
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POP
 
CNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL
 3,HWPSTATE,ITSC,BMI1,IBPB,XSAVEOPT
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 1MB 64b/line 
16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 3 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 4 pa 0xfec01000, version 21, 32 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (GPP0)
acpiprt2 at acpi0: bus -1 (GPP1)
acpiprt3 at acpi0: bus -1 (GPP2)
acpiprt4 at acpi0: bus -1 (GPP3)
acpiprt5 at acpi0: bus -1 (GFX_)
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
com0 at acpi0 UAR0 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
com0: console
acpicmos0 at acpi0
com1 at acpi0 UAR1 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo
"FUJ02E3" at acpi0 not configured
acpibtn0 at acpi0: PWRB
tpm0 at acpi0 TPM_ 1.2 (TIS) addr 0xfed4/0x5000, device 0x001a15d1 rev 0x10
acpicpu0 at acpi0: C2(0@400 io@0x414), C1(@1 halt!), PSS
acpicpu1 at acpi0: C2(0@400 io@0x414), C1(@1 halt!), PSS
acpivideo0 at acpi0: VGA_
acpivout0 at acpivideo0: LCD_
acpivideo1 at acpi0: VGA_
cpu0: 2196 MHz: speeds: 2200 2000 1800 1600 1400 1200 1000 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD 16h Root Complex" rev 0x00
radeondrm0 at pci0 dev 1 function 0 "ATI Mullins" rev 0x06
drm0 at radeondrm0
radeondrm0: msi
azalia0 at pci0 dev 1 function 1 "ATI Radeon HD Audio" rev 0x00: msi
azalia0: no supported codecs
pchb1 at pci0 dev 2 function 0 "AMD 16h Host" rev 0x00
ppb0 at pci0 dev 2 function 2 "AMD 16h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G (0x4c00), 
msi, address 4c:52:62:11:13:ef
rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
ccp0 at pci0 dev 8 function 0 "AMD 16h Crypto" rev 0x00
ahci0 at pci0 dev 17 function 0 "AMD Hudson-2 SATA" rev 0x40: msi, AHCI 1.3
ahci0: port 0: 

Re: Hardware recommendation for small form factor, noiseless, server

[Jo MacMahon]

I recently switched my RockPro64 over to OpenBSD and so far everything works 
nicely with it. I had trouble getting it to boot at first, but it was my fault 
for not fully reading the installation instructions[1], and assuming that I 
could simply `dd` the provided miniroot75.img to an SD card and boot. In fact 
you also have to write bootloader firmware to certain constant addresses on the 
SD card, depending on which board you use.

I also would have been lost without a UART USB adapter.

[1] https://ftp.openbsd.org/pub/OpenBSD/7.5/arm64/INSTALL.arm64

Re: Hardware recommendation for small form factor, noiseless, server

[Implausibility]

For various values of 'fully supports', I have multiple odroid HC4 units, and 
they all run very well.  I've booted them with OpenBSD to play with it, but 
inevitably switched back to Linux.  No built-in WiFi, but it has a single USB 
socket that you could plug in a WiFi/Bluetooth dongle.

-JD.

> On May 6, 2024, at 4:03 PM, James Johnson  wrote:
> 
> Hi all,
> 
> can anyone please advise on what computer I can purchase with the following 
> requirements:
> 
> - fully supports OpenBSD
> - no noise
> - good quality wifi
> - small form factor preferably
> - processor does not need to be fast (no highly intensive compute load)
> - low RAM need
> - needs 1 TB of hard drive at least
> - will be used only remotely, for basic and low-intensity server-type 
> applications (no desktop use)
> - under $500
> 
> Thanks!
> James

Hardware recommendation for small form factor, noiseless, server

[James Johnson]

Hi all,

can anyone please advise on what computer I can purchase with the following 
requirements:

- fully supports OpenBSD
- no noise
- good quality wifi
- small form factor preferably
- processor does not need to be fast (no highly intensive compute load)
- low RAM need
- needs 1 TB of hard drive at least
- will be used only remotely, for basic and low-intensity server-type 
applications (no desktop use)
- under $500

Thanks!
James

Re: Does anyone know whether this hardware runs OpenBSD?

[Anders Andersson]

On Tue, Mar 26, 2024 at 1:07 AM Jose Maldonado  wrote:
>
> El Mon, 25 Mar 2024 04:39:15 -0400
> Steve Litt  escribió:
> > Does anyone know whether this hardware runs OpenBSD?
> >
> > https://www.walmart.com/ip/MeLE-Quieter3Q-Fanless-Mini-PC-N5105-Windows-11-8GB-256GB-4K-UHD-Wifi-6-Mini-Desktop-Computer-New/2177929669
> >
> > Thanks,
> >
> > SteveT
> >
> > Steve Litt
> >
> > Autumn 2023 featured book: Rapid Learning for the 21st Century
> > http://www.troubleshooters.com/rl21
> >
>
> Hi! Why not this?
>
> https://www.pcliquidations.com/p150914-hp-elitedesk-705-g4
>
> Better hardware and OpenBSD support

Why not a full desktop PC? How are these even comparable? Your
suggestion is more than 5 times as large and heavy, and it even has a
fan.

Re: Does anyone know whether this hardware runs OpenBSD?

[Jose Maldonado]

El Mon, 25 Mar 2024 04:39:15 -0400
Steve Litt  escribió:
> Does anyone know whether this hardware runs OpenBSD?
> 
> https://www.walmart.com/ip/MeLE-Quieter3Q-Fanless-Mini-PC-N5105-Windows-11-8GB-256GB-4K-UHD-Wifi-6-Mini-Desktop-Computer-New/2177929669
> 
> Thanks,
> 
> SteveT
> 
> Steve Litt 
> 
> Autumn 2023 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
> 

Hi! Why not this?

https://www.pcliquidations.com/p150914-hp-elitedesk-705-g4

Better hardware and OpenBSD support 

-- 
*
Dios en su cielo, todo bien en la Tierra

Re: Does anyone know whether this hardware runs OpenBSD?

[Mike Larkin]

On Mon, Mar 25, 2024 at 04:39:15AM -0400, Steve Litt wrote:
> Does anyone know whether this hardware runs OpenBSD?
>
> https://www.walmart.com/ip/MeLE-Quieter3Q-Fanless-Mini-PC-N5105-Windows-11-8GB-256GB-4K-UHD-Wifi-6-Mini-Desktop-Computer-New/2177929669
>
> Thanks,
>
> SteveT
>
> Steve Litt
>
> Autumn 2023 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
>

We've seen some of those cheap "router PCs" with bad broken BIOS. There were
a few all using the same common motherboard that had stuck GPEs a few years
ago. Since most of these machines don't have a manufacturer website for
BIOS updates, tracking down an updated BIOS without risking bricking the machine
is sorta a pain.

You get what you pay for.

-ml

Re: Does anyone know whether this hardware runs OpenBSD?

[Odhiambo Washington]

On Mon, Mar 25, 2024 at 11:41 AM Steve Litt 
wrote:

> Does anyone know whether this hardware runs OpenBSD?
>
>
> https://www.walmart.com/ip/MeLE-Quieter3Q-Fanless-Mini-PC-N5105-Windows-11-8GB-256GB-4K-UHD-Wifi-6-Mini-Desktop-Computer-New/2177929669
>
> Thanks,
>
> SteveT
>
> Steve Litt


I guess it should. I have one variant of these
<https://www.amazon.com/gp/product/B0B7764P39/ref=ppx_od_dt_b_asin_title_s00?ie=UTF8=1>
being used by my client as a "mail server", but it's running Windows.
I have installed an OpenBSD VM on it and here is the output of dmesg:

```
OpenBSD 7.4 (GENERIC.MP) #1397: Tue Oct 10 09:02:37 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2129526784 (2030MB)
avail mem = 2045325312 (1950MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0010 (248 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 11/12/2020
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3)
S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3)
S1F0(S3) PE50(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) N5105 @ 2.00GHz, 1997.42 MHz, 06-9c-00
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,RSBA,IF_PSCHANGE,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB
64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 66MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Celeron(R) N5105 @ 2.00GHz, 1997.81 MHz, 06-9c-00
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,RSBA,IF_PSCHANGE,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB
64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Celeron(R) N5105 @ 2.00GHz, 1997.76 MHz, 06-9c-00
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,RSBA,IF_PSCHANGE,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB
64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu2: smt 0, core 0, package 1
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Celeron(R) N5105 @ 2.00GHz, 1997.62 MHz, 06-9c-00
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,RSBA,IF_PSCHANGE,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB
64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu3: smt 0, core 1, package 1
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-127
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
"PNP0A05" at acpi0 not configured
acpiac0 at acpi0: AC unit online
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpicpu2 at acpi0: C1(@1 halt!)
acpicpu3 at acpi0: C1(@1 halt!)
cpu0: using VERW MDS workaround (except on vmm entry)
pvbus0 at mainbus0: VMware
vmt0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01
pci1 at ppb0 bus 1
pcib0 at pci0 dev 7 function 0 "

Re: Does anyone know whether this hardware runs OpenBSD?

[Dave Voutila]

Steve Litt  writes:

> Does anyone know whether this hardware runs OpenBSD?
>
> https://www.walmart.com/ip/MeLE-Quieter3Q-Fanless-Mini-PC-N5105-Windows-11-8GB-256GB-4K-UHD-Wifi-6-Mini-Desktop-Computer-New/2177929669

Maybe... Looking at:

https://www.cnx-software.com/2022/06/03/mele-quieter3q-review-ultra-thin-fanless-mini-pc-tested-with-windows-11-ubuntu-22-04/

It seems to use components that should be supported. The wifi might work
with iwx(4). Not sure about the mmc controller, so whatever works with
that m.2 slot you might want to put in some storage that way.

For anyone curious, that link has a dmesg from Ubuntu 22.04 on the
machine in question.

>
> Thanks,
>
> SteveT
>
> Steve Litt
>
> Autumn 2023 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21

Does anyone know whether this hardware runs OpenBSD?

[Steve Litt]

Does anyone know whether this hardware runs OpenBSD?

https://www.walmart.com/ip/MeLE-Quieter3Q-Fanless-Mini-PC-N5105-Windows-11-8GB-256GB-4K-UHD-Wifi-6-Mini-Desktop-Computer-New/2177929669

Thanks,

SteveT

Steve Litt 

Autumn 2023 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[offtopic] hardware routers failing

[beecdaddict]

hello
I have problem while running program i2pd and increasing bandwidth/number of
tunnels, router fails and internet connectivity network-wide goes down, router
restarts it after a few seconds up to minutes

someone told me this:

> For an ISP "customer premises equipment" router (home/officr router)?
> That often means you made too many connections and exceeded the size of
> NAT/firewall state table that they can cope with. Also for ISPs with
> CGN, you might have a limited port-range that you're allowed to use and
> can't make more connections once that has been exceeded.

the 1st problem can be solved by custom router running OpenBSD, yes?
how can I make sure it's 1st solution without buying/making router?
ISP says there is nothing they can do or they act dumb

can someone help me?
thank you
- best regards

firewall hardware

[Alexei Malinin]

Hello!

Please advise me hardware for an OpenBSD firewall:
- 8 gigabit ethernet interfaces,
- >= 4 Gbps throughput.


Thanks,
Alexei

Re: keepassxc-2.7 + Hardware Key

[0x1eef]

> Hi, anyone using keepassxc-2.7.4p2 with a hardware dongle - preferably
> opensource or DIY type - succesfully in OpenBSD?

I have used ordinary USB storage, and 'pash' in the past:
https://github.com/dylanaraps/pash#readme

It does not sound as solid as what you're looking for,
but somewhat similar I guess.

Re: keepassxc-2.7 + Hardware Key

[Christoff Humphries]

--- Original Message ---
On Monday, October 2nd, 2023 at 5:18 PM, Mike Coddington  
wrote:
> 
> > On Oct 2, 2023, at 2:09 PM, m...@phosphorus.com.br wrote:
> > 
> > ping
> > 
> > On 9/30/23 07:39, m...@phosphorus.com.br wrote:
> > 
> > > Hi, anyone using keepassxc-2.7.4p2 with a hardware dongle - preferably 
> > > opensource or DIY type - succesfully in OpenBSD?
> 
> Perhaps the answer you've found is that it's only you doing this. "Ping"-ing 
> us all because nobody responded is wasting everyone's time. And next time, 
> don't top-post. It's rude.

Come on, dude...

Is top posting as rude as not respecting the character line 
length? Netiquette on https://www.openbsd.org/mail.html

There are many reasons why folks don't get a reply, I've seen 
plenty of folks also ping to get replies. People miss things.
I see it on ports@ all the time.  

It may be a niche question or it may not be, who knows what
all the folks are up to that are on these lists, you know?
And this is misc@ for pete's sake, not like messages here
are wasting anyone's time, outside of the time sink of 
simply being on this list. Frankie says relax. 

Re: keepassxc-2.7 + Hardware Key

[Stuart Henderson]

I don't think the keepassxc-2.7.4p2 package will support any hardware keys.
There is a -yubikey flavour (i.e. the keepassxc-2.7.4p2-yubikey package) which
might work with a yubikey. Never tried it though.


On 2023-10-02, Mike Coddington  wrote:
>
>
>> On Oct 2, 2023, at 2:09 PM, m...@phosphorus.com.br wrote:
>> 
>> ping
>> 
>> On 9/30/23 07:39, m...@phosphorus.com.br wrote:
>>> Hi, anyone using keepassxc-2.7.4p2 with a hardware dongle - preferably 
>>> opensource or DIY type - succesfully in OpenBSD?
>>> 
>>> 
>
>
> Perhaps the answer you've found is that it's only you doing this. "Ping"-ing 
> us all because nobody responded is wasting everyone's time. And next time, 
> don't top-post. It's rude.
>
>


-- 
Please keep replies on the mailing list.

Re: keepassxc-2.7 + Hardware Key

[Mike Coddington]

> On Oct 2, 2023, at 2:09 PM, m...@phosphorus.com.br wrote:
> 
> ping
> 
> On 9/30/23 07:39, m...@phosphorus.com.br wrote:
>> Hi, anyone using keepassxc-2.7.4p2 with a hardware dongle - preferably 
>> opensource or DIY type - succesfully in OpenBSD?
>> 
>> 


Perhaps the answer you've found is that it's only you doing this. "Ping"-ing us 
all because nobody responded is wasting everyone's time. And next time, don't 
top-post. It's rude.

Re: keepassxc-2.7 + Hardware Key

[misc]

ping

On 9/30/23 07:39, m...@phosphorus.com.br wrote:
Hi, anyone using keepassxc-2.7.4p2 with a hardware dongle - preferably 
opensource or DIY type - succesfully in OpenBSD?



--

Fabio

keepassxc-2.7 + Hardware Key

[misc]

Hi, anyone using keepassxc-2.7.4p2 with a hardware dongle - preferably 
opensource or DIY type - succesfully in OpenBSD?



--

Fabio

Re: ipsec hardware recommendation

[Marko Cupać]

Hi,

thank you for suggestions, took me some time to think about them and
reply here.

On Fri, 11 Aug 2023 14:19:44 - (UTC)
Stuart Henderson  wrote:

> If you post your IPsec configuration, perhaps someone can suggest
> whether the choice of ciphers etc could be improved. It can make
> quite a difference.

I have just recently bumped quick enc from aes-128-gcm to aes-256-gcm,
as well as group from modp3072 to ecp256:

ike passive esp transport proto gre from $me to $peer \
  main auth hmac-sha2-256 enc aes-256 group ecp256 lifetime 24h \
  quick enc aes-256-gcm group ecp256 lifetime 8h

I have also increased lifetime from default values because I was
getting quite a lot of INVALID COOKIE messages from isakmpd:

isakmpd[51306]: message_recv: invalid cookie(s) cookiea cookieb
isakmpd[51306]: dropped message from $peer port 500 due to notification
type INVALID_COOKIE


On Sat, 12 Aug 2023 12:17:36 +1000
David Gwynne  wrote:

> The things you can do Right Now(tm) are:
> 
> - upgrade to -current
> 
> the pf purge code has been taken out from under the big kernel lock.
> if you have a lot of pf states, this will give more time to crypto.

I have ~50,000 states during peak time. I can't go -current, but I will
look forward to 7.4. I also read the following articles on undeadly.org:

https://undeadly.org/cgi?action=article;sid=20230807094305
https://undeadly.org/cgi?action=article;sid=20230706115843

Once 7.4 hits, is it expected that changing gre/ipsec to sec(4) could
make positive difference in throughput on same hardware?

> - pick faster crypto algorithms

I posted mine above, I would be thankful to get latest recommendation.

> - try wireguard?

I am testing replacing a few of gre/ipsec with wg interfaces on 7.3 at
the moment. Main problem I am encountering so far is the fact that
`ospfctl reload` does not seem to pick newly added (to ospfd.conf) wg
interfaces. `ospfctl sh int` shows them in DOWN state after reload, and
no OSPFv2-hello packets are being sent until `rcctl restart ospfd`.

It is quite unmaintainable to have to restart ospfd every time
wg interfaces are added or removed from ospfd.conf. Any way around it?
Perhaps on some later releases this will improve? Or am I doing it
wrong?

I have more questions about wireguard but I guess I should better ask
them in another topic.

Thank you in advance,

-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: non-hardware 2fa options for openssh

[Stuart Henderson]

On 2023-08-29, myml...@gmx.com  wrote:
> My question is there any recent documentation / information on setting
> up an openssh server with non-hardware based two factor authentication? 
> This does NOT have to be google authenticator, any similar service will
> suffice.

if an ssh key is good enough to be considered as one factor, and a
password as the second, you can use

AuthenticationMethods "publickey,password"
PasswordAuthentication yes

which requires both the ssh key and password

Re: non-hardware 2fa options for openssh

[Stuart Henderson]

On 2023-08-29, Daniel Jakots  wrote:
> You can also want to look at sysutils/login_oath (which I've been using
> for years), but maybe for new setups, the login_totp from base makes
> more sense.

you might be thinking of login_yubikey which is in base, but it has no
way to sync the counter between machines, so it is a very bad idea to
use the same key with this on more than one machine.

Re: non-hardware 2fa options for openssh

[Daniel Jakots]

On Tue, 29 Aug 2023 13:18:53 -0400, Dave Voutila  wrote:

> > You can also want to look at sysutils/login_oath (which I've been
> > using for years), but maybe for new setups, the login_totp from
> > base makes more sense.
> >  
> 
> login_totp is in base?

Wow, I was sure https://github.com/reyk/login_otp was imported, and the
man I was looking at actually comes from sysutilis/login_oauth lol

thanks for catching my mistake!

Re: non-hardware 2fa options for openssh

[Dave Voutila]

Daniel Jakots  writes:

> On Tue, 29 Aug 2023 10:07:18 -0500, "myml...@gmx.com" 
> wrote:
>
>> Hi All,
>>
>> I want to secure an openssh server with two factor authentication and
>> have seen the hardware token methods, most recently i've been seeing
>> yubi/FIDO methods.
>>
>> Ideally I would like to avoid having to depend on a usb size device
>> that could easily be lost.
>
> Using something based on TOTP (Cf. rfc6238) is probably your best bet
> then.
>
>> I looked around and found mention of google authenticator as an
>> option, phones aren't much bigger than usb sticks but people protect
>> their phone as if it was their soul, but the newest mention I can
>> find is many years old.
>
> AFAIK, google authenticator is simply an app doing the math for TOTP.
> There are multiple basic opensource apps (on both Android and iphones)
> which can provide you with the right TOTP based on the seed/secret.
>
> And if you don't want to use a phone, you can use oathtool(1) from
> security/oath-toolkit.
> I think some password managers also are able to generate the TOTP.
>
>> My question is there any recent documentation / information on setting
>> up an openssh server with non-hardware based two factor
>> authentication? This does NOT have to be google authenticator, any
>> similar service will suffice.
>
> login_totp(8), login.conf(5), sshd_config(5), and maybe a couple of
> others.
>
> You can also want to look at sysutils/login_oath (which I've been using
> for years), but maybe for new setups, the login_totp from base makes
> more sense.
>

login_totp is in base?

Re: non-hardware 2fa options for openssh

[Daniel Jakots]

On Tue, 29 Aug 2023 10:07:18 -0500, "myml...@gmx.com" 
wrote:

> Hi All,
> 
> I want to secure an openssh server with two factor authentication and
> have seen the hardware token methods, most recently i've been seeing
> yubi/FIDO methods.
> 
> Ideally I would like to avoid having to depend on a usb size device
> that could easily be lost.

Using something based on TOTP (Cf. rfc6238) is probably your best bet
then.

> I looked around and found mention of google authenticator as an
> option, phones aren't much bigger than usb sticks but people protect
> their phone as if it was their soul, but the newest mention I can
> find is many years old.

AFAIK, google authenticator is simply an app doing the math for TOTP.
There are multiple basic opensource apps (on both Android and iphones)
which can provide you with the right TOTP based on the seed/secret.

And if you don't want to use a phone, you can use oathtool(1) from
security/oath-toolkit.
I think some password managers also are able to generate the TOTP.

> My question is there any recent documentation / information on setting
> up an openssh server with non-hardware based two factor
> authentication? This does NOT have to be google authenticator, any
> similar service will suffice.

login_totp(8), login.conf(5), sshd_config(5), and maybe a couple of
others.

You can also want to look at sysutils/login_oath (which I've been using
for years), but maybe for new setups, the login_totp from base makes
more sense.

Have fun,
Daniel 

non-hardware 2fa options for openssh

[myml...@gmx.com]

Hi All,

I want to secure an openssh server with two factor authentication and
have seen the hardware token methods, most recently i've been seeing
yubi/FIDO methods.

Ideally I would like to avoid having to depend on a usb size device that
could easily be lost.

I looked around and found mention of google authenticator as an option,
phones aren't much bigger than usb sticks but people protect their phone
as if it was their soul, but the newest mention I can find is many years
old.

My question is there any recent documentation / information on setting
up an openssh server with non-hardware based two factor authentication? 
This does NOT have to be google authenticator, any similar service will
suffice.

Any advice greatly appreciated

Thanks in advance.

Re: ipsec hardware recommendation

[David Gwynne]

> On 11 Aug 2023, at 21:08, Marko Cupać  wrote:
> 
> Hi,
> 
> I have star topology network where dozens of spokes communicate with
> other spokes through central hub over GRE tunnels protected with
> transport-mode ipsec.
> 
> This worked great for years, but lately all the locations got bandwidth
> upgrade (spokes: 10Mbit -> 50Mbit, hub: 2x200Mbit -> 2x500Mbit), and I'm
> starting to experience problems.
> 
> Spokes have APU4D4s, and my tests show they can push up to 30Mbit/s of
> ipsec bidirectionally. Hub has HPE DL360g9 with Xeon CPU E5-2623 v4 @
> 2.60GHz and bge NICs, and it seems it can push no more than 200Mbit/s
> of ipsec bidirectionally (I have no chance to test this thoroughly in a
> lab, but what I see in production indicate this strongly).
> 
> Are there any commands I can run which would indicate ipsec traffic is
> being throttled due to hardware being underspecced? top shows CPU is
> more than 50% idle. netstat shows ~1 Ierrs / Ifail (no Oerrs /
> Ifail) on interfaces that deal with ipsec for two months worth of
> uptime.
> 
> Would replacing Xeon box with AMD EPYC 7262 likely result in an
> improvement? Should I go for some NICs other than bge? What hardware do
> I need at Hub location to accomodate ~400Mbit/s of ipsec
> bidirectionally?

>From recent experience it looks like IPsec, and the crypto processing in 
>particular, still runs under the giant kernel lock. This means you're only 
>going to go as fast as a single core can go, and you'll be particularly 
>sensitive to contention on that lock. The things you can do Right Now(tm) are:

- upgrade to a system with the fastest single core performance you can afford

- upgrade to -current

the pf purge code has been taken out from under the big kernel lock. if you 
have a lot of pf states, this will give more time to crypto.

- pick faster crypto algorithms

you might already be using the fastest, so maybe this wont help.

- terminate ipsec on multiple hosts

two kernels will be faster than one. however, this adds complexity to the 
network, so not an obvious benefit.

- try wireguard?

if it's a single tunnel IP tunnel (ie, one gre(4), and not egre(4)) between the 
hubs and spokes then wg might be simpler and faster. simpler because wg is less 
layers than gre over ipsec, and faster cos it should be able to do crypto in 
parallel.


in the future i'm sure the ipsec stack will improve, but it's hard work that 
takes time.

dlg

> 
> Thank you in advance,
> 
> 
> -- 
> Before enlightenment - chop wood, draw water.
> After  enlightenment - chop wood, draw water.
> 
> Marko Cupać
> https://www.mimar.rs/
> 

Re: ipsec hardware recommendation

[Stuart Henderson]

On 2023-08-11, Marko Cupać  wrote:
> Hi,
>
> I have star topology network where dozens of spokes communicate with
> other spokes through central hub over GRE tunnels protected with
> transport-mode ipsec.
>
> This worked great for years, but lately all the locations got bandwidth
> upgrade (spokes: 10Mbit -> 50Mbit, hub: 2x200Mbit -> 2x500Mbit), and I'm
> starting to experience problems.
>
> Spokes have APU4D4s, and my tests show they can push up to 30Mbit/s of
> ipsec bidirectionally. Hub has HPE DL360g9 with Xeon CPU E5-2623 v4 @
> 2.60GHz and bge NICs, and it seems it can push no more than 200Mbit/s
> of ipsec bidirectionally (I have no chance to test this thoroughly in a
> lab, but what I see in production indicate this strongly).

If possible, I suggest putting a fast client machine (laptop or
server) on local network near the server and doing some tests that way.

If you post your IPsec configuration, perhaps someone can suggest
whether the choice of ciphers etc could be improved. It can make quite a
difference.

> Are there any commands I can run which would indicate ipsec traffic is
> being throttled due to hardware being underspecced? top shows CPU is
> more than 50% idle. netstat shows ~1 Ierrs / Ifail (no Oerrs /
> Ifail) on interfaces that deal with ipsec for two months worth of
> uptime.
>
> Would replacing Xeon box with AMD EPYC 7262 likely result in an
> improvement? Should I go for some NICs other than bge? What hardware do
> I need at Hub location to accomodate ~400Mbit/s of ipsec
> bidirectionally?

I doubt the NIC choice will be hugely important, in terms of overall
network traffic pretty much anything should be able to cope with the
available bandwidth.

EPYC is certainly a bunch faster than the 2016 Xeon, but the 'Jaguar'
AMDs in the APUs are going to be the slowest point overall.

You also don't mention which OpenBSD versions you're using. That could
make quite a difference.

-- 
Please keep replies on the mailing list.

Re: ipsec hardware recommendation

[Matthew Ernisse]

On Fri, Aug 11, 2023 at 01:08:07PM +0200, Marko Cupać said:

Are there any commands I can run which would indicate ipsec traffic is
being throttled due to hardware being underspecced? top shows CPU is
more than 50% idle. netstat shows ~1 Ierrs / Ifail (no Oerrs /
Ifail) on interfaces that deal with ipsec for two months worth of
uptime.


I believe the crypto work will show up as system% in systat(1) and 
top(1).  I'm not sure if it is still the case but at one point it was 
single-threaded.



Would replacing Xeon box with AMD EPYC 7262 likely result in an
improvement? Should I go for some NICs other than bge? What hardware do
I need at Hub location to accomodate ~400Mbit/s of ipsec
bidirectionally?


I would start by testing your throughput without ipsec to a system on 
your local ethernet segment.  Maybe using something like iperf.  If you 
can exceed your ipsec throughput you know it probably isn't the NIC

driver.  Try to set it up so you are testing forwarding performance.
I have a Xeon D-1521 with ix(4) NICs and I can forward enough 
(unencrypted traffic) to saturate the 1Gbe ports on the switch.


--
Please direct replies to the list.

ipsec hardware recommendation

[Marko Cupać]

Hi,

I have star topology network where dozens of spokes communicate with
other spokes through central hub over GRE tunnels protected with
transport-mode ipsec.

This worked great for years, but lately all the locations got bandwidth
upgrade (spokes: 10Mbit -> 50Mbit, hub: 2x200Mbit -> 2x500Mbit), and I'm
starting to experience problems.

Spokes have APU4D4s, and my tests show they can push up to 30Mbit/s of
ipsec bidirectionally. Hub has HPE DL360g9 with Xeon CPU E5-2623 v4 @
2.60GHz and bge NICs, and it seems it can push no more than 200Mbit/s
of ipsec bidirectionally (I have no chance to test this thoroughly in a
lab, but what I see in production indicate this strongly).

Are there any commands I can run which would indicate ipsec traffic is
being throttled due to hardware being underspecced? top shows CPU is
more than 50% idle. netstat shows ~1 Ierrs / Ifail (no Oerrs /
Ifail) on interfaces that deal with ipsec for two months worth of
uptime.

Would replacing Xeon box with AMD EPYC 7262 likely result in an
improvement? Should I go for some NICs other than bge? What hardware do
I need at Hub location to accomodate ~400Mbit/s of ipsec
bidirectionally?

Thank you in advance,


-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Hardware Available for Port Maintenance (Maryland, USA)

[Alexander Jacocks]

Re: BGP Router Hardware Suggestions

[Zack Newman]

On 7/3/23 12:59, Rachel Roth wrote:


For the record, "API not working" is not exclusively about mediaopt
settings.  "API not working" also kills SFP DOM stats, something which
is quite useful when troubleshooting with third-parties on the other
side of your fibre link.



When someone on the other side of the phone asks for "light levels",
its rather nice to be able to give them an answer  ;-)


Yeah, I understand. That is why my first e-mail only recommended a
copper-based solution if one insists on using the most recent firmware.
Then upon learning that autonegotiation is only a thing for Ethernet
over twisted pair, I revised the recommendation more conservatively to
only include SFP+ DAC solutions since I would not be surprised if X710
does not work on the most recent firmware for something like the
X710-T4L network interface adapter.

With something like the X710-DA2-more relevantly for the OP, the
X710-DA4-it definitely works, and "light levels" are obviously not a
thing. As a result, one might be able to get 10 Gbps if one is willing
to use a different controller (e.g., X520), use an older firmware for
X710, or use an X710 SFP+ DAC adapter in addition to using "amd fast,
not intel fast" CPU cores.

Of course as mentioned and likely known, SFP+ DAC may not be a
possibility if EMI is an issue, the runs are very long, or fiber is
forced upon you by the other end. If not though; then enjoy the cheaper,
equally performant, and less power hungry passive SFP+ DAC solution.

Re: BGP Router Hardware Suggestions

[Rachel Roch]

2 Jul 2023, 22:58 by z...@philomathiclife.com:

>  As a result, there is not much to "negotiate"
> anyway. In summary if 10GSFP+Cu is acceptable, then you shouldn't worry
> about the API not working on OpenBSD.
>

For the record, "API not working" is not exclusively about mediaopt settings.  
"API not working" also kills SFP DOM stats, something which is quite useful 
when troubleshooting with third-parties on the other side of your fibre link.

When someone on the other side of the phone asks for "light levels", its rather 
nice to be able to give them an answer  ;-)

Re: BGP Router Hardware Suggestions

[Zack Newman]

On 7/1/23 18:26, Zack Newman wrote:

As Rachel pointed out, OpenBSD 7.3 does not work with the API of that
NIC when the newest firmware is flashed. Not sure what the most recent
version of firmware that has a working API is, but it is not a problem
for me since autonegotiation works just fine. If you don't require very
long runs and EMI is not an issue, then you should be fine with the
copper solution.


Ah, I was unaware that autonegotiation was only a thing for Ethernet
over twisted pair; so my setup did not rely on autonegotiation which
makes it even less surprising that my setup works. 10 Gigabit Ethernet
only works in full-duplex, and the SFP+ DAC Twinax cables only work for
one speed (i.e., 10 Gbps). As a result, there is not much to "negotiate"
anyway. In summary if 10GSFP+Cu is acceptable, then you shouldn't worry
about the API not working on OpenBSD.

Re: BGP Router Hardware Suggestions

[Zack Newman]

I don't have any 10 Gbps NICs, so I cannot comment on that level of
throughput. I do have a couple 2.5 Gbps machines, and my system
saturates them with ease. No way to know if there is 7.5 Gbps more I
could get out of them without actually testing it.

Motherboard: Supermicro X13SAE flashed with newest BIOS.
CPU: Intel i5-13600K with iGPU underclocked.
RAM: 2 x 16 GiB DDR5-4400MHz unbuffered ECC modules.
Network interface adapter: Intel X710-DA2 flashed with newest firmware.

Switch: Juniper EX2300-24MP

Server and switch are connected via a dual-compatible SFP+ DAC Twinax
cable from FS.com.

The network interface adapter is a genuine Intel. It is _not_ an OEM
one. I didn't want to deal with any headaches when it comes to flashing
firmware.

I disabled SMT as well as the efficiency cores on the CPU. I tried to
reduce the use of the integrated GPU as much as I could. No inteldrm.
Only connected via a serial console. The reason for that CPU is that
the equivalent CPU without an iGPU was not officially listed as ECC
capable, so I played it safe and got the iGPU version. That CPU only
has 6 performance cores though; and as one of Stuart's links showed,
this means I am only using 4 queues instead of maxing out the card at
8. Had I known this, I would have gotten the CPU one level up which has
8 performance cores.

My machine does a lot more than just routing and firewall though. It
runs a web server, git repos, e-mail, DNS, authoritative nameserver, and
VPN servers just to name a few things. Despite all that, it handles 2.5
Gbps no problem. I haven't done any form of tuning (e.g., using MTUs
larger than 1500) either.

As Rachel pointed out, OpenBSD 7.3 does not work with the API of that
NIC when the newest firmware is flashed. Not sure what the most recent
version of firmware that has a working API is, but it is not a problem
for me since autonegotiation works just fine. If you don't require very
long runs and EMI is not an issue, then you should be fine with the
copper solution.

Re: BGP Router Hardware Suggestions

[Stuart Henderson]

On 2023-06-29, Lyndon Nerenberg (VE7TFX/VE6BBM)  wrote:
> We are about to discover the joys of upstream BGP routing :-P  The
> current plan is to use a pair of OpenBSD+bgpd hosts as the routers.
>
> Each host will require 4x10gig ports (SFP+).  One of those links
> (to AWS) will be close to saturated, along with the downlink to our
> switches.  The other two will only need to carry ~1Gb/s of traffic.
>
> We are pretty much a Supermicro shop, and I'm wondering if anyone
> out there is running a similar setup on SM hardware.  My main concern
> is finding NICs that will let us squeeze every last drop of bandwidth
> on the 10gig links.

I don't need full 10G and haven't benchmarked anything recently, but
Hrvoje has done a lot of testing in this area, see comments at
https://marc.info/?l=openbsd-misc=167665861931266=2

For servers, look at the AMD boards e.g. M11SDV-based systems like
https://www.supermicro.com/Aplus/system/Embedded/AS-5019D-FTN4.cfm

Sadly Supermicro seem to have stopped doing boards with 4x fibre
module slots, so you'll be stuck with needing PCIe NICs for the
newer boards. (Newer xeon d boards have 2xSFP28 plus copper;
networking on their AMD boards tend to be copper only).

I would probably favour ix(4) i.e. X520 (for one thing, firmware is less
of a moving target..)

> I did run some brief ttcp tests on a pair of SM 1Us (don't have the
> model number handy, maybe 5018-FTN4s?) with add-in Intel cards
> (550s?) and was able to get 700 MBytes/s of throughput.  This would
> have been circa the 6.7 or 6.8 releases.

A lot changed since then. See some stats over time at
http://bluhm.genua.de/perform/results/perform.html
(especially forwarding tests).

Don't test packet generation on the box itself if you care about
forwarding. Generate packets elsewhere and pass them through
the device under test.

Re: BGP Router Hardware Suggestions

[Rachel Roch]

29 Jun 2023, 23:57 by lyn...@orthanc.ca:

> We are about to discover the joys of upstream BGP routing :-P  The
> current plan is to use a pair of OpenBSD+bgpd hosts as the routers.
>
> Each host will require 4x10gig ports (SFP+).  One of those links
> (to AWS) will be close to saturated, along with the downlink to our
> switches.  The other two will only need to carry ~1Gb/s of traffic.
>
> We are pretty much a Supermicro shop, and I'm wondering if anyone
> out there is running a similar setup on SM hardware.  My main concern
> is finding NICs that will let us squeeze every last drop of bandwidth
> on the 10gig links.
>


I have had excellent luck on 1g using HotLava (https://www.hotlavasystems.com/) 
cards which are Intel based but custom design.

I am currently working on upgrading parts of my network to 10g, also using 
HotLava, but sadly the OpenBSD devs need to update the ixl drivers to match the 
newer Intel API because at the moment stuff like "ifconfig ixl sff" returns 
nothing when it should return transciever DOM data.

BGP Router Hardware Suggestions

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

We are about to discover the joys of upstream BGP routing :-P  The
current plan is to use a pair of OpenBSD+bgpd hosts as the routers.

Each host will require 4x10gig ports (SFP+).  One of those links
(to AWS) will be close to saturated, along with the downlink to our
switches.  The other two will only need to carry ~1Gb/s of traffic.

We are pretty much a Supermicro shop, and I'm wondering if anyone
out there is running a similar setup on SM hardware.  My main concern
is finding NICs that will let us squeeze every last drop of bandwidth
on the 10gig links.

I did run some brief ttcp tests on a pair of SM 1Us (don't have the
model number handy, maybe 5018-FTN4s?) with add-in Intel cards
(550s?) and was able to get 700 MBytes/s of throughput.  This would
have been circa the 6.7 or 6.8 releases.

I'm hoping to get >70% of the theoretical bandwidth out of the new
hardware, and my gut says it's the NIC that's constraining us.

So, I'd be interested in hearing from anyone running a similar
setup, or who has benchmarked any of the current crop of 10gig NICs
and has good/bad things to say about specific models.

Thanks,

--lyndon

Re: Which hardware for a firewall?

[Stuart Henderson]

On 2023-06-20, Nick Holland  wrote:
> On 6/20/23 13:13, Karel Lucas wrote:
>> 
>> Hi all,
>> 
>> I'm going to create a firewall with openBSD, and would like to use the
>> ARM64 or ARMv7 distribution for that. Unfortunately I don't know what
>> hardware I can get for this, and that's the reason for this mail. Can
>> someone point me to a suitable platform for this? If this email does not
>> belong on this mailing list, I offer my apology. This is my first post
>> on this mailing list, and ask for understanding. Sincerely, Karel.

R5S is probably most likely to fit the bill.

armv7 is probably too slow to be of all that much interest.

Be aware that OpenBSD is a bit less polished on arm platforms.
Most are at least a bit more awkward than most amd64.

> Fortunately, since there's only one speed connection, a set number of
> devices doing a fixed number of things in each location, we will have no
> problem advising you on the best choice for your application...
>
> oh, wait... :)
>
> Well, here's the HW compatibility for those platforms:
> https://www.openbsd.org/arm64.html
> https://www.openbsd.org/armv7.html

There's only partial detail of what works on the various boards, and
some need fiddling with boot loaders/device trees.

Re: Which hardware for a firewall?

[Nick Holland]

On 6/20/23 13:13, Karel Lucas wrote:


Hi all,

I'm going to create a firewall with openBSD, and would like to use the
ARM64 or ARMv7 distribution for that. Unfortunately I don't know what
hardware I can get for this, and that's the reason for this mail. Can
someone point me to a suitable platform for this? If this email does not
belong on this mailing list, I offer my apology. This is my first post
on this mailing list, and ask for understanding. Sincerely, Karel.



Fortunately, since there's only one speed connection, a set number of
devices doing a fixed number of things in each location, we will have no
problem advising you on the best choice for your application...

oh, wait... :)

Well, here's the HW compatibility for those platforms:
https://www.openbsd.org/arm64.html
https://www.openbsd.org/armv7.html

You will have to decide what fits your needs.

Honestly, though, I'd suggest just recycling an old PC and a surplus
network card (or multi-port card, depending on how people toss stuff
out around you).  If you want "the best choice", this is probably it.

Nick.

Which hardware for a firewall?

[Karel Lucas]

Hi all,

I'm going to create a firewall with openBSD, and would like to use the 
ARM64 or ARMv7 distribution for that. Unfortunately I don't know what 
hardware I can get for this, and that's the reason for this mail. Can 
someone point me to a suitable platform for this? If this email does not 
belong on this mailing list, I offer my apology. This is my first post 
on this mailing list, and ask for understanding. Sincerely, Karel.

Re: hardware

[Andrew Klaus]

That's been my motto as well.

Except I recently picked up an R86s with older Mellanox ConnectX-3 10GbE 
SFPs, only to discover that OpenBSD only supports the newer ConnectX-4 
and 5s :(


I'd love to contribute in writing a driver in some way, but don't even 
know where to begin.


On 4/28/23 13:55, Mihai Popescu wrote:

Gustavo Rios  wrote:


What is the best supported servers by OpenBSD ?

The older, the better!
Take the oldest machine that will suit your needs.
If it old enough, then someone:
o released some (in)complete documentation
o was pissed enough to start writing drivers and code for it
o noticed bugs and reported them
o ...
already!

Good luck!

Re: hardware

[Mihai Popescu]

Gustavo Rios  wrote:

> What is the best supported servers by OpenBSD ?

The older, the better!
Take the oldest machine that will suit your needs.
If it old enough, then someone:
o released some (in)complete documentation
o was pissed enough to start writing drivers and code for it
o noticed bugs and reported them
o ...
already!

Good luck!

Re: hardware

[Katherine Mcmillan]

"I agree in this case with ChatGPT... why bother? Plants are fine as they
are - not touched by human hands (at least in the wild)"

Agreed.  Unless you want an Audrey 2. :)

From: owner-m...@openbsd.org  on behalf of Kaya Saman 

Sent: 20 April 2023 12:20
To: misc@openbsd.org 
Subject: Re: hardware

Attention : courriel externe | external email

On 4/20/23 17:12, Katherine Mcmillan wrote:
> According to ChatGPT, unfortunately, it doesn't work on plants.
>
> Me to ChatGPT: Can I run OpenBSD on my ficus?
>
> ChatGPT: No, it is not possible to run OpenBSD on a ficus plant. OpenBSD is 
> an operating system designed to run on computer hardware, not on plants. 
> Plants do not have the necessary hardware components or architecture to 
> support an operating system. Additionally, attempting to install an operating 
> system on a plant would be considered nonsensical and impossible. It is 
> important to respect the natural world and not attempt to impose technology 
> on living organisms that are not designed to use it.
>
> Bummer, I guess that wasn't the secret behind Audrey 2.  Back to the drawing 
> board.


Plants have their own OS... it's bio chemical! Just like us though add
bio electrical to the mix.


To run OpenBSD on a plant you would need one hell of a recompiler to
convert digital impulses into chemical ones.


I agree in this case with ChatGPT... why bother? Plants are fine as they
are - not touched by human hands (at least in the wild)

Re: hardware

[Kaya Saman]

On 4/20/23 17:12, Katherine Mcmillan wrote:

According to ChatGPT, unfortunately, it doesn't work on plants.

Me to ChatGPT: Can I run OpenBSD on my ficus?

ChatGPT: No, it is not possible to run OpenBSD on a ficus plant. OpenBSD is an 
operating system designed to run on computer hardware, not on plants. Plants do 
not have the necessary hardware components or architecture to support an 
operating system. Additionally, attempting to install an operating system on a 
plant would be considered nonsensical and impossible. It is important to 
respect the natural world and not attempt to impose technology on living 
organisms that are not designed to use it.

Bummer, I guess that wasn't the secret behind Audrey 2.  Back to the drawing 
board.



Plants have their own OS... it's bio chemical! Just like us though add 
bio electrical to the mix.



To run OpenBSD on a plant you would need one hell of a recompiler to 
convert digital impulses into chemical ones.



I agree in this case with ChatGPT... why bother? Plants are fine as they 
are - not touched by human hands (at least in the wild)

Re: hardware

[Katherine Mcmillan]

According to ChatGPT, unfortunately, it doesn't work on plants.

Me to ChatGPT: Can I run OpenBSD on my ficus?

ChatGPT: No, it is not possible to run OpenBSD on a ficus plant. OpenBSD is an 
operating system designed to run on computer hardware, not on plants. Plants do 
not have the necessary hardware components or architecture to support an 
operating system. Additionally, attempting to install an operating system on a 
plant would be considered nonsensical and impossible. It is important to 
respect the natural world and not attempt to impose technology on living 
organisms that are not designed to use it.

Bummer, I guess that wasn't the secret behind Audrey 2.  Back to the drawing 
board.



From: owner-m...@openbsd.org  on behalf of Frans 
Haarman 
Sent: 20 April 2023 11:13
To: OpenBSD general usage list 
Subject: Re: hardware

Attention : courriel externe | external email

Did you not know NetBSD runs on everything and OpenBSD runs on every fur!

Op wo 19 apr. 2023 10:53 schreef Stanislav Syekirin <
stanislav.syeki...@studium.fernuni-hagen.de>:

>
>
>
> On Mi, 19 Apr 2023 12:51:02 +1000
>   David Diggles  wrote:
> > On 2023-04-19 01:40, folly bololey wrote:
> >>> It doesn't matter whether the cat is black or white, as long as it
> >>> catches mice.
> >> Black cat is more stealthy
> >
> > just a different hunting strategy and depends on the lighting. white
> >cats would be stealthier in snow, or ambushing from above in the day
> >time.
> >
>
> To be honest I didn't know it was possible to install OpenBSD on a
> cat.
>
>

Re: hardware

[Frans Haarman]

Did you not know NetBSD runs on everything and OpenBSD runs on every fur!

Op wo 19 apr. 2023 10:53 schreef Stanislav Syekirin <
stanislav.syeki...@studium.fernuni-hagen.de>:

>
>
>
> On Mi, 19 Apr 2023 12:51:02 +1000
>   David Diggles  wrote:
> > On 2023-04-19 01:40, folly bololey wrote:
> >>> It doesn't matter whether the cat is black or white, as long as it
> >>> catches mice.
> >> Black cat is more stealthy
> >
> > just a different hunting strategy and depends on the lighting. white
> >cats would be stealthier in snow, or ambushing from above in the day
> >time.
> >
>
> To be honest I didn't know it was possible to install OpenBSD on a
> cat.
>
>

Re: hardware

[deich...@placebonol.com]

and lest we forget, all the gray/grey ones 

On April 19, 2023 2:19:48 AM MDT, Jan Stary  wrote:
>Once we leveraged the synergy of the red and purple solution frameworks.
>
>On Apr 18 07:47:56, deich...@placebonol.com wrote:
>> I was always partial to the blue or purple ones.
>> 
>> On April 18, 2023 3:42:58 AM MDT, Joel Carnat  wrote:
>> >
>> >> Le 18 avr. 2023 à 11:30, Stuart Henderson  a 
>> >> écrit :
>> >> 
>> >> On 2023-04-18, Mischa  wrote:
>>  On 2023-04-17 23:37, Mike Larkin wrote:
>>  On Mon, Apr 17, 2023 at 02:21:14PM -0600, Theo de Raadt wrote:
>> > Gustavo Rios  wrote:
>> > 
>> >> What is the best supported servers by OpenBSD ?
>> > 
>> > The silver ones work a little bit better than the black ones.
>> > 
>>  
>>  disagree. All my long running servers are the black ones.
>> >>> 
>> >>> I concur. The black ones are the best!
>> >>> They also need to have blue blinkenlights.
>> >> 
>> >> No love for the blue ones?
>> >
>> >If SunFire v100 count as blue, I do.
>> >
>> >
>> 
>

Re: hardware

[Jan Stary]

Once we leveraged the synergy of the red and purple solution frameworks.

On Apr 18 07:47:56, deich...@placebonol.com wrote:
> I was always partial to the blue or purple ones.
> 
> On April 18, 2023 3:42:58 AM MDT, Joel Carnat  wrote:
> >
> >> Le 18 avr. 2023 à 11:30, Stuart Henderson  a 
> >> écrit :
> >> 
> >> On 2023-04-18, Mischa  wrote:
>  On 2023-04-17 23:37, Mike Larkin wrote:
>  On Mon, Apr 17, 2023 at 02:21:14PM -0600, Theo de Raadt wrote:
> > Gustavo Rios  wrote:
> > 
> >> What is the best supported servers by OpenBSD ?
> > 
> > The silver ones work a little bit better than the black ones.
> > 
>  
>  disagree. All my long running servers are the black ones.
> >>> 
> >>> I concur. The black ones are the best!
> >>> They also need to have blue blinkenlights.
> >> 
> >> No love for the blue ones?
> >
> >If SunFire v100 count as blue, I do.
> >
> >
> 

Re: hardware

[Stanislav Syekirin]

On Mi, 19 Apr 2023 12:51:02 +1000
 David Diggles  wrote:

On 2023-04-19 01:40, folly bololey wrote:

It doesn't matter whether the cat is black or white, as long as it
catches mice.

Black cat is more stealthy


just a different hunting strategy and depends on the lighting. white 
cats would be stealthier in snow, or ambushing from above in the day 
time.




To be honest I didn't know it was possible to install OpenBSD on a 
cat.

Re: hardware

[David Diggles]

On 2023-04-19 01:40, folly bololey wrote:

It doesn't matter whether the cat is black or white, as long as it
catches mice.

Black cat is more stealthy


just a different hunting strategy and depends on the lighting. white 
cats would be stealthier in snow, or ambushing from above in the day 
time.

Re: hardware

[folly bololey]

> It doesn't matter whether the cat is black or white, as long as it
> catches mice.
Black cat is more stealthy

Re: hardware

[deich...@placebonol.com]

I was always partial to the blue or purple ones.

On April 18, 2023 3:42:58 AM MDT, Joel Carnat  wrote:
>
>> Le 18 avr. 2023 à 11:30, Stuart Henderson  a 
>> écrit :
>> 
>> On 2023-04-18, Mischa  wrote:
 On 2023-04-17 23:37, Mike Larkin wrote:
 On Mon, Apr 17, 2023 at 02:21:14PM -0600, Theo de Raadt wrote:
> Gustavo Rios  wrote:
> 
>> What is the best supported servers by OpenBSD ?
> 
> The silver ones work a little bit better than the black ones.
> 
 
 disagree. All my long running servers are the black ones.
>>> 
>>> I concur. The black ones are the best!
>>> They also need to have blue blinkenlights.
>> 
>> No love for the blue ones?
>
>If SunFire v100 count as blue, I do.
>
>

Re: hardware

[lux]

On Mon, 2023-04-17 at 21:37 +, Mike Larkin wrote:
> On Mon, Apr 17, 2023 at 02:21:14PM -0600, Theo de Raadt wrote:
> > Gustavo Rios  wrote:
> > 
> > > What is the best supported servers by OpenBSD ?
> > 
> > The silver ones work a little bit better than the black ones.
> > 
> 
> disagree. All my long running servers are the black ones.
> 
> 

It doesn't matter whether the cat is black or white, as long as it
catches mice.

Re: hardware

[Joel Carnat]

> Le 18 avr. 2023 à 11:30, Stuart Henderson  a écrit 
> :
> 
> On 2023-04-18, Mischa  wrote:
>>> On 2023-04-17 23:37, Mike Larkin wrote:
>>> On Mon, Apr 17, 2023 at 02:21:14PM -0600, Theo de Raadt wrote:
 Gustavo Rios  wrote:
 
> What is the best supported servers by OpenBSD ?
 
 The silver ones work a little bit better than the black ones.
 
>>> 
>>> disagree. All my long running servers are the black ones.
>> 
>> I concur. The black ones are the best!
>> They also need to have blue blinkenlights.
> 
> No love for the blue ones?

If SunFire v100 count as blue, I do.

Re: hardware

[Christoph Roland Winter]

Sure, the cobalt and electric blue ones are great. But also the dark red, green 
and dark blue ones. The silver / white ones are great to, specially if you need 
them in a modern or home office.

> Am 18.04.2023 um 11:30 schrieb Stuart Henderson :
> 
> On 2023-04-18, Mischa  wrote:
>>> On 2023-04-17 23:37, Mike Larkin wrote:
>>> On Mon, Apr 17, 2023 at 02:21:14PM -0600, Theo de Raadt wrote:
 Gustavo Rios  wrote:
 
> What is the best supported servers by OpenBSD ?
 
 The silver ones work a little bit better than the black ones.
 
>>> 
>>> disagree. All my long running servers are the black ones.
>> 
>> I concur. The black ones are the best!
>> They also need to have blue blinkenlights.
> 
> No love for the blue ones?
> 
> 

Re: hardware

[Stuart Henderson]

On 2023-04-18, Mischa  wrote:
> On 2023-04-17 23:37, Mike Larkin wrote:
>> On Mon, Apr 17, 2023 at 02:21:14PM -0600, Theo de Raadt wrote:
>>> Gustavo Rios  wrote:
>>> 
>>> > What is the best supported servers by OpenBSD ?
>>> 
>>> The silver ones work a little bit better than the black ones.
>>> 
>> 
>> disagree. All my long running servers are the black ones.
>
> I concur. The black ones are the best!
> They also need to have blue blinkenlights.

No love for the blue ones?

Re: hardware

[Mischa]

On 2023-04-17 23:37, Mike Larkin wrote:

On Mon, Apr 17, 2023 at 02:21:14PM -0600, Theo de Raadt wrote:

Gustavo Rios  wrote:

> What is the best supported servers by OpenBSD ?

The silver ones work a little bit better than the black ones.



disagree. All my long running servers are the black ones.


I concur. The black ones are the best!
They also need to have blue blinkenlights.

Mischa

Re: hardware

[Mike Larkin]

On Mon, Apr 17, 2023 at 02:21:14PM -0600, Theo de Raadt wrote:
> Gustavo Rios  wrote:
>
> > What is the best supported servers by OpenBSD ?
>
> The silver ones work a little bit better than the black ones.
>

disagree. All my long running servers are the black ones.

Re: hardware

[David]

On Mon, 2023-04-17 at 14:21 -0600, Theo de Raadt wrote:
> Gustavo Rios  wrote:
> 
> > What is the best supported servers by OpenBSD ?
> 
> The silver ones work a little bit better than the black ones.

If you can get one of the more rare red ones, they're faster!


-- 
A Kiwi in Australia,
doing my bit toward raising the national standard.

Re: hardware

[Theo de Raadt]

Gustavo Rios  wrote:

> What is the best supported servers by OpenBSD ?

The silver ones work a little bit better than the black ones.

hardware

[Gustavo Rios]

What is the best supported servers by OpenBSD ?

Dell, HPE, IBM or Oracle's ones ?

Thanks.

-- 
The lion and the tiger may be more powerful, but the wolves do not perform
in the circus

Re: fido2 hardware key with PIN in browsers

[rsykora]

Greg Steuck  wrote:
> rsyk...@disroot.org writes:
> 
> > Fabio Martins  wrote:
> >> About your question, I believe you need to do a tail -f /var/log/messages
> >
> > this is what I see after pluging the key in the computer:
> >
> > Apr  7 19:02:06 odin /bsd: uhidev1 at uhub0 port 1 configuration 1 
> > interface 1 "GoTrust Idem Key" rev 2.00/1.11 addr 2
> > Apr  7 19:02:06 odin /bsd: uhidev1: iclass 3/0
> > Apr  7 19:02:06 odin /bsd: fido0 at uhidev1: input=64, output=64, feature=0
> > Apr  7 19:02:06 odin /bsd: uhidev2 at uhub0 port 1 configuration 1 
> > interface 2 "GoTrust Idem Key" rev 2.00/1.11 addr 2
> > Apr  7 19:02:06 odin /bsd: uhidev2: iclass 3/1
> > Apr  7 19:02:06 odin /bsd: ukbd0 at uhidev2: 8 variable keys, 6 key codes
> > Apr  7 19:02:06 odin /bsd: wskbd1 at ukbd0 mux 1
> > Apr  7 19:02:06 odin /bsd: wskbd1: connecting to wsdisplay0
> > Apr  7 19:02:06 odin /bsd: ugen0 at uhub0 port 1 configuration 1 "GoTrust 
> > Idem Key" rev 2.00/1.11 addr 2
> 
> This is a good start of debugging effort. We can tell that the kernel is
> happy enough with your device. Now you can go one step further and see
> if ssh can use it.
> 
> If you are feeling ambitious about debugging this for chrome, try
> running it with --enable-logging --v=1 and then look into
> ~/.config/chromium/chrome_debug.log for anything matching "fido".
> 
> You can then do the same on Linux and compare the outputs.
> 
> How much do you care about having this extra pin protection? I have been
> using a few older FIDO devices for years now, so we know this much
> works.

After upgrading to OpenBSD to 7.3 today, the operation
started to work in chrome, so the key seems to be useable
for me now. (I only encountered a minor difficulty to
actually start chrome. It did not start the first time due
to some trap, nor the second time, but then it finally
started.  This behaviour is daunting, but, in the end, the
process succeeded.)

I do not know why the use of the key did not work before the
upgrade, but anyhow.

Regarding the question about the PIN: To the extent I
understand the PIN is a requirement by the security level to
be used. I use the key to communicate with the state (public
administration). There the condition is given that the PIN
is to be used.


Best regards,
Ruda

Re: fido2 hardware key with PIN in browsers

[Greg Steuck]

rsyk...@disroot.org writes:

> Fabio Martins  wrote:
>> About your question, I believe you need to do a tail -f /var/log/messages
>
> this is what I see after pluging the key in the computer:
>
> Apr  7 19:02:06 odin /bsd: uhidev1 at uhub0 port 1 configuration 1 interface 
> 1 "GoTrust Idem Key" rev 2.00/1.11 addr 2
> Apr  7 19:02:06 odin /bsd: uhidev1: iclass 3/0
> Apr  7 19:02:06 odin /bsd: fido0 at uhidev1: input=64, output=64, feature=0
> Apr  7 19:02:06 odin /bsd: uhidev2 at uhub0 port 1 configuration 1 interface 
> 2 "GoTrust Idem Key" rev 2.00/1.11 addr 2
> Apr  7 19:02:06 odin /bsd: uhidev2: iclass 3/1
> Apr  7 19:02:06 odin /bsd: ukbd0 at uhidev2: 8 variable keys, 6 key codes
> Apr  7 19:02:06 odin /bsd: wskbd1 at ukbd0 mux 1
> Apr  7 19:02:06 odin /bsd: wskbd1: connecting to wsdisplay0
> Apr  7 19:02:06 odin /bsd: ugen0 at uhub0 port 1 configuration 1 "GoTrust 
> Idem Key" rev 2.00/1.11 addr 2

This is a good start of debugging effort. We can tell that the kernel is
happy enough with your device. Now you can go one step further and see
if ssh can use it.

If you are feeling ambitious about debugging this for chrome, try
running it with --enable-logging --v=1 and then look into
~/.config/chromium/chrome_debug.log for anything matching "fido".

You can then do the same on Linux and compare the outputs.

How much do you care about having this extra pin protection? I have been
using a few older FIDO devices for years now, so we know this much
works.

Thanks
Greg

Re: fido2 hardware key with PIN in browsers

[rsykora]

Fabio Martins  wrote:
> About your question, I believe you need to do a tail -f /var/log/messages

this is what I see after pluging the key in the computer:

Apr  7 19:02:06 odin /bsd: uhidev1 at uhub0 port 1 configuration 1 interface 1 
"GoTrust Idem Key" rev 2.00/1.11 addr 2
Apr  7 19:02:06 odin /bsd: uhidev1: iclass 3/0
Apr  7 19:02:06 odin /bsd: fido0 at uhidev1: input=64, output=64, feature=0
Apr  7 19:02:06 odin /bsd: uhidev2 at uhub0 port 1 configuration 1 interface 2 
"GoTrust Idem Key" rev 2.00/1.11 addr 2
Apr  7 19:02:06 odin /bsd: uhidev2: iclass 3/1
Apr  7 19:02:06 odin /bsd: ukbd0 at uhidev2: 8 variable keys, 6 key codes
Apr  7 19:02:06 odin /bsd: wskbd1 at ukbd0 mux 1
Apr  7 19:02:06 odin /bsd: wskbd1: connecting to wsdisplay0
Apr  7 19:02:06 odin /bsd: ugen0 at uhub0 port 1 configuration 1 "GoTrust Idem 
Key" rev 2.00/1.11 addr 2

Re: fido2 hardware key with PIN in browsers

[Fabio Martins]

Interesting, I am also looking for such a device for quite some time. Ppl
using functional ones under obsd pla let me lnow

About your question, I believe you need to do a tail -f /var/log/messages
before plugging the device, and sending a dmesg also so ppl @misc can help
you out

On Friday, April 7, 2023,  wrote:

> Dear list,
>
>
> I have a USB hardware security key
> GoTrust Idem Key
> and while I can use it on linux in a chromium browser
> to login to some services -- you have to input a PIN
> number and then touch the key -- it seems to not work
> on OpenBSD (neither chrome nor firefox).
>
> Is this process supported on OpenBSD or there is
> no such functionality available now?
>
> Thank you for any comments.
>
>
> Best regards,
> Ruda
>
>
>

-- 
Atenciosamente,

Fabio Martins

(+5521) 97914-8106 (Signal)
https://www.linkedin.com/in/fabio1337br/

fido2 hardware key with PIN in browsers

[rsykora]

Dear list,


I have a USB hardware security key
GoTrust Idem Key
and while I can use it on linux in a chromium browser
to login to some services -- you have to input a PIN
number and then touch the key -- it seems to not work
on OpenBSD (neither chrome nor firefox).

Is this process supported on OpenBSD or there is
no such functionality available now?

Thank you for any comments.


Best regards,
Ruda
 

Re: Hardware RAID on Poweredge Servers

[deich...@placebonol.com]

On March 30, 2023 10:36:01 PM MDT, Kenneth Gober  wrote:
>On Thu, Mar 30, 2023 at 12:37 PM Kihaguru Gathura 
>wrote:
>
SNIP 
>
>In general I prefer hardware RAID because it's more likely you'll be able
>to easily boot your
>system if the array is running in a degraded state due to a drive failure
>(perhaps you might
>need to press F1 or something to continue).  With softraid, you might need
>to type special
>commands at the console to force booting or mounting a volume with a failed
>drive in it.
>This may be a problem if you are in a rush to bring the system back up and
>don't have a
>convenient way to look up the necessary commands.
>
>-ken

Hardware RAID is fine, but you need to make sure the system is configured to 
send notification when a RAID drive goes to a degraded state.  I can't tell you 
how many times I've been asked to assist with a system to find more than one 
drive failed.  What would seem to be common sense is often not done.

73
diana
KI5PGJ 

Re: Hardware RAID on Poweredge Servers

[Kihaguru Gathura]

Thanks for the info.

Regards,

Kihaguru.

On Fri, Mar 31, 2023 at 7:36 AM Kenneth Gober  wrote:

> On Thu, Mar 30, 2023 at 12:37 PM Kihaguru Gathura <
> kihagurugath...@gmail.com> wrote:
>
>> Is hardware RAID on Poweredge servers (T340, PERC H330 in particular)
>> generally stable enough for production or is it safer to stick with
>> OpenBSD
>> softraid?
>>
>
> I haven't used the H330, but the PERC 5/i and the PERC H700 have worked
> fine for
> me.  In terms of 'safety' I advise having a spare controller on hand
> because if your
> controller fails recovery will be simplest if you have the same controller
> (with the same
> firmware version) on hand.
>
> Note that mounting a RAID volume on a newer controller (or the same
> controller with
> newer firmware) may prevent that volume from being attached to an older
> controller later.
> So don't try doing fancy things like moving the drives to a newer system
> to take a backup,
> then trying to move them back to their original system later unless you
> have the same
> controller in both systems.
>
> In general I prefer hardware RAID because it's more likely you'll be able
> to easily boot your
> system if the array is running in a degraded state due to a drive failure
> (perhaps you might
> need to press F1 or something to continue).  With softraid, you might need
> to type special
> commands at the console to force booting or mounting a volume with a
> failed drive in it.
> This may be a problem if you are in a rush to bring the system back up and
> don't have a
> convenient way to look up the necessary commands.
>
> -ken
>

Re: Hardware RAID on Poweredge Servers

[Kenneth Gober]

On Thu, Mar 30, 2023 at 12:37 PM Kihaguru Gathura 
wrote:

> Is hardware RAID on Poweredge servers (T340, PERC H330 in particular)
> generally stable enough for production or is it safer to stick with OpenBSD
> softraid?
>

I haven't used the H330, but the PERC 5/i and the PERC H700 have worked
fine for
me.  In terms of 'safety' I advise having a spare controller on hand
because if your
controller fails recovery will be simplest if you have the same controller
(with the same
firmware version) on hand.

Note that mounting a RAID volume on a newer controller (or the same
controller with
newer firmware) may prevent that volume from being attached to an older
controller later.
So don't try doing fancy things like moving the drives to a newer system to
take a backup,
then trying to move them back to their original system later unless you
have the same
controller in both systems.

In general I prefer hardware RAID because it's more likely you'll be able
to easily boot your
system if the array is running in a degraded state due to a drive failure
(perhaps you might
need to press F1 or something to continue).  With softraid, you might need
to type special
commands at the console to force booting or mounting a volume with a failed
drive in it.
This may be a problem if you are in a rush to bring the system back up and
don't have a
convenient way to look up the necessary commands.

-ken

Re: Hardware RAID on Poweredge Servers

[Hrvoje Popovski]

On 30.3.2023. 18:33, Kihaguru Gathura wrote:
> Hello,
> 
> Is hardware RAID on Poweredge servers (T340, PERC H330 in particular)
> generally stable enough for production or is it safer to stick with OpenBSD
> softraid?
> 

Hi,

not sure if there is big differences between H330 and H330 mini but H330
mini is quite stable ..



bios0: Dell Inc. PowerEdge R630

mfii0 at pci1 dev 0 function 0 "Symbios Logic MegaRAID SAS3008" rev
0x02: msi
mfii0: "PERC H330 Mini", firmware 25.5.5.0005


uptime
 6:39PM  up 1205 days,  2:14, 1 user, load averages: 0.38, 0.40, 0.40


bioctl sd0
Volume  Status   Size Device
mfii0 0 Online   299439751168 sd0 RAID1 WT
  0 Online   3000 1:0.0   noencl 
  1 Online   3000 1:1.0   noencl 

Hardware RAID on Poweredge Servers

[Kihaguru Gathura]

Hello,

Is hardware RAID on Poweredge servers (T340, PERC H330 in particular)
generally stable enough for production or is it safer to stick with OpenBSD
softraid?


Regards,

Kihaguru.

Re: HP PA-RISC / IA64 hardware platform for Linux Debian, Gentoo, NetBSD, OpenBSD and HP-UX Unix

[Jesse Dougherty]

Hi Tom, thanks...  Yes it does overlap it seems with the J6700.. I have 
a few of them and other PA-RISC boxes also. I guess I'll just see who 
might be interested.


Thanks again


On 10/7/22 8:56 AM, Tom Smyth wrote:

Hi Jesse,

you can check out https://www.openbsd.org/want.html perhaps there is 
an overlap between developers requirements and what you have surplus,
it is a voluntary project so consider donating  some hardware to the 
developers  according to that list,


Hope this helps,

Tom Smyth

On Fri, 7 Oct 2022 at 13:16, Jesse Dougherty <mailto:je...@cypress-tech.com>> wrote:


Hi, I'm Jesse at Cypress Technology Inc. We at Cypress sell HP
    hardware.
Below are some links to HP PA-RISC and IA64 boxes that support the
Linux
Debian, Gentoo, NetBSD, OpenBSD Linux and HP-UX Unix platforms. If
you
are in need of systems, feel free to email back with any question or
requests. We also sell all boxes and parts that HP made for the
HP-UX /
Unix line.

PA-RISC
www.ebay.com/itm/385130495455 <http://www.ebay.com/itm/385130495455>
www.ebay.com/itm/384211227917 <http://www.ebay.com/itm/384211227917>

IA64
www.ebay.com/itm/384272059488 <http://www.ebay.com/itm/384272059488>
www.ebay.com/itm/384211228177 <http://www.ebay.com/itm/384211228177>

IA64 - For Telco / Data Center users / 48v DC
www.ebay.com/itm/384966825704 <http://www.ebay.com/itm/384966825704>

Thanks
    Jesse Dougherty
Resellers of HP hardware
je...@cypress-tech.com <mailto:je...@cypress-tech.com>
www.cypress-tech.com <http://www.cypress-tech.com>



--
Kindest regards,
Tom Smyth.

Re: HP PA-RISC / IA64 hardware platform for Linux Debian, Gentoo, NetBSD, OpenBSD and HP-UX Unix

[Tom Smyth]

Hi Jesse,

you can check out https://www.openbsd.org/want.html  perhaps there is an
overlap between developers requirements and what you have surplus,
it is a voluntary project so consider donating  some hardware to the
developers  according to that list,

Hope this helps,

Tom Smyth

On Fri, 7 Oct 2022 at 13:16, Jesse Dougherty  wrote:

> Hi, I'm Jesse at Cypress Technology Inc. We at Cypress sell HP hardware.
> Below are some links to HP PA-RISC and IA64 boxes that support the Linux
> Debian, Gentoo, NetBSD, OpenBSD Linux and HP-UX Unix platforms. If you
> are in need of systems, feel free to email back with any question or
> requests. We also sell all boxes and parts that HP made for the HP-UX /
> Unix line.
>
> PA-RISC
> www.ebay.com/itm/385130495455
> www.ebay.com/itm/384211227917
>
> IA64
> www.ebay.com/itm/384272059488
> www.ebay.com/itm/384211228177
>
> IA64 - For Telco / Data Center users / 48v DC
> www.ebay.com/itm/384966825704
>
> Thanks
> Jesse Dougherty
> Resellers of HP hardware
> je...@cypress-tech.com
> www.cypress-tech.com
>
>

-- 
Kindest regards,
Tom Smyth.

HP PA-RISC / IA64 hardware platform for Linux Debian, Gentoo, NetBSD, OpenBSD and HP-UX Unix

[Jesse Dougherty]

Hi, I'm Jesse at Cypress Technology Inc. We at Cypress sell HP hardware. 
Below are some links to HP PA-RISC and IA64 boxes that support the Linux 
Debian, Gentoo, NetBSD, OpenBSD Linux and HP-UX Unix platforms. If you 
are in need of systems, feel free to email back with any question or 
requests. We also sell all boxes and parts that HP made for the HP-UX / 
Unix line.


PA-RISC
www.ebay.com/itm/385130495455
www.ebay.com/itm/384211227917

IA64
www.ebay.com/itm/384272059488
www.ebay.com/itm/384211228177

IA64 - For Telco / Data Center users / 48v DC
www.ebay.com/itm/384966825704

Thanks
Jesse Dougherty
Resellers of HP hardware
je...@cypress-tech.com
www.cypress-tech.com

Re: OpenBSD hardware accelerated video? (In X on Intel/AMDGPU/ARM64)

[Sandeep Gupta]

I would great to have hardware acceleration for Raspberry Pi. But Pi's
video hardware drivers are not open source. They are some propriety
binary bits. Even theoretically, I don't see if those binary bits can be
used within
OpenBSD system.


On Thu, Jul 21, 2022 at 2:20 AM Mihai Popescu  wrote:

> > With your email now however the original question remains: Does OpenBSD
> actually support hardware accelerated video decoding today?
>
> General answer: NO.
>
> A more detailed answer is like this: there is a talk on the list about
> libvaapi (if i recall correctly) implementation for intel only. It was
> suggested, I am not sure if landed into the ports.
> Hardware video decoding must be done thru some libs, I think they are
> vaapi and vdpau for the moment. Then the used software (vlc, mpv,
> chromium, firefox) must be compiled with support for one of these, or
> both maybe.
>
> Both ways are praised and hated on the internet, depending of what you
> read. As always, there is much marketing involved.
>
> Anyone is welcome to correct some possible mistakes, I am not a video
> hardware expert.
>
>

Re: OpenBSD hardware accelerated video? (In X on Intel/AMDGPU/ARM64)

[Mihai Popescu]

> With your email now however the original question remains: Does OpenBSD 
> actually support hardware accelerated video decoding today?

General answer: NO.

A more detailed answer is like this: there is a talk on the list about
libvaapi (if i recall correctly) implementation for intel only. It was
suggested, I am not sure if landed into the ports.
Hardware video decoding must be done thru some libs, I think they are
vaapi and vdpau for the moment. Then the used software (vlc, mpv,
chromium, firefox) must be compiled with support for one of these, or
both maybe.

Both ways are praised and hated on the internet, depending of what you
read. As always, there is much marketing involved.

Anyone is welcome to correct some possible mistakes, I am not a video
hardware expert.

Re: OpenBSD hardware accelerated video? (In X on Intel/AMDGPU/ARM64)

[Nick Holland]

On 7/20/22 10:24 AM, Joseph wrote:

Hi,

Is there any hardware accelerated video decoding in OpenBSD today?

E.g. in X on AMDGPU and Intel & ARM64 built-in graphics.

My best understanding is that the X graphics rendering is indeed
accelerated on those, but video decoding is not.

HW accelerated video decoding would be very useful as high-resolution
full-screen playback not really works now because there's too much
lag (or maybe I had unsupported hardware, if so glad to be corrected). It
would contribute to a sense of smoothness in X/web browsing.


well...I have some pretty old hw that I don't seem to have any issue
watching full screen 1920x1200 video from YouTube.  Or 1920x1080 on my
other monitor.  On both Firefox and Chrome.  Zero efforts to optimize
performance, just tweaking login.conf to respect the expectations of
modern browsers so they don't get slapped out of RAM for excess memory
consumption.

OpenBSD 7.1-current (GENERIC.MP) #506: Sun May  8 20:07:46 MDT 2022 <- needs 
updating :-/
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34340835328 (32749MB)
avail mem = 33282727936 (31740MB)
...
bios0: vendor Dell Inc. version "A16" date 05/28/2013
bios0: Dell Inc. Precision WorkStation T5500
...
cpu0: Intel(R) Xeon(R) CPU X5670 @ 2.93GHz, 3192.41 MHz, 06-2c-02
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
[six real cores, hyperthreading off.  Was once a fast processor,
but that was probably ten years ago].
...
radeondrm0 at pci3 dev 0 function 0 "ATI Radeon HD 5450" rev 0x00
drm0 at radeondrm0
...
radeondrm1 at pci4 dev 0 function 0 "ATI Radeon HD 3450" rev 0x00
drm1 at radeondrm1
...
[pretty sure both those video cards were always lame]

Now, I'm not very picky, but I don't see obvious lag.  Kinda sucks,
I was much more productive before youtube and other video sources
became fully functional in OpenBSD. :)

Nick.

another hardware "bleed"

[Mihai Popescu]

For the late comers to the party, see [1].

[1] https://www.hertzbleed.com/

Re: OpenBSD 7.1 - hangs after userland upgrade on server hardware

[Andrew Lemin]

ocal was not properly unmounted
WARNING: /var was not properly unmounted
WARNING: /usr/src was not properly unmounted



On Sun, May 1, 2022 at 7:42 PM Stuart Henderson 
wrote:

> On 2022-05-01, Andrew Lemin  wrote:
> > Hi all,
> >
> > I am totally stumped with issues while upgrading/installing 7.1 and I
> need
> > some help!
> >
> > Server; Supermicro X10SLV-Q (Intel Q87 Express), Xeon E3-1280 v3, 8G RAM,
> > Mellanox 10G NIC
> >
> > This server has been running OpenBSD flawlessly for years. I followed the
> > upgrade instructions and was able to reboot fine onto the 7.1 kernel (I
> > rebooted a couple of times on the 7.1 kernel in fact). However after I
> run
> > 'pkg_add -u' to upgrade all of userland to 7.1, the machine started
> hanging
> > during boot.
> >
> > The hang looked like an IO problem as it would always hang around the
> disk
> > setup stages.
> > I went into the BIOS and tried optimised defaults and failsafe defaults
> but
> > no luck..
> >
> > I also downloaded a fresh copy and tried installing 7.1 from flash,
> however
> > the 7.1 installer also hangs. It hangs in the same place every time after
> > selecting 'done' to the networking config.
> > As I have a Mellanox card in here, I removed the NIC. but the hang
> > continues so its not that..
> >
> > I get nothing to debug, it just freezes. I have reinstalled 7.0 which is
> > still working perfectly so this is not a hardware fault.
> >
> > Is there anything I can do to increase the verbosity to see what driver
> it
> > is trying to load before the hang?
> >
> > Other information, this is a totally headless machine, with a Xeon CPU
> > without any onboard GPU. It has a console connection with
> > console-redirection in the bios, and I have to set the tty params during
> > boot to interact over console. Otherwise everything else is standard.
>
> If you can copy the console output (from boot loader to hang) from serial
> console into an email, that might give some clues.
>
> dmesg from 7.0 might be useful too.
>
> It's a bit unclear how you upgraded (pkg_add -u is for packages rather than
> userland parts of the OS) - normally you would upgrade kernel and userland
> such that you'd boot onto new kernel+userland at the same time, then update
> packages.
>
>
>

Re: OpenBSD 7.1 - hangs after userland upgrade on server hardware

[Stuart Henderson]

On 2022-05-01, Andrew Lemin  wrote:
> Hi all,
>
> I am totally stumped with issues while upgrading/installing 7.1 and I need
> some help!
>
> Server; Supermicro X10SLV-Q (Intel Q87 Express), Xeon E3-1280 v3, 8G RAM,
> Mellanox 10G NIC
>
> This server has been running OpenBSD flawlessly for years. I followed the
> upgrade instructions and was able to reboot fine onto the 7.1 kernel (I
> rebooted a couple of times on the 7.1 kernel in fact). However after I run
> 'pkg_add -u' to upgrade all of userland to 7.1, the machine started hanging
> during boot.
>
> The hang looked like an IO problem as it would always hang around the disk
> setup stages.
> I went into the BIOS and tried optimised defaults and failsafe defaults but
> no luck..
>
> I also downloaded a fresh copy and tried installing 7.1 from flash, however
> the 7.1 installer also hangs. It hangs in the same place every time after
> selecting 'done' to the networking config.
> As I have a Mellanox card in here, I removed the NIC. but the hang
> continues so its not that..
>
> I get nothing to debug, it just freezes. I have reinstalled 7.0 which is
> still working perfectly so this is not a hardware fault.
>
> Is there anything I can do to increase the verbosity to see what driver it
> is trying to load before the hang?
>
> Other information, this is a totally headless machine, with a Xeon CPU
> without any onboard GPU. It has a console connection with
> console-redirection in the bios, and I have to set the tty params during
> boot to interact over console. Otherwise everything else is standard.

If you can copy the console output (from boot loader to hang) from serial
console into an email, that might give some clues.

dmesg from 7.0 might be useful too.

It's a bit unclear how you upgraded (pkg_add -u is for packages rather than
userland parts of the OS) - normally you would upgrade kernel and userland
such that you'd boot onto new kernel+userland at the same time, then update
packages.

OpenBSD 7.1 - hangs after userland upgrade on server hardware

[Andrew Lemin]

Hi all,

I am totally stumped with issues while upgrading/installing 7.1 and I need
some help!

Server; Supermicro X10SLV-Q (Intel Q87 Express), Xeon E3-1280 v3, 8G RAM,
Mellanox 10G NIC

This server has been running OpenBSD flawlessly for years. I followed the
upgrade instructions and was able to reboot fine onto the 7.1 kernel (I
rebooted a couple of times on the 7.1 kernel in fact). However after I run
'pkg_add -u' to upgrade all of userland to 7.1, the machine started hanging
during boot.

The hang looked like an IO problem as it would always hang around the disk
setup stages.
I went into the BIOS and tried optimised defaults and failsafe defaults but
no luck..

I also downloaded a fresh copy and tried installing 7.1 from flash, however
the 7.1 installer also hangs. It hangs in the same place every time after
selecting 'done' to the networking config.
As I have a Mellanox card in here, I removed the NIC. but the hang
continues so its not that..

I get nothing to debug, it just freezes. I have reinstalled 7.0 which is
still working perfectly so this is not a hardware fault.

Is there anything I can do to increase the verbosity to see what driver it
is trying to load before the hang?

Other information, this is a totally headless machine, with a Xeon CPU
without any onboard GPU. It has a console connection with
console-redirection in the bios, and I have to set the tty params during
boot to interact over console. Otherwise everything else is standard.

Thanks for your time,
Best regards Andy.

Re: Hardware for OpenBSD based access point

[Laurence Tratt]

On Mon, Mar 14, 2022 at 01:52:15AM +0100, Nicolas Goy wrote:

Hello Nicolas,

> I use OpenBSD for all my network gears except wireless access points.
>
> My current access points are getting old and I'd like to replace them.

I was also in the same place a year or so ago. After seeing many
recommendations I bought a Ubiquiti device, but I would not recommend it: it
is poorly documented, with two separate incomplete UIs, and buggy (including,
but not only, dropping connections), even before one considers things like
"phoning home" etc. Not one of my better purchases, and I'm surprised how
often they're recommended -- I was happy to be rid of it.

I then bought a cheap Celeron box as an OpenBSD router and a Ruckus access
point (an R510 in my case, though I suspect most of their models would suit
my purposes) with the "unleashed" firmware. The Ruckus is an absolute joy --
the UI is simple and well thought through, so I had it 95% configured to do
what I wanted in under 10 minutes, and the (clear! fairly complete!)
documentation helped me do the rest soon after. It has been rock solid for 6
months, without once dropping a connection. The only problem is price -- they
are prohibitively expensive new for a typical consumer, but on ebay you can
pick them up for a reasonable price.


Laurie
-- 
Personalhttps://tratt.net/laurie/
Software Development Team   https://soft-dev.org/
   https://github.com/ltratt https://twitter.com/laurencetratt

Re: Hardware for OpenBSD based access point

[Stuart Henderson]

On 2022-03-15, Stuart Longland  wrote:
> On Mon, 14 Mar 2022 20:16:14 +0100
> Nicolas Goy  wrote:
>
>> I heard that controller based AP "fleet" can mitigate that by
>> kicking devices that are on the "wrong" AP. But I am not sure how it
>> works in practice as I only read about it and it is not any standard.
>
> I tried this with my fleet of Ubiquiti APs, I found my Android tablet
> would always connect on the 5GHz network and refuse to even acknowledge
> the existance of its 2.4GHz counterpart, to the point that when I
> walked down the drive way, instead of switching to 2.4GHz, it'd simply
> declare the whole network "out of range".

There are some "band steering" settings in the AP config that could make
this worse (e.g. there's one which stops opaquely defined "high performance
devices" from connecting to 2GHz in some cases). 

(For bigger setups, and I'd certainly include the 8 suggested by the OP in
this, it's often helpful to disable 2GHz in most cases, just enable on
some APs where needed..)

> There is an option for booting clients off that have "too weak" a
> signal.  Basically if the received RSSI in dBm from the client is not
> above a certain minimum threshold, the AP boots them off.  Ideally the
> client should then find _another_ AP or network, but in my case I found
> the dumb client just tried again with the same AP and network, on the
> same frequency.

minrssi. To work properly that needs an AP design plan to ensure that
minimum signal in the covered areas is up to the value you set with
enough overlap between APs otherwise it ends up kicking people off their
only working AP. Then they try to reconnect, then booted off again, etc.
It can work, but it's easy to make things worse that way.

> So yes, your mileage will definitely vary.


-- 
Please keep replies on the mailing list.

Re: Hardware for OpenBSD based access point

[Nicolas Goy]

On Mon, Mar 14, 2022 at 02:31:13PM -, Stuart Henderson wrote:
> 
> Roaming decisions are client-side though there are some things an AP can
> do to influence them.

At present, with non communicating AP, the android clients are holding
to their AP for way too long. For example if I enable wifi in the
garden, it pairs with the garden AP to get a strong signal, but as I
move in the house to the basement, it holds to the garden AP with like
1% signal even if the basement AP is literraly next to it, and I have to
disable-enable wifi on the phone to force it to change, otherwise it
doesn't. I heard that controller based AP "fleet" can mitigate that by
kicking devices that are on the "wrong" AP. But I am not sure how it
works in practice as I only read about it and it is not any standard.

-- 
Nicolas Goy

https://www.kuon.ch
https://www.goyman.com

Re: Hardware for OpenBSD based access point

[Stuart Henderson]

On 2022-03-14, Nicolas Goy  wrote:
> On Mon, Mar 14, 2022 at 01:32:35PM -, Stuart Henderson wrote:
>> There's no chance of meeting all of these requirements with OpenBSD.
>> 
>> For AP-side 11ac there are some bwfm(4) devices which _might_ do but they
>> are not common. Really at this point the emphasis for wifi on OpenBSD
>> is for client-side not AP-side. There are some options but they are limited,
>> and bwfm is the only one with 11ac.
>> 
>> Ignoring trying to run it on OpenBSD, for setups with more than a couple
>> of APs I would probably get either TP-Link Omada or Ubiquiti Unifi with
>> an on-site controller. Omada is a Unifi clone and so far they haven't
>> made quite such annoying/questionable decisions as Ubiquiti have been
>> doing recently.
>> 
>> They both use java 8+mongodb for the controllers. Unifi runs on
>> amd64 OpenBSD (you need to install it from ports as we can't distribute
>> packages - you can't run distributions direct from upstream as some
>> binary part in one of the .jar files isn't built for OpenBSD).
>> I haven't tried running omada on OpenBSD recently; last time I tried
>> it didn't work but that may have changed. There are fairly cheap small
>> "hardware" controllers which might not be a bad idea.
>> 
>
> Thanks. I had many issue with device not being able to roam properly, so
> I guess having a managed setup would help, as it would allow me to not
> have to turn off/on wifi on my devices when moving around the house.

It's more about handling config changes/updates/etc in one place rather
than having to replicate on all the boxes.

Roaming decisions are client-side though there are some things an AP can
do to influence them.

> I should have a Raspberry pi to spare, I can put the controller on it
> and jail that.

That should work if it's running Linux. Won't work for OpenBSD as the
binary components of some of the java libraries aren't available.


-- 
Please keep replies on the mailing list.

Re: Hardware for OpenBSD based access point

[Stuart Henderson]

On 2022-03-14, Stefan Sperling  wrote:
> On Mon, Mar 14, 2022 at 04:58:07AM +0100, Nicolas Goy wrote:
>> I actually have an OpenWRT box (LTE SMS gateway, the LTE modem wasn't
>> compatible with OpenBSD when I installed it), and yeah, it is very
>> decent. I guess that would be a viable alternative.
>
> It is possible to install OpenWRT on some Unify AP models to get rid of
> the Java-based controller requirement, phoning home, etc.

Phone home stuff is in the controller and optional. It has an annoying
popup when you upgrade it asking you whether to allow it. You can certainly
run it with APs and controller firewalled or in a vlan without internet
access if you want, you need to fiddle about a bit if you want to do
firmware upgrades in that case though.

Re: Hardware for OpenBSD based access point

[Nicolas Goy]

On Mon, Mar 14, 2022 at 01:32:35PM -, Stuart Henderson wrote:
> There's no chance of meeting all of these requirements with OpenBSD.
> 
> For AP-side 11ac there are some bwfm(4) devices which _might_ do but they
> are not common. Really at this point the emphasis for wifi on OpenBSD
> is for client-side not AP-side. There are some options but they are limited,
> and bwfm is the only one with 11ac.
> 
> Ignoring trying to run it on OpenBSD, for setups with more than a couple
> of APs I would probably get either TP-Link Omada or Ubiquiti Unifi with
> an on-site controller. Omada is a Unifi clone and so far they haven't
> made quite such annoying/questionable decisions as Ubiquiti have been
> doing recently.
> 
> They both use java 8+mongodb for the controllers. Unifi runs on
> amd64 OpenBSD (you need to install it from ports as we can't distribute
> packages - you can't run distributions direct from upstream as some
> binary part in one of the .jar files isn't built for OpenBSD).
> I haven't tried running omada on OpenBSD recently; last time I tried
> it didn't work but that may have changed. There are fairly cheap small
> "hardware" controllers which might not be a bad idea.
> 

Thanks. I had many issue with device not being able to roam properly, so
I guess having a managed setup would help, as it would allow me to not
have to turn off/on wifi on my devices when moving around the house.

I should have a Raspberry pi to spare, I can put the controller on it
and jail that.

Thanks for all your feedback.

Regards

-- 
Nicolas Goy

https://www.kuon.ch
https://www.goyman.com

Re: Hardware for OpenBSD based access point

[Stuart Henderson]

On 2022-03-14, Nicolas Goy  wrote:
> Hello,
>
> I use OpenBSD for all my network gears except wireless access points.
>
> My current access points are getting old and I'd like to replace them.
>
> I did a bit of researches and there are quite some boards supported by 
> OpenBSD, but I cannot find one that tick all my boxes.
>
> Here are my requirements:
>
> - OpenBSD compatible without proprietary binary blob (coreboot...)
> - Wifi .11ax or way to update to it in the future (mini PCI), I can manage 
> without it for now with .11ac, my current AP are .11n
> - SMA/i-pex... connector
> - 1 gigabit ethernet
> - Bonus: PoE but I don't mind if it doesn't, I'll manage
> - can be a board, a full computer... I'll manage.
> - the form factor doesn't really matter as long as I don't have to hang a 
> midi tower to my wall.
> - must be available in europe (switzerland)
> - < 200$
>
> If you have any suggestion, I would be delighted.
>
> Regards
>

There's no chance of meeting all of these requirements with OpenBSD.

For AP-side 11ac there are some bwfm(4) devices which _might_ do but they
are not common. Really at this point the emphasis for wifi on OpenBSD
is for client-side not AP-side. There are some options but they are limited,
and bwfm is the only one with 11ac.

Ignoring trying to run it on OpenBSD, for setups with more than a couple
of APs I would probably get either TP-Link Omada or Ubiquiti Unifi with
an on-site controller. Omada is a Unifi clone and so far they haven't
made quite such annoying/questionable decisions as Ubiquiti have been
doing recently.

They both use java 8+mongodb for the controllers. Unifi runs on
amd64 OpenBSD (you need to install it from ports as we can't distribute
packages - you can't run distributions direct from upstream as some
binary part in one of the .jar files isn't built for OpenBSD).
I haven't tried running omada on OpenBSD recently; last time I tried
it didn't work but that may have changed. There are fairly cheap small
"hardware" controllers which might not be a bad idea.

MikroTik was mentioned too, that might be an option but IMHO they are
better at routers and wireless bridges than they are at making APs for
normal end-devices to connect to. 8 APs is enough that you probably do
want some kind of management setup; they have this but it's more complex
than unifi/omada (https://wiki.mikrotik.com/wiki/Manual:Simple_CAPsMAN_setup)


-- 
Please keep replies on the mailing list.

Re: Hardware for OpenBSD based access point

[Stefan Sperling]

On Mon, Mar 14, 2022 at 04:58:07AM +0100, Nicolas Goy wrote:
> I actually have an OpenWRT box (LTE SMS gateway, the LTE modem wasn't
> compatible with OpenBSD when I installed it), and yeah, it is very
> decent. I guess that would be a viable alternative.

It is possible to install OpenWRT on some Unify AP models to get rid of
the Java-based controller requirement, phoning home, etc.

Re: Hardware for OpenBSD based access point

[Paulo Mafra]

Hi, i have an ubiquiti u6-lr connected in bridge mode with an openbsd router.  
The controller runs on the openbsd, take a look at ports packages.  It works 
like a sharm and i can reach about 400 mbps in wifi. 

Regards,
Paulo. 


> Em 14 de mar. de 2022, à(s) 04:41, Stuart Longland 
>  escreveu:
> 
> On Mon, 14 Mar 2022 04:58:07 +0100
> Nicolas Goy  wrote:
> 
>>> If you don't mind having a small Linux machine running Java 8 (yes, I
>>> know), Ubiquiti UniFI APs aren't bad, but I can well understand the
>>> desire to avoid such a dependency.  The silver lining I guess is the
>>> Linux machine could be a virtual machine running atop an OpenBSD host
>>> on-premise and "powered off" unless configuration settings need to be
>>> made.  
>> 
>> Aren't unifi AP notorious for phoning home?
> 
> Mine are sitting on a largely isolated VLAN for management purposes.
> 
>> Well, I can deny them outside access. I actually have a linux server
>> with java for my kids' minecraft world, so I can use that. The
>> controller is only required to be running for configuration changes?
>> I guess that could work.
> 
> Yep, as I say, one downside is that the latest version of Java they
> support is Java v8, and the back-end database is a rather dated version
> of MongoDB.  Ubuntu 20.04 ships the required version of Java, and Ubiquiti's
> instructions for deployment include details on where to get the
> required version of MongoDB.
> 
> Personally, the proprietary controller is the biggest downside with
> these things.  The concept is good (particularly in situations where
> you have a fleet of APs: configure a SSID in the controller, it's
> rolled out to all APs) but its implementation has obvious downsides.
> 
> For now though, I just put up with that aspect as to go multi-SSID
> 802.1Q APs with Cisco seems to be four figures (AUD) now, and
> it's what I can readily get my hands on here in Brisbane in the
> short-term.
> 
> I might have a look at the Mikrotik stuff at some point.  I do notice
> the market seem to have split: extra-cheap and nasty SoHO, or
> enterpri$e, with nothing in between.  Last stand-alone AP I had that was
> in this middle ground was the Cisco WAP150, and I found its performance
> underwhelming.
> 
> Makes me wonder if a Raspberry Pi CM4 + decent PCIe WiFi adaptor might
> be a better solution long-term.  If there's a 802.11ax WiFi chipset
> that's AP-capable with good documentation, maybe an OpenBSD-based AP
> might be a reasonable proposition after all?
> -- 
> Stuart Longland (aka Redhatter, VK4MSL)
> 
> I haven't lost my mind...
>  ...it's backed up on a tape somewhere.
> 

Re: Hardware for OpenBSD based access point

[Jan Stary]

On Mar 14 01:52:15, k...@goyman.com wrote:
> I use OpenBSD for all my network gears except wireless access points.

Same here.

> My current access points are getting old and I'd like to replace them.
> I did a bit of researches and there are quite some boards
> supported by OpenBSD, but I cannot find one that tick all my boxes.

To be sure: you want to replace a dedicated HW AP (such as a TP-Link)
with an OpenBSD box to be your AP?

I used to run that with athn(4) in an ALIX,
or more recently with athn(4) in an APU,
but a cheap-o TP-Link gadget still beats that,
in my experience: faster and more reliable.

Of course, you have a separete non-opnebsd box to care about.
But once isolated to do just the AP'ing, I have had no problems.


On Mar 13 21:28:26, grobe...@gmail.com wrote:
> I use (and I believe there are others on here who do as well) an external
> WAP, that handles only the wireless connections, with DHCP, routing,
> firewalling, etc., handled by a separate OpenBSD box, the WAP being used
> only as a bridge.

Yes.

> For the OpenBSD hardware portion, you could try https://pcengines.ch APU

Yes.

> > If you don't mind having a small Linux machine running Java 8

Surely that is well beyond the realm of sane requirements
for running an AP ...

> Aren't unifi AP notorious for phoning home? Well, I can deny them
> outside access. I actually have a linux server with java for my kids'
> minecraft world, so I can use that. The controller is only required to
> be running for configuration changes? I guess that could work.

On Mar 14 17:37:26, stua...@longlandclan.id.au wrote:
> > Aren't unifi AP notorious for phoning home?
> Mine are sitting on a largely isolated VLAN for management purposes.

Are you logging the blocked traffic of them calling home?
Have you looked at what they are trying to do? (Just curious.)

Jan