Full disk encryption - Verifying/changing passphrase

[patrick keshishian]

Hello,

For the first time I decided to set up full disk encryption on a new
drive. Process went smoothly!

Anyway, here are two possibly silly questions:
1. How can one verify they remember the passphrase before
rebooting/shutting down?
2. What is the process (steps) to change/update the passphrase?

Is the process simply running "bioctl -P sdX"? And entering old and
then new passphrases?

--patrick

Re: Add support for RK356x eMMC controller

[Patrick Wildt]

On Mon, Feb 26, 2024 at 04:47:53PM +0100, Mizsei Zolt??n wrote:
> Hi,
> 
> on NetBSD  the following is used to support the eMMC modules on RK356x. Would 
> it possible to implement asomething similar for OpenBSD?
> 
> https://github.com/NetBSD/src/commit/f30b89bb4385f5fe218ff86be5d458a51fc62d4c
> 
> For more info see the original commit message below:
> 
> "acpi: sdhc: Add support for RK356x eMMC controller.
> RK356x has a DesignWare eMMC controller that is somewhat SDHCI compliant,
> with one major problem -- the clock divisor doesn't actually work. To
> change the clock card on Rockchip SoCs, the clock frequency needs to be
> adjusted in the Clock & Reset Unit (CRU) directly.
> 
> The RK356x UEFI implementation introduces a DSM that allows drivers to
> request firmware assistance in setting the card clock rate, for instances
> like this where the divisor is broken.

RK356x is not a viable platform for use with ACPI.  I'd recommend to
switch to a Linux-mainline device tree and use a current U-Boot, if
possible.

Re: [arm64] [sound] simpleaudio, but no audio to attach

[Patrick Wildt]

On Wed, Apr 19, 2023 at 06:09:06AM -, Stuart Henderson wrote:
> On 2023-04-18, S V  wrote:
> > Hello, misc@!
> >
> > I'm using ARM64/current and see that my audio chip got detected by 
> > simpleaudio
> > but OpenBSD can't attach audio to it
> >
> > Any suggestions on there to start reading? I'm not developer,
> > but I tried to read different match/attach functions
> > in simpleaudio.c/audio.c with no result for now.
> 
> Fortunately you don't need to be a programmer to add some code that
> will help you figure out more about what's going on.
> 
> Try adding printf()s to simpleaudio_attach_deferred() to check if that
> function is called and, if so, see how far it gets.
> 
> I guess it might hit one of the "return"s before actually attaching, so
> for example you could add printf before+after the various return
> statements to see if they were triggered.
> 
> While you can just printf some text that you write to identify them,
> you can save a bit of time by sprinkling some of these which use the
> C features to include the function name/line number:
> 
>   printf("... %s line %d\n", __func__, __LINE__);

Yup.  Also we don't appear to have support for nuvoton,nau8822, so that
might be a hindrance.  simpleaudio is merely a meta-node that combines
all the necessary HW pieces for a audio path.  This usually needs some-
thing that does I2S (transfers audio), speakers and... probably some-
thing else I forgot.  Your simpleaudio node shows two pieces, referenced
through the phandles 0031 and 0032.  You should look these up
to see what drivers you need to implement.

Re: bridge(4) question new network setup

[patrick keshishian]

On 1/21/23, David Gwynne  wrote:
> On Sat, Jan 21, 2023 at 01:46:34PM -0800, patrick keshishian wrote:
>> On 1/20/23, David Gwynne  wrote:
>> > On Fri, Jan 20, 2023 at 11:09:47AM -0800, patrick keshishian wrote:
>> >> Hello,
>> >>
>> >> I am trying get a new ISP setup working.  The Router is
>> >> causing some pain.  There is a /28 public block assigned.
>> >> The DSL router can't be configured in transparent bridge
>> >> mode (they say).  It holds on to one of the /28 addresses.
>> >
>> > i'm sure they say that, but that doesn't mean it's impossible. this
>> > will be a lot easier and more useful if you can get a dsl modem
>> > into bridge/transparent mode and do all the routing on your own
>> > box.
>>
>> OK. So the situation was a bit worse than I had actually
>> anticipated.  After I got the described setup configured
>> I noticed that the DSL Router/Modem wouldn't send out
>> any traffic unless it had an arp entry for the source.
>> e.g., nat-to an unassigned IP from the /28 wouldn't go out.
>>
>> Again, in my limited networking knowledge, it meant I had
>> to do proxy arp entries for /28 public IPs in the $dmz.
>> This was quite frustrating.
>>
>> So I started poking around in the DSL Router/modem settings
>> (cuing off your "doesn't mean it's impossible") and I
>> have it now acting as a transparent bridge!
>>
>> I spent most of Tues on the phone with their techs, and I
>> was assured that is not possible/unsupported.  Now maybe
>> they actually meant "unsupported" mode as far as their
>> support is concerned.
>>
>> But things seem to running as expect (so far)!  So thanks
>> for the bit of "encouragement"!
>
> Does that mean you have the WAN IP on your router now? And you can do
> whatever you want with the /28?

Yep!  And it made things so much easier to set up.

>> > that would also give you the option to do fun stuff like NOT putting
>> > the /28 onto an ethernet network so you could you use all 16 of the
>> > IPs on dmz hosts instead of losing some to network/broadcast/gateway.
>>
>> I am curious how you would go about doing what you suggest:
>> Using all 16 of /28.
>
> The simple (and currently best supported) way is to set up a tunnel
> interface for every IP in the /28 and connect the tunnel to the server
> providing the service. The router would have a config like this:
>
> ifconfig gif0 create
> ifconfig gif0 tunnel $router_lan_ip $server_lan_ip
> ifconfig gif0 inet $router_gif_ip $server_slash28_ip

A bit above my pay-grade.  I'll need to study this later on.

Thanks again for the hints/help!
--patrick


>>
>> Thanks for your reply,
>> --patrick
>>
>>
>> >> The setup looks something like this:
>> >> (and hopefully the ascii "art" remains intact from gmail)
>> >>
>> >>( internet )
>> >> |
>> >> | [WAN IP]
>> >>   +-o--+
>> >>  / DSL ROUTER / <-- Transparent bridge mode NOT possible
>> >> +-o--+
>> >>   | [ one of /28 Public IPs = $dslgw_ip ]
>> >>   |
>> >>   |
>> >>   | $ext
>> >> +-o--+
>> >> ||
>> >> | OpenBSD/pf o--- ( rest of /28 Public IP network )
>> >> || $dmz  (DMZ: httpd, smtpd, ...)
>> >> +-o--+
>> >>  $lan | [10.x.x.1]
>> >>   |
>> >> ( 10.x.x.x network )
>> >>
>> >>
>> >> As far as networking goes, I need to be spoken to as if I'm
>> >> a fledgling.
>> >>
>> >> I want to do the obvious: use OpenBSD/pf(4) to:
>> >>  - Filter traffic from $ext to $dmz
>> >>  - Filter traffic from $dmz outbound
>> >>  - Filter traffic from $lan (10.x.x.x) to $dmz
>> >>  - NAT traffic from $lan (10.x.x.x) outbound to internet
>> >>
>> >>
>> >> I'm bridge(4)-ing $ext and $dmz.  Which means I must give
>> >> one of the /28 public IP addresses to either $ext or $dmz
>> >> to be able to do:
>> >>
>> >> # route add default $dslgw_ip
>> >>
>> >> (!?)
>> >>
>> >> Am I missing something?
>> >> Is there a better way to configure things?
>> >>
>> >> Thanks,
>> >> --patrick
>> >>
>> >
>

Re: bridge(4) question new network setup

[patrick keshishian]

On 1/21/23, David Gwynne  wrote:
> On Sat, Jan 21, 2023 at 01:32:18PM -0800, patrick keshishian wrote:
>> On 1/20/23, Hrvoje Popovski  wrote:
>> > On 20.1.2023. 20:09, patrick keshishian wrote:
>> >> Hello,
>> >>
>> >> I am trying get a new ISP setup working.  The Router is
>> >> causing some pain.  There is a /28 public block assigned.
>> >> The DSL router can't be configured in transparent bridge
>> >> mode (they say).  It holds on to one of the /28 addresses.
>> >>
>> >> The setup looks something like this:
>> >> (and hopefully the ascii "art" remains intact from gmail)
>> >>
>> >>( internet )
>> >> |
>> >> | [WAN IP]
>> >>   +-o--+
>> >>  / DSL ROUTER / <-- Transparent bridge mode NOT possible
>> >> +-o--+
>> >>   | [ one of /28 Public IPs = $dslgw_ip ]
>> >>   |
>> >>   |
>> >>   | $ext
>> >> +-o--+
>> >> ||
>> >> | OpenBSD/pf o--- ( rest of /28 Public IP network )
>> >> || $dmz  (DMZ: httpd, smtpd, ...)
>> >> +-o--+
>> >>  $lan | [10.x.x.1]
>> >>   |
>> >> ( 10.x.x.x network )
>> >>
>> >>
>> >> As far as networking goes, I need to be spoken to as if I'm
>> >> a fledgling.
>> >>
>> >> I want to do the obvious: use OpenBSD/pf(4) to:
>> >>  - Filter traffic from $ext to $dmz
>> >>  - Filter traffic from $dmz outbound
>> >>  - Filter traffic from $lan (10.x.x.x) to $dmz
>> >>  - NAT traffic from $lan (10.x.x.x) outbound to internet
>> >>
>> >>
>> >> I'm bridge(4)-ing $ext and $dmz.  Which means I must give
>> >> one of the /28 public IP addresses to either $ext or $dmz
>> >> to be able to do:
>> >>
>> >> # route add default $dslgw_ip
>> >>
>> >> (!?)
>> >>
>> >> Am I missing something?
>> >> Is there a better way to configure things?
>> >>
>> >> Thanks,
>> >> --patrick
>> >>
>> >
>> > Hi,
>> >
>> > If your ext interface is in same subnet as that /28 from your ISP then
>> > you could:
>> >
>> > - use veb(4) to bridge ext, dmz and vport(4) interface and add default
>> > route to dslgw_ip. vport is ip interface for veb
>>
>> I started out looking at veb(4) but I wasn't confident
>> how I could filter traffic in/out of $dmz.  Also, the
>> description of vport(4) which states "packets traversing
>> vport interfaces appear to travel in the opposite direction
>> to packets travelling over other ports" confused me even
>> more.  So I started using bridge(4).
>
> When you add a port to veb(4), it takes it over completely and by
> default it only uses it to switch traffic at layer 2 (Ethernet).
> In other words, by default veb(4) does not run pf against packets
> on ports.
>
> vport is an exception because it operates as if it is a normal
> ethernet interface plugged into a switchport, it's just that the
> switch in this situation is veb, and the other ports on that switch
> are the non-vport interfaces you added to the veb.

Thanks for taking the time to explain in these two paragraphs.
I definitely have a better sense of veb/vport now.

> So, by default veb lets you build a switch out of other interfaces
> in the system, and vport lets you plug the kernel network stack
> into that virtual switch. Because packets from a normal switch coming
> into a normal physical interface go in to the network stack, that is
> also how it behaves with vport. ie, you write rules in pf like this for
> packets coming from a veb into a vport:
>
>   pass in on vport0 inet tcp from any to port ssh

Nice.

> If you do enable IP filtering on veb (ie, you ifconfig veb0 link1 as per
> the ifconfig manpage), then packets coming from the "wire" into the
> interface are filtered by pf too. This means that if a packet is coming
> from the wire and is destined to your network stack via a vport
> interface, it will be going through pf twice: once when it comes into
> the physical interface and again when it goes over vport.
>
> pf is not designed for a packet to be processed twice. TCP packets in
> particular going through pf twice will confuse the window tracking. If
> you're doing NAT or something like that, it can also get confused.
>
> So if you're going 

Re: bridge(4) question new network setup

[patrick keshishian]

On 1/20/23, David Gwynne  wrote:
> On Fri, Jan 20, 2023 at 11:09:47AM -0800, patrick keshishian wrote:
>> Hello,
>>
>> I am trying get a new ISP setup working.  The Router is
>> causing some pain.  There is a /28 public block assigned.
>> The DSL router can't be configured in transparent bridge
>> mode (they say).  It holds on to one of the /28 addresses.
>
> i'm sure they say that, but that doesn't mean it's impossible. this
> will be a lot easier and more useful if you can get a dsl modem
> into bridge/transparent mode and do all the routing on your own
> box.

OK. So the situation was a bit worse than I had actually
anticipated.  After I got the described setup configured
I noticed that the DSL Router/Modem wouldn't send out
any traffic unless it had an arp entry for the source.
e.g., nat-to an unassigned IP from the /28 wouldn't go out.

Again, in my limited networking knowledge, it meant I had
to do proxy arp entries for /28 public IPs in the $dmz.
This was quite frustrating.

So I started poking around in the DSL Router/modem settings
(cuing off your "doesn't mean it's impossible") and I
have it now acting as a transparent bridge!

I spent most of Tues on the phone with their techs, and I
was assured that is not possible/unsupported.  Now maybe
they actually meant "unsupported" mode as far as their
support is concerned.

But things seem to running as expect (so far)!  So thanks
for the bit of "encouragement"!

> that would also give you the option to do fun stuff like NOT putting
> the /28 onto an ethernet network so you could you use all 16 of the
> IPs on dmz hosts instead of losing some to network/broadcast/gateway.

I am curious how you would go about doing what you suggest:
Using all 16 of /28.

Thanks for your reply,
--patrick


>> The setup looks something like this:
>> (and hopefully the ascii "art" remains intact from gmail)
>>
>>( internet )
>> |
>> | [WAN IP]
>>   +-o--+
>>  / DSL ROUTER / <-- Transparent bridge mode NOT possible
>> +-o--+
>>   | [ one of /28 Public IPs = $dslgw_ip ]
>>   |
>>   |
>>   | $ext
>> +-o--+
>> ||
>> | OpenBSD/pf o--- ( rest of /28 Public IP network )
>> || $dmz  (DMZ: httpd, smtpd, ...)
>> +-o--+
>>  $lan | [10.x.x.1]
>>   |
>> ( 10.x.x.x network )
>>
>>
>> As far as networking goes, I need to be spoken to as if I'm
>> a fledgling.
>>
>> I want to do the obvious: use OpenBSD/pf(4) to:
>>  - Filter traffic from $ext to $dmz
>>  - Filter traffic from $dmz outbound
>>  - Filter traffic from $lan (10.x.x.x) to $dmz
>>  - NAT traffic from $lan (10.x.x.x) outbound to internet
>>
>>
>> I'm bridge(4)-ing $ext and $dmz.  Which means I must give
>> one of the /28 public IP addresses to either $ext or $dmz
>> to be able to do:
>>
>> # route add default $dslgw_ip
>>
>> (!?)
>>
>> Am I missing something?
>> Is there a better way to configure things?
>>
>> Thanks,
>> --patrick
>>
>

Re: bridge(4) question new network setup

[patrick keshishian]

On 1/20/23, Hrvoje Popovski  wrote:
> On 20.1.2023. 20:09, patrick keshishian wrote:
>> Hello,
>>
>> I am trying get a new ISP setup working.  The Router is
>> causing some pain.  There is a /28 public block assigned.
>> The DSL router can't be configured in transparent bridge
>> mode (they say).  It holds on to one of the /28 addresses.
>>
>> The setup looks something like this:
>> (and hopefully the ascii "art" remains intact from gmail)
>>
>>( internet )
>> |
>> | [WAN IP]
>>   +-o--+
>>  / DSL ROUTER / <-- Transparent bridge mode NOT possible
>> +-o--+
>>   | [ one of /28 Public IPs = $dslgw_ip ]
>>   |
>>   |
>>   | $ext
>> +-o--+
>> ||
>> | OpenBSD/pf o--- ( rest of /28 Public IP network )
>> || $dmz  (DMZ: httpd, smtpd, ...)
>> +-o--+
>>  $lan | [10.x.x.1]
>>   |
>> ( 10.x.x.x network )
>>
>>
>> As far as networking goes, I need to be spoken to as if I'm
>> a fledgling.
>>
>> I want to do the obvious: use OpenBSD/pf(4) to:
>>  - Filter traffic from $ext to $dmz
>>  - Filter traffic from $dmz outbound
>>  - Filter traffic from $lan (10.x.x.x) to $dmz
>>  - NAT traffic from $lan (10.x.x.x) outbound to internet
>>
>>
>> I'm bridge(4)-ing $ext and $dmz.  Which means I must give
>> one of the /28 public IP addresses to either $ext or $dmz
>> to be able to do:
>>
>> # route add default $dslgw_ip
>>
>> (!?)
>>
>> Am I missing something?
>> Is there a better way to configure things?
>>
>> Thanks,
>> --patrick
>>
>
> Hi,
>
> If your ext interface is in same subnet as that /28 from your ISP then
> you could:
>
> - use veb(4) to bridge ext, dmz and vport(4) interface and add default
> route to dslgw_ip. vport is ip interface for veb

I started out looking at veb(4) but I wasn't confident
how I could filter traffic in/out of $dmz.  Also, the
description of vport(4) which states "packets traversing
vport interfaces appear to travel in the opposite direction
to packets travelling over other ports" confused me even
more.  So I started using bridge(4).

> - or on ext interface put ip alias with ip addresses from /28 public
> range and than do binat-to or nat-to in pf to hosts in dmz
>
> or maybe i totally misunderstood you  :)

I think you understood me fine. I'm just not too familiar
with how networking actually works.

Thanks,
--patrick

bridge(4) question new network setup

[patrick keshishian]

Hello,

I am trying get a new ISP setup working.  The Router is
causing some pain.  There is a /28 public block assigned.
The DSL router can't be configured in transparent bridge
mode (they say).  It holds on to one of the /28 addresses.

The setup looks something like this:
(and hopefully the ascii "art" remains intact from gmail)

   ( internet )
|
| [WAN IP]
  +-o--+
 / DSL ROUTER / <-- Transparent bridge mode NOT possible
+-o--+
  | [ one of /28 Public IPs = $dslgw_ip ]
  |
  |
  | $ext
+-o--+
||
| OpenBSD/pf o--- ( rest of /28 Public IP network )
|| $dmz  (DMZ: httpd, smtpd, ...)
+-o--+
 $lan | [10.x.x.1]
  |
( 10.x.x.x network )


As far as networking goes, I need to be spoken to as if I'm
a fledgling.

I want to do the obvious: use OpenBSD/pf(4) to:
 - Filter traffic from $ext to $dmz
 - Filter traffic from $dmz outbound
 - Filter traffic from $lan (10.x.x.x) to $dmz
 - NAT traffic from $lan (10.x.x.x) outbound to internet


I'm bridge(4)-ing $ext and $dmz.  Which means I must give
one of the /28 public IP addresses to either $ext or $dmz
to be able to do:

# route add default $dslgw_ip

(!?)

Am I missing something?
Is there a better way to configure things?

Thanks,
--patrick

Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version

[Patrick Wildt]

On Fri, Oct 28, 2022 at 12:26:07PM -0700, Mike Larkin wrote:
> On Fri, Oct 28, 2022 at 12:30:11PM -0600, Theo de Raadt wrote:
> > Kalabic S,  wrote:
> >
> > > To be more precise, I wanted to say sticking with FreeBSD means
> > > sticking with whatever behavior VMware will keep consistent and
> > > support in the future. For "Others" option I don't think they care and
> > > is more probable to vary.
> >
> > I cannot tell the difference.  I think you are completely unqualified
> > to know what "they will not change" fakery vmware is doing with the MSR's
> > and clock related registers... it is actually possible that when they
> > *know* it is one particular operating system they do something sophisticated
> > to fool that one specific operating system, whereas when they don't know
> > what the operating system is, they reduce the amount of trickery.
> >
> > You don't know.  I don't know.  None of us know.
> >
> > But can you please stop making claims you can't back.
> >
> 
> I think it's reasonable to try and claim that whatever we are, we are the
> closest to "that thing". Meaning, the OP said we should claim we are FreeBSD
> 64 bit or 32 bit or whatever. Fine, but let's spend some time to actually
> figure out *what* we should say we are before we just pick something randomly
> because "it fixed my machine". Maybe we should say we're Windows? Maybe we
> should say we're Linux? My point, and I think Theo's as well, is we don't
> know and just randomly taking a diff because it fixes one scenario on one
> version of ESXi is shortsighted.
> 
> So I would ask the OP to:
> 
>  - try different OS choices
>  - on different versions of ESX
>  - on different versions of VMware fusion
>  - on different versions of VMware workstation
>  - on different versions of OpenBSD VMs
>  - on different archs (i386/amd64) of OpenBSD VMs
> 
> ... and then report back what the findings are.
> 
> -ml

Hi,

>From what I've been told from someone in the know:

* What we report in vmt(4) doesn't influence what machine is modeled,
  that's just for what's shown in vCenter.  We should probably show
  something useful.  I kinda liked that OpenBSD 7.2 GENEIRC.MP#31 string
  that jmatthew@ showed, but that's another discussion.

* The guest type configured in the .vmx influences the VM model.  Just
  assume the ESXi version has a workaround for FreeBSD to run fine on
  that ESXi, it could be possible that it actually degrades OpenBSD
  performance/stability.  In general it makes more sense to opt for the
  Other 64-Bit guest type (for amd64).

I personally sometimes use Windows 11 guest types on things like VMware
Fusion or Parallels, but that's mostly because they sometimes have some
funky devices and I'm doing that for testing w/ graphics.  For ESXi I'd
opt for Other 64-Bit.

Cheers,
Patrick

Re: X/DRM freeze on 7.2

[Patrick Harper]

Hi,

https://docs.mesa3d.org/envvars.html#radeonsi-driver-environment-variables

For me freezes happen only when hardware acceleration is enabled so this
might be a good place to start.

-- 
  Patrick Harper
  paia...@fastmail.com

On Fri, 21 Oct 2022, at 19:56, Mickael Torres wrote:
> Hello,
>
> Since upgrading to 7.2, I have X/DRM freezes on one computer (dmesg below).
>
> When it happens, the screen is completely frozen, but I can still ssh 
> to the machine.
> It only happened when starting firefox or VLC, for now. Once they are 
> started I didn't have any
> problem.
> When the machine is in that state, the X and firefox processes are in 
> the DRM wait state:
> 87821 _x11 -200   97M  110M idle  DRM   0:01  0.00% Xorg
> 76467 mike -200   12M   28M idle  DRM   0:00  0.00% 
> firefox
> 51234 mike -200 5972K   49M idle  DRM   0:00  0.00% 
> firefox
> Nothing in dmesg or Xorg.0.log.
>
> As far as I can remember, it never happened with 7.1.
>
> Is there anything I can do to further debug this?
>
> Best,
> Mickael
>
> OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 68598935552 (65421MB)
> avail mem = 66502520832 (63421MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.3 @ 0xbda23000 (49 entries)
> bios0: vendor American Megatrends International, LLC. version "F37d" 
> date 07/27/2022
> bios0: Gigabyte Technology Co., Ltd. X570 AORUS ELITE
> acpi0 at bios0: ACPI 6.2
> acpi0: sleep states S0 S4 S5
> acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT FIDT MCFG HPET SSDT IVRS 
> FPDT VFCT BGRT PCCT SSDT CRAT CDIT SSDT SSDT SSDT SSDT WSMT APIC SSDT
> acpi0: wakeup devices GPP0(S4) GPP2(S4) GPP3(S4) GPP4(S4) GPP5(S4) 
> GPP6(S4) GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) 
> GPPE(S4) GPPF(S4) GP10(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf000, bus 0-127
> acpihpet0 at acpi0: 14318180 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Ryzen 9 5900X 12-Core Processor, 3700.08 MHz, 19-21-00
> 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,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 
> 64b/line 8-way L2 cache, 32MB 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 100MHz
> cpu0: mwait min=64, max=64, C-substates=1.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD Ryzen 9 5900X 12-Core Processor, 3700.00 MHz, 19-21-00
> 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,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 
> 64b/line 8-way L2 cache, 32MB 64b/line 16-way L3 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: AMD Ryzen 9 5900X 12-Core Processor, 3700.00 MHz, 19-21-00
> 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,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 
> 64b/line 8-way L2 cache, 32MB 64b/line 16-way L3 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: AMD Ryzen 9 5900X 12-Core Processor, 3700.00 MHz, 19-21-00

Re: radeondrm / radeon 8570

[Patrick Harper]

In Chrome, try logging on to chrome://flags and enable #ignore-gpu-blocklist.

Make sure hardware acceleration is enabled in the settings as well.

-- 
  Patrick Harper
  paia...@fastmail.com

On Fri, 28 Jan 2022, at 23:46, Chris Cappuccio wrote:
> is anyone trying to use an older radeondrm card with current?
>
> i just moved my SSDs into an amd64 box with a radeon 8570 card and 
> everything seems to work, glxgears works fast...
>
> ...until i start firefox or chrome, and pull up, say, youtube's 
> video-image-laden front page, then the browser window mostly freezes up 
> and responds extremely slowly, also after this point glxgears barely 
> runs at all, it claims a 4 frames per second but is more like 4 seconds 
> per frame, even after firefox is stopped
>
> OpenBSD 7.0-current (GENERIC.MP) #287: Tue Jan 25 01:38:55 MST 2022
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 137342574592 (130980MB)
> avail mem = 133162971136 (126994MB)
> random: boothowto does not indicate good seed
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xcbacc018 (128 entries)
> bios0: vendor Hewlett-Packard version "J63 v03.50" date 08/14/2013
> bios0: Hewlett-Packard HP Z820 Workstation
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT MCFG SRAT SLIT HPET SSDT SLIC SSDT 
> SSDT ASF! TCPA IFEU
> acpi0: wakeup devices PS2K(S3) UAR1(S3) BR20(S4) EUSB(S4) USBE(S4) 
> GBE_(S4) NP1B(S4) NPE2(S4) NPE3(S4
> ) PEX1(S4) PEX2(S4) PEX4(S4) NPE2(S4) NPE3(S4) PWRB(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) Xeon(R) CPU E5-2667 0 @ 2.90GHz, 2893.42 MHz, 06-2d-07
> 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,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU E5-2667 0 @ 2.90GHz, 2893.04 MHz, 06-2d-07
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Xeon(R) CPU E5-2667 0 @ 2.90GHz, 2893.04 MHz, 06-2d-07
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Xeon(R) CPU E5-2667 0 @ 2.90GHz, 2893.04 MHz, 06-2d-07
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, package 0
> cpu4 at mainbus0: apid 8 (application processor)
> cpu4: Intel(R) Xeon(R) CPU E5-2667 0 @ 2.90GHz, 2893.04 MHz, 06-2d-07
> cpu4: 
> 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,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu4: 256KB 64b/line 8-way L2 cache
> cpu4: smt 0, core 4, package 0
> cpu5 at mainbus0: apid 10 (application processor)
> cpu5: Intel(R) Xeon(R) CPU E5-2667 0 @ 2.90GHz, 2893.04 MHz, 06-2d-07
> cpu5: 
> 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,C

Re: ix(4) stopped working after upgrade to OpenBSD 6.8

[Patrick Wildt]

Am Sun, Jan 16, 2022 at 06:38:08PM - schrieb Stuart Henderson:
> On 2022-01-16, Ax0n  wrote:
> > I have a SuperMicro X9DRH-7TF that's been chugging along diligently in a
> > data center. I've been upgrading the vmm instances it hosts but I let the
> > host get pretty far behind. After running sysupgrade to 6.8, the system
> > never came back online. I have the Supermicro BMC IPMI, so I used that to
> > mount remote CD-ROMs to complete the upgrade to 6.9 and 7.0. The network
> > still doesn't work, from the install images or after it's been upgraded.
> > There have been "mem address conflict" messages on this hardware for as
> > long as I can remember. OpenBSD 6.4 at least. They may or may not be a red
> > herring.
> >
> > I mounted the OpenBSD 6.7 cd67.iso and I was able to get it on the network
> > again. Somewhere between 6.7 and 6.8, ix(4) broke with this hardware, an
> > integrated dual-port Intel X540.
> 
> Do both ix0 and ix1 break, or just ix1?
> 
> One important difference visible in dmesg is that ix starts using MSI-X.

Can you give this a go?  I remember issues with broken MSI-X bars or so,
but that was on some Ryzen.

Patrick

diff --git a/sys/arch/amd64/pci/pci_machdep.c b/sys/arch/amd64/pci/pci_machdep.c
index 72456c32829..1cdc33757ee 100644
--- a/sys/arch/amd64/pci/pci_machdep.c
+++ b/sys/arch/amd64/pci/pci_machdep.c
@@ -96,6 +96,8 @@
 #include 
 #endif
 
+intpci_check_msix_bar(pci_chipset_tag_t, pcitag_t);
+
 /*
  * Memory Mapped Configuration space access.
  *
@@ -497,6 +499,36 @@ msix_delroute(struct pic *pic, struct cpu_info *ci, int 
pin, int vec, int type)
pci_msix_table_unmap(pc, tag, memt, memh);
 }
 
+/*
+ * BIOS assigns BAR addresses for every PCI device, but some BIOS are bugged 
and
+ * map an illegal address, say for instance an address outside the ppb(4) 
range.
+ * When this occurs, OpenBSD rewrites the BAR address as 0.
+ * This BAR might be the MSI-X BAR, therefore we consider address 0 as a bad 
BAR
+ * address and fail MSI-X mapping. It's not greatest solution but since we
+ * never correct bad addresses for BARs, this at least prevents us from using
+ * MSI-X when we know it won't work.
+ */
+int
+pci_check_msix_bar(pci_chipset_tag_t pc, pcitag_t tag)
+{
+   pcireg_t table;
+   bus_addr_t base;
+   int bir, off;
+
+   if (pci_get_capability(pc, tag, PCI_CAP_MSIX, , NULL) == 0)
+   return (ENODEV);
+
+   table = pci_conf_read(pc, tag, off + PCI_MSIX_TABLE);
+   bir = (table & PCI_MSIX_TABLE_BIR);
+   bir = PCI_MAPREG_START + bir * 4;
+
+   if (pci_mem_find(pc, tag, bir, , NULL, NULL) ||
+   base == 0)
+   return (ENODEV);
+
+   return (0);
+}
+
 int
 pci_intr_map_msix(struct pci_attach_args *pa, int vec, pci_intr_handle_t *ihp)
 {
@@ -507,7 +539,8 @@ pci_intr_map_msix(struct pci_attach_args *pa, int vec, 
pci_intr_handle_t *ihp)
KASSERT(PCI_MSIX_VEC(vec) == vec);
 
if ((pa->pa_flags & PCI_FLAGS_MSI_ENABLED) == 0 || mp_busses == NULL ||
-   pci_get_capability(pc, tag, PCI_CAP_MSIX, NULL, ) == 0)
+   (pci_get_capability(pc, tag, PCI_CAP_MSIX, NULL, ) == 0) ||
+   pci_check_msix_bar(pc, tag))
return 1;
 
if (vec > PCI_MSIX_MC_TBLSZ(reg))
diff --git a/sys/dev/pci/pci_map.c b/sys/dev/pci/pci_map.c
index 3cc0e61c0df..9567e83c363 100644
--- a/sys/dev/pci/pci_map.c
+++ b/sys/dev/pci/pci_map.c
@@ -135,7 +135,12 @@ obsd_pci_mem_find(pci_chipset_tag_t pc, pcitag_t tag, int 
reg, pcireg_t type,
u_int64_t waddress, wmask;
int s, is64bit;
 
-   is64bit = (PCI_MAPREG_MEM_TYPE(type) == PCI_MAPREG_MEM_TYPE_64BIT);
+   if (type == -1)
+   is64bit = (PCI_MAPREG_MEM_TYPE(pci_conf_read(pc, tag, reg))
+   == PCI_MAPREG_MEM_TYPE_64BIT);
+   else
+   is64bit = (PCI_MAPREG_MEM_TYPE(type) ==
+   PCI_MAPREG_MEM_TYPE_64BIT);
 
if (reg < PCI_MAPREG_START ||
 #if 0

Re: unknown warning option '-Wno-unused-but-set-variable'

[Patrick Wildt]

Kernel Makefiles were adjusted to compile with clang 13.  Either take
out the warnings so you can compile with old-clang, or rebuild clang.

What should have been done was to add no-op arguments for these warnings
into clang 11 to ease the transition to clang 13, but somehow no one did
it, huh.

Patrick

Am Fri, Dec 17, 2021 at 07:23:06PM +0100 schrieb Jan Stary:
> This is current/i386 on an ALIX.1E (dmesg below).
> The kernel does not build with the current cvs:
> 
> cat /usr/src/sys/arch/i386/i386/genassym.cf 
> /usr/src/sys/arch/i386/i386/genassym.cf |  sh /usr/src/sys/kern/genassym.sh 
> cc -no-integrated-as -g -Werror -Wall -Wimplicit-function-declaration  
> -Wno-pointer-sign  -Wframe-larger-than=2047 -Wno-address-of-packed-member 
> -Wno-constant-conversion  -Wno-unused-but-set-variable 
> -Wno-gnu-folding-constant  -ffreestanding -fno-pie -mretpoline -O2  -pipe 
> -nostdinc -I/usr/src/sys -I/usr/src/sys/arch/i386/compile/GENERIC/obj 
> -I/usr/src/sys/arch  -I/usr/src/sys/dev/pci/drm/include
> -I/usr/src/sys/dev/pci/drm/include/uapi  -I/usr/src/sys/dev/pci/drm/i915 
> -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBUG 
> -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 
> -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT 
> -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DTCP_ECN 
> -DTCP_SIGNATURE -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX 
> -DMROUTING -DMPLS -DBOOT_CONFIG -DUSER_PCICONF -DAPERTURE -DMTRR -DNTFS 
> -DHIBERNATE -DPCIVERBOSE -DEISAVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL 
> -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS="6" -DX86EMU 
> -DONEWIREVERBOSE -DMAXUSERS=80 -D_KERNEL -MD -MP -MF assym.P > assym.h.tmp
> error: unknown warning option '-Wno-unused-but-set-variable'; did you mean 
> '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-option]
> *** Error 1 in /usr/src/sys/arch/i386/compile/GENERIC (Makefile:1286 
> 'assym.h')
> 
> 
>   Jan
> 
> 
> OpenBSD 7.0-current (GENERIC) #345: Thu Dec 16 13:19:22 MST 2021
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem  = 259207168 (247MB)
> avail mem = 238182400 (227MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 07/19/10, BIOS32 rev. 0 @ 0xfa950
> apm0 at bios0: Power Management spec V1.2 (slowidle)
> pcibios0 at bios0: rev 2.1 @ 0xf/0xdfb4
> pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf30/128 (6 entries)
> pcibios0: PCI Exclusive IRQs: 5 10 11
> pcibios0: no compatible PCI ICU found: ICU vendor 0x1022 product 0x2090
> pcibios0: Warning, unable to fix up PCI interrupt routing
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xc/0x8000 0xc8000/0xa800 0xef000/0x1000!
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 
> 499 MHz, 05-0a-02
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
> mtrr: K6-family MTRR support (2 registers)
> amdmsr0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
> vga1 at pci0 dev 1 function 1 "AMD Geode LX Video" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
> vr0 at pci0 dev 13 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, 
> address 00:0d:b9:0e:9e:f4
> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> 0x004063, model 0x0034
> glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 
> 3579545Hz timer, watchdog, gpio, i2c
> gpio0 at glxpcib0: 32 pins
> iic0 at glxpcib0
> pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 
> wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0: 
> wd0: 1-sector PIO, LBA48, 15279MB, 31293360 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> pciide0: channel 1 ignored (disabled)
> auglx0 at pci0 dev 15 function 3 "AMD CS5536 Audio" rev 0x01: irq 11, CS5536 
> AC97
> ac97: codec id 0x414c4770 (Avance Logic ALC203 rev 0)
> ac97: codec features headphone, 20 bit DAC, 18 bit ADC, No 3D Stereo
> audio0 at auglx0
> ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 5, version 
> 1.0, legacy support
> ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 5
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interf

Re: can't get fonts to show up

[Patrick Harper]

I would read the fonts(7) man page first. Specifically the 'Installing 
fonts in Xft' section.

-- 
  Patrick Harper
  paia...@fastmail.com

On Tue, 30 Nov 2021, at 23:38, Carson Chittom wrote:
> I have purchased some fonts that I like, and I want to use them
> throughout my OpenBSD 7.0 system.  I have both TTF and OTF versions of
> the fonts.
>
> I created a new port in /usr/ports/mystuff/myfonts and copied over the
> Makefile from fonts/ibm-plex to use as a model, edited it *only*
> (AFAICR) to adjust for font names and paths, did the minimum possible to
> actually create a package, and installed it.  That worked fine.
>
> I may have run mkfontscale and mkfontdir manually in each font's
> directory as well; I don't remember. In any case, the fonts are
> available to GTK and Qt.
>
> As part of ~/.xsession, I also have:
>
> if [ -d /usr/local/share/fonts ]; then
>   for i in /usr/local/share/fonts/*; do
> xset fp+ $i
>   done
>   xset fp rehash
> fi
>
> But the fonts still do not show up in xfontsel (unlike, for example, if
> I install fonts/ibm-plex), and I don't seem to be able to use them in
> Fvwm either, even if I copy a font description directly from
> /usr/local/share/fonts/myfonts/fonts.dir
>
> So, I'm guessing either my fonts are missing something, or I'm missing
> something.  I've tried to search and mostly just turned up Arch Linux
> wiki pages telling me to do the things I'd already done with
> mkfontscale, mkfontdir, and xset.  Can anyone point me in the right
> direction?

Re: lm(4) temperature

[Patrick Wildt]

Am Sat, Nov 27, 2021 at 03:35:05PM +0100 schrieb Jan Stary:
> > > This is current/i386 on an ALIX.1E (dmesg below).
> > > I am trying to monitor the CPU temperature with
> > > 
> > > wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x41
> > > lm1 at wbsio0 port 0x290/8: W83627HF
> > > 
> > > $ sysctl hw.sensors.lm1
> > > hw.sensors.lm1.temp0=69.00 degC
> > > hw.sensors.lm1.temp1=57.00 degC
> > > hw.sensors.lm1.temp2=49.00 degC
> > > hw.sensors.lm1.volt0=1.26 VDC (VCore A)
> > > hw.sensors.lm1.volt1=2.64 VDC (VCore B)
> > > hw.sensors.lm1.volt2=3.42 VDC (+3.3V)
> > > hw.sensors.lm1.volt3=5.11 VDC (+5V)
> > > hw.sensors.lm1.volt4=0.00 VDC (+12V)
> > > hw.sensors.lm1.volt5=-14.91 VDC (-12V)
> > > hw.sensors.lm1.volt6=-7.71 VDC (-5V)
> > > hw.sensors.lm1.volt7=5.07 VDC (5VSB)
> > > hw.sensors.lm1.volt8=0.00 VDC (VBAT)
> > > 
> > > There are three temperatures reported,
> > > and dev/ic/lm78var.h talks about Temperature 1, 2, 3;
> > > but man lm(4) only says
> > > 
> > >   Temp uK Motherboard Temperature
> > > 
> > > Does anyone know what exactly they are?
> > 
> > 
> > There is a chip in the machine.
> > It has pins.
> > Those pins are monitored by the driver, as specific registers.
> > 
> > The pins wired to who the hell knows where by each board manufacturer.
> > 
> > Sometimes the chips need special registers and capacitors
> > 
> > Quite often, the board engineer sent to add this part to the board
> > choose the wrong registers and capacitors, and sometimes they compensate
> > for these errors with private tables in the BIOS or various monitoring
> > programs which move around machine to machine.
> > 
> > 
> > We monitor registers.  We assume the vendor did the right thing.
> > 
> > No that I've described what a shitshow it is, I hope you can adjust your
> > expectations.
> 
> OK, with expectations adjusted,
> does anyone know what the three numbers
> are _supposed_ to be?
> 

Yes.  Temperature readings from multiple places on the motherboard.

Re: RTL8852AE wifi driver

[Patrick Harper]

You need to get the authors to change the license to an acceptable one 
first, as GPL won't cut it. https://www.openbsd.org/policy.html

-- 
  Patrick Harper
  paia...@fastmail.com

On Fri, 19 Nov 2021, at 15:24, Moritz Messner wrote:
> Hello,
>
> there seems to be a working driver for this wifi chip which works under
> Linux (https://github.com/lwfinger/rtw89) and I have it in my laptop
> (will probably replace it with a intel ax200/201 so I can use it at school).
>
> How much work would be needed to port the driver to OpenBSD?

Re: Should 80MB of RAM be enough for kernel relinking on i386?

[Patrick Harper]

If the situation isn't going to change anytime soon then I have some 
diffs for INSTALL.i386 and INSTALL.amd64. The latter has not specified 
disk requirements, I guess since anyone who owns an amd64 system will 
very likely be using a disk big enough for X, so I figured that the 
same would apply to any user of an i386 system that meets the proposed 
minimum RAM. These are based on the 2021-09-21 snapshot versions.

--- INSTALL.i386.txtWed Sep 22 16:52:38 2021
+++ INSTALL.i386_newWed Sep 22 16:51:17 2021
@@ -201,10 +201,7 @@ OpenBSD/i386 7.0 supports most SMP (Symmetrical 
MultiP
 systems.  To support SMP operation, a separate SMP kernel (bsd.mp)
 is included with the installation file sets.
 
-The minimal configuration to install the system is 32MB of RAM and
-at least 250MB of disk space to accommodate the `base' set.
-To install the entire system, at least 600MB of disk are required,
-and to run X or compile the system, more RAM is recommended.
+The minimal configuration to install the system is 512MB of RAM.
 
 Please refer to the website for a full list of supported hardware:
 https://www.openbsd.org/i386.html


--- INSTALL.amd64.txt   Wed Sep 22 16:52:48 2021
+++ INSTALL.amd64_new   Wed Sep 22 16:51:12 2021
@@ -202,6 +202,8 @@ is included with the installation file sets.
 OpenBSD/amd64 7.0 supports both UEFI/GPT booting and BIOS/MBR
 booting.
 
+The minimal configuration to install the system is 512MB of RAM.
+
 Please refer to the website for a full list of supported hardware.
 
 https://www.openbsd.org/amd64.html


Patrick Harper

Re: iked choosing the wrong policy?

[Patrick Wildt]

On Tue, Jul 27, 2021 at 09:55:34AM +0200, Claudio Jeker wrote:
> On Tue, Jul 27, 2021 at 07:32:09AM -, Stuart Henderson wrote:
> > On 2021-07-27, Vladimir Nikishkin  wrote:
> > > Hello, everyone.
> > >
> > > This is my iked.conf:
> > >
> > > ```
> > > ikev2 "for-phone" passive esp \
> > > from any to 10.0.3.2/32 \
> > > local egress peer any \
> > ...
> > > dstid phone.mine \
> > 
> > > ikev2 "for-laptop" passive esp \
> > > from any to 10.0.3.3/32 \
> > > local egress peer any \
> > ...
> > > dstid laptop.mine \
> > 
> > Two policies with "peer any" doesn't work.
> > 
> > > How to correct the setup?
> > 
> > Maybe it's possible by modifying the code, I'm not sure if the
> > id is sent early enough though so it might not be possible.
> 
> This is one of the biggest annoyances of iked. It does not even help to
> use different IPs and 'local' to split up the rules. Would love if someone
> would fix this.

Using differnt IPs for local should work.  The trouble is not in iked,
but in the IKEv2 protocol.  The IDs are only shared in the second part
of the handshake.  So until then, there's no way for the daemon to find
the correct policy, apart from looking at local or peer address.

That's why the settings for the IKE-SA should be similar across all
policies thate could be valid, and the Child-SA can then (afaik) have
different settings.

But still, using different IPs for local should work in -current.

Re: Should 80MB of RAM be enough for kernel relinking on i386?

[Patrick Harper]

> Your swap is only 256MB.  That seem too low.  (We have walked away 
> from making it correspond to physical memory, but still, it seems 
> uncomfortably low).
>
> As well, /usr seems a bit large, leaving not much for /home.
>
> The autoallocation scheme might have made a less than perfect 
> decision here.

I tried the same thing except for editing the partition layout to allow 
for 512M of swap:

wd1*> p m
OpenBSD area: 64-15662304; size: 7647.6M; free: 955.0M
#size   offset  fstype [fsize bsize   cpg]
  a:  1060.6M   64  4.2BSD   2048 16384 1 # /
  b:   512.0M  2172128swap
  c:  7647.6M0  unused
  d:  3072.0M  3220704  4.2BSD   2048 16384 1 # /usr
  e:  2048.0M  9512128  4.2BSD   2048 16384 1 # 
/home

and 768M:

wd1*> p m
OpenBSD area: 64-15662304; size: 7647.6M; free: 699.0M
#size   offset  fstype [fsize bsize   cpg]
  a:  1060.6M   64  4.2BSD   2048 16384 1 # /
  b:   768.0M  2172128swap
  c:  7647.6M0  unused
  d:  3072.0M  3744992  4.2BSD   2048 16384 1 # /usr
  e:  2048.0M 10036416  4.2BSD   2048 16384 1 # 
/home

...and there's no practical difference, the system will just sit for 
half an hour, print one or two seg faults in that time and then reboot. 
memtest86 didn't print any errors so I'm assuming my memory is fine. 
I'd say x86 computers without INT 13h Extensions support in the BIOS 
are pretty much obsolete at this point given that nearly all of them 
are going to be a combo of very small memory (>128MB was very rare 
before 1998) and small disk (8.4GB limit).

Should 80MB of RAM be enough for kernel relinking on i386?

[Patrick Harper]

Hi All,

The installation program on my Intel P5/80MB RAM machine works fine up 
to 'Relinking to create unique kernel...', during which the system 
either reboots or eventually prints a kernel panic message. If 80MB is 
not enough under normal circumstances then it's not worth debugging. 
Apparently 64MB was enough for 6.7 
(https://www.uninformativ.de/blog/postings/2020-06-21/0/POSTING-en.html)
 but that was then, e.t.c.

paianni$ doas cu
Connected to /dev/cua00 (speed 9600)
>> OpenBSD/i386 BOOT 3.44
boot> machine mem
Region 0: type 1 at 0x0 for 639KB
Region 1: type 1 at 0x10 for 80896KB
Low ram: 639KB  High ram: 15360KB
Total free memory: 81535KB
boot> wd0a:/bsd.rd
boot> boot wd0a:/bsd.rd
cannot open wd0a:/etc/random.seed: No such file or directory
booting wd0a:/bsd.rd: 3213847+1405952+3358728+0+421888 
[88+160+28]=0x805300
entry point at 0x201000

Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights 
reserved.
Copyright (c) 1995-2021 OpenBSD. All rights reserved.  
https://www.OpenBSD.org

OpenBSD 6.9 (RAMDISK_CD) #768: Sat Apr 17 22:27:31 MDT 2021
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
real mem  = 83423232 (79MB)
avail mem = 7228 (69MB)
random: good seed from bootblocks
mainbus0 at root
bios0 at mainbus0: date 11/15/96
pcibios at bios0 function 0x1a not configured
bios0: ROM list: 0xc/0xc000 0xef000/0x1000!
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 134 MHz, 05-02-0c
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,MELTDOWN
cpu0: F00F bug workaround installed
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Opti 82C557 Host" rev 0x00
pcib0 at pci0 dev 1 function 0 "Opti 82C558 ISA" rev 0x00
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD7543" rev 0x00
vga1: aperture needed
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
isa0 at pcib0
isadma0 at isa0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
wdc0 at isa0 port 0x1f0/8 irq 14
wd0 at wdc0 channel 0 drive 0: 
wd0: 1-sector PIO, LBA48, 7647MB, 15662304 sectors
wd0(wdc0:0:0): using BIOS timings
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
pcic0 at isa0 port 0x3e0/2 iomem 0xd/16384
pcic0 controller 0:  has sockets A and B
pcmcia0 at pcic0 controller 0 socket 0
wdc2 at pcmcia0 function 0 "TRANSCEND, TS8GCF133, " port 0x340/16: irq 3
wd1 at wdc2 channel 0 drive 0: 
wd1: 1-sector PIO, LBA48, 7647MB, 15662304 sectors
wd1(wdc2:0:0): using BIOS timings
pcmcia1 at pcic0 controller 0 socket 1
ne3 at pcmcia1 function 0 "D-Link, DE-660, 118B6603" port 0x300/32, irq 
9, address 00:80:c8:8b:ec:8e
pcic0: irq 10, polling enabled
softraid0 at root
scsibus0 at softraid0: 256 targets
root on rd0a swap on rd0b dump on rd0b
WARNING: CHECK AND RESET THE DATE!
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
erase ^?, werase ^W, kill ^U, intr ^C, status ^T

Welcome to the OpenBSD/i386 6.9 installation program.
WARNING: /mnt was not properly unmounted
(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? i
At any prompt except password prompts you can escape to a shell by
typing '!'. Default answers are shown in []'s and are selected by
pressing RETURN.  You can exit this program at any time by pressing
Control-C, but this can leave your system in an inconsistent state.

Terminal type? [vt220] 
System hostname? (short form, e.g. 'foo') paipaq

Available network interfaces are: ne3 vlan0.
Which network interface do you wish to configure? (or 'done') [ne3] 
IPv4 address for ne3? (or 'dhcp' or 'none') [dhcp] 
ne3: no lease..sleeping
IPv6 address for ne3? (or 'autoconf' or 'none') [none] 
Available network interfaces are: ne3 vlan0.
Which network interface do you wish to configure? (or 'done') [done] 
DNS domain name? (e.g. 'example.com') [my.domain] home
DNS nameservers? (IP address list or 'none') [none] 

Password for root account? (will not echo) 
Password for root account? (again) 
Start sshd(8) by default? [yes] 
Do you expect to run the X Window System? [yes] no
Change the default console to com0? [yes] no
Setup a user? (enter a lower-case loginname, or 'no') [no] paianni
Full name for user paianni? [paianni] Patrick Harper
Password for user paianni? (will not echo) 
Password for user paianni? (again) 
WARNING: root is targeted by password guessing attacks, pubkeys are 
safer.
Allow root ssh login? (yes, no, prohibit-password) [no] 

Available disks are: wd0 wd1.
Which disk is the root disk? ('?' for details) [wd0] wd1
Disk: wd1   geometry: 15538/16/63 [15662304 Sectors]
Offset: 0   Signature: 0xAA55
Starting Ending 

Re: pflow on PE router

[Patrick Dohman]

Perhaps it has something to do with Citrix being a dinosaur.
God forbid the powers that be choose on premise unix.
Regards
Patrick

> On Jun 4, 2021, at 6:43 AM, Stuart Henderson  wrote:
> 
> On 2021/06/03 15:04, Chris Cappuccio wrote:
>> Stuart Henderson [s...@spacehopper.org] wrote:
>>> 
>>> Oh watch out with sloppy. Keep an eye on your state table size.
>> 
>> Really? Wouldn't sloppy keep the state table smaller if anything since it's 
>> tracking less specifically?
>> 
>> Anyways I use sloppy across four boxes that run in parallel with pfsync. 
>> There could easily be 10,000 devices behind it at any given time. I keep my 
>> state table limit at 1,000,000. It's around 300,000 during this lighter 
>> traffic period today. I had to do sloppy after moving to several boxes in 
>> parallel, I didn't notice sloppy making any significant difference?
>> 
>> Chris
> 
> The problem I had was in conjunction with synfloods. I didn't get
> captures for everything to figure it out (it was in 2018 and my
> network was in flames, with the full state table bgp sessions were
> getting dropped / not reestablishing) but I think what happened was
> this,
> 
> spoofed SYN to real server behind PF
> SYN+ACK from server
> 
> and the state entry ended up as ESTABLISHED:ESTABLISHED where it
> remained until the tcp.established timer expired (24h default
> or 5h with "set optimization aggressive").
> 
> My "fix" was to move as much as possible to "pass XX flags any no state"
> but that's clearly not going to help with what Denis would like to do.
> (fwiw - I'm not doing flow monitoring regularly, but when I do it's
> usually via sflow on switches instead, which solves some problems,
> though it's only possible in some situations).
> 

Re: pflow on PE router

[Patrick Dohman]

I suspect that you’ll be out of luck until TLSv1.3 is implemented. 
I’ve found the same to be true with the new 10 gb sfp switches in our 
infrastructure which surprisingly still implement TLSv1.0 & broken CGI web 
server.
Regards
Patrick

> On Jun 1, 2021, at 3:44 PM, Stuart Henderson  wrote:
> 
> On 2021-05-30, Denis Fondras  wrote:
>> Le Fri, May 28, 2021 at 03:30:58PM -0700, Chris Cappuccio a écrit :
>>> You might try "set state-defaults pflow, sloppy", also in some scenarios 
>>> you 
>>> might need "set state-policy floating"
>>> 
>>> If "sloppy" fixes it, there may be some bugs to hunt.
>>> 
>> 
>> "sloppy" seems to fix the issue. I will do more tests this week before 
>> declaring
>> victory :)
>> 
>> Thank you Chris.
>> 
>> 
> 
> Oh watch out with sloppy. Keep an eye on your state table size.
> 

Re: pflow on PE router

[Patrick Dohman]

> "sloppy" seems to fix the issue. I will do more tests this week before 
> declaring
> victory :)
> 
> Thank you Chris.
> 

Get somme ;)
Regards
Patrick

Re: spamd IPv6 listener 6.9amd64

[Patrick Wildt]

Am Wed, May 12, 2021 at 09:46:28AM -0400 schrieb Aisha Tammy:
> afaik spamd(8) does not support ipv6 (yet).
> I also do not know if there is any ongoing effort for ipv6 to be added.
> 
> On 5/12/21 9:24 AM, Martin wrote:
> > Hi list,
> > 
> > I can't find in spamd(8) how to enable IPv6 listener in addition to IPv4 
> > one.
> > 
> > Is it possible to set spamd(8) to listen on both IPv4 and IPv6?
> > 
> > Martin
> > 

I'm using rspamd, that's a pretty good application.

Re: Q: dmesg: dt: 443 probes

[Patrick Wildt]

Am Tue, May 04, 2021 at 03:38:14PM - schrieb Stuart Henderson:
> On 2021-05-04, Why 42? The lists account.  wrote:
> >
> > On Mon, May 03, 2021 at 12:59:27AM +0200, Patrick Wildt wrote:
> >> > ...
> >> > But when I do (as root): "sysctl kern.allowdt=1" it returns this error:
> >> > sysctl: kern.allowdt: Operation not permitted
> >> 
> >> Similarly to kern.allowkmem, you can only set it when the securelevel is
> >> still 'low'.  That's for security.  You need to add kern.allowdt=1 to
> >> sysctl.conf, and then reboot.  Then it'll be enabled after reboot.
> >
> > Thanks Patrick! After the reboot I was able to experiment with btrace.
> >
> > Do you use it, do you have any examples that might help to get started?
> 
> Here's one example:
> https://marc.info/?l=openbsd-bugs=158583371404603=2

That's exactly the one I use.  Though with varying hz (1-60)

Re: Q: dmesg: dt: 443 probes

[Patrick Wildt]

Am Sun, May 02, 2021 at 11:49:10PM +0200 schrieb Why 42? The lists account.:
> 
> Actually I do notice one thing, having just upgraded to:
> kern.version=OpenBSD 6.9-current (GENERIC.MP) #492: Sat May  1 17:37:28 MDT 
> 2021
> 
> I checked the output from dmesg and I have a new boot time message:
> dt: 443 probes
> 
> man dt tells me that dt is dynamic tracing and that I can enable it by
> setting kern.allowdt.
> 
> But when I do (as root): "sysctl kern.allowdt=1" it returns this error:
> sysctl: kern.allowdt: Operation not permitted

Similarly to kern.allowkmem, you can only set it when the securelevel is
still 'low'.  That's for security.  You need to add kern.allowdt=1 to
sysctl.conf, and then reboot.  Then it'll be enabled after reboot.

> What am I missing?
> 
> Cheers,
> Robb.
> 
> FYI: This is on an Intel NUC:
> bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x7a9a4000 (77 entries)
> bios0: vendor Intel Corp. version "BECFL357.86A.0087.2020.1209.1115" date 
> 12/09/2020
> bios0: Intel(R) Client Systems NUC8i5BEH
> 

Re: gl.inet Brume (GL-MV1000): sdcard works with 6.8 but not -current

[Patrick Wildt]

Am Sun, Apr 04, 2021 at 11:32:10PM +0200 schrieb Mark Kettenis:
> > From: Darren Tucker 
> > Date: Sun, 4 Apr 2021 09:18:30 +1000
> > 
> > On Sun, 4 Apr 2021 at 01:32, Patrick Wildt  wrote:
> > 
> >  [...]
> >  Maybe you both can try my revert and make sure it doesn't introduce any
> >  other regressions?
> > 
> > That also seems to work on the Brume in question:
> 
> Works for the Turris MOX as well.
> 
> Do you want to commit the revert Darren?

Just committed it myself.  Sorry for the regression.

Re: gl.inet Brume (GL-MV1000): sdcard works with 6.8 but not -current

[Patrick Wildt]

Am Fri, Apr 02, 2021 at 12:56:24PM +1100 schrieb Darren Tucker:
> On Fri, Apr 02, 2021 at 01:01:30AM +0200, Mark Kettenis wrote:
> > Hi Darren,
> > 
> > This got broken when Patrick fixed something related to slow mode for
> > the Marvel ARMADA 8040 SoC.  The diff below fixes it for me on my
> > Turris MOX which uses the same SoC.  Not entirely sure what is going
> > wrong here since looking at the Linux code suggests that Patrick's fix
> > should work on the ARMADA 3720 as well.
> 
> Confirmed that this fixes it.  dmesg at end of mail.

Damn.  I'm sorry, it wasn't my intention to break anything with that.
As far as I remember, that particular change was an attempt to reduce
diff.  This one wasn't even needed to fix my ClearFog GT8K.

By the way, U-Boot always sets slow mode for legacy and high speed,
which is similar to what we had before.

I would actually propose reverting my change completely.  My GT 8K still
works, but even better: it seems to make the SD card show up on my early
revision MacchiatoBin.

-sdmmc1: can't enable card
 scsibus2 at sdmmc0: 2 targets, initiator 0
 sd1 at scsibus2 targ 1 lun 0:  removable
 sd1: 7456MB, 512 bytes/sector, 15269888 sectors
+scsibus3 at sdmmc1: 2 targets, initiator 0
+sd2 at scsibus3 targ 1 lun 0:  removable
+sd2: 7632MB, 512 bytes/sector, 15630336 sectors

Maybe you both can try my revert and make sure it doesn't introduce any
other regressions?

> > That BRUME thingy looks cute, but has a bit of an issue.  It doesn't
> > really have three Ethernet ports.  Instead those ports are part of a
> > switch that also connects to an Ethernet interface on the SoC.
> 
> Yeah I noticed that.  Single ethernet plus programmable switch seems to
> be pretty common in this class of device.

And if someone wants to program it, feel free to, mvsw(4) exists for a
reason, might just need some code. :)

diff --git a/sys/dev/fdt/sdhc_fdt.c b/sys/dev/fdt/sdhc_fdt.c
index 56bf15c46fa..cc0239df682 100644
--- a/sys/dev/fdt/sdhc_fdt.c
+++ b/sys/dev/fdt/sdhc_fdt.c
@@ -430,8 +430,8 @@ phy_init:
XENON_EMMC_PHY_TIMING_ADJUST);
reg |= XENON_EMMC_PHY_TIMING_ADJUST_SAMPL_INV_QSP_PHASE_SELECT;
reg &= ~XENON_EMMC_PHY_TIMING_ADJUST_SLOW_MODE;
-   if ((timing == SDMMC_TIMING_LEGACY ||
-   timing == SDMMC_TIMING_HIGHSPEED) && sc->sc_slow_mode)
+   if (timing == SDMMC_TIMING_LEGACY ||
+   timing == SDMMC_TIMING_HIGHSPEED || sc->sc_slow_mode)
reg |= XENON_EMMC_PHY_TIMING_ADJUST_SLOW_MODE;
bus_space_write_4(sc->sc_iot, sc->sc_ioh,
XENON_EMMC_PHY_TIMING_ADJUST, reg);

Re: IKEv2 on Windows 10

[Patrick Wildt]

Am Wed, Jan 13, 2021 at 01:12:09AM -0700 schrieb Ian Timothy:
> Hi,
> 
> I'm trying to get IKEv2 VPN working with Windows 10. I'm able to use PSK with 
> macOS without issue. Changing to EAP MSCHAP for use with Windows results in 
> the following error:
> 
> "The network connection between your computer and the VPN server could not be 
> established because the remote server is not responding. The could be because 
> one of the network devices (e.g. firewalls, NAT, routers, etc.) between your 
> computer and the remote server is not configured to allow VPN connections."
> 
> I’ve worked through many examples online, but I’m not sure what's the next 
> step to troubleshoot this?
> 
> Thanks!
> 
> 
> 
> # uname -rsv
> OpenBSD 6.8 GENERIC.MP#2
> 
> 
> #
> # iked.conf
> #
> 
> ikev2 "vpn-psk" passive esp \
>   from 0.0.0.0/0 to 0.0.0.0/0 \

Hi,

if you're using config address (as in giving peers a tunnel IP), you
need to configure

from 0.0.0.0/0 to 0.0.0.0 \

The "to" becomes a /32, a /0 is wrong.  This is because of internal
semantics.  Anyway, this confusing bit has been changed in -current,
as you can read here:

https://www.openbsd.org/faq/current.html

But unless you're using current, you still need the line above.

But since you're complaining about EAP MSCHAP, I don't know what's the
issue there.  Maybe tobhe@ or sthen@ have an idea.

Patrick

>   local egress peer any \
>   srcid vpn.company.com \
>   eap "mschap-v2" \
>   config address 10.0.2.0/24 \
>   config netmask 255.255.0.0 \
>   config name-server 10.0.0.1 \
>   tag "$name-$id" 
> 
> # Changing 'eap "mschap-v2"' to 'psk "password"' works just fine for macOS.
> 
> 
> #
> # Generate certificates
> #
> 
> pkg_add zip
> 
> ikectl ca vpn create
> ikectl ca vpn install
> 
> # CN should be same as srcid in iked.conf
> ikectl ca vpn certificate vpn.company.com create
> ikectl ca vpn certificate vpn.company.com install
> 
> # CN should be same as client ip address
> ikectl ca vpn certificate 10.0.2.100 create
> ikectl ca vpn certificate 10.0.2.100 export
> 
> 
> #
> # Windows config
> #
> 
> - VPN device
>- General tab
>   - Server: vpn.company.com
>- Security tab
>   - VPN type: IKEv2
>   - Authentication: Use machine certificates
> 
> - Certs install
>- ca.crt --> Certificates (Local Computer)/Trusted Root Certification 
> Authorities/Certificates
>- 10.0.2.100 --> Certificates (Local Computer)/Personal/Certificates
> 
> 
> #
> # iked log
> #
> 
> doas iked -dvv
> create_ike: using signature for peer 
> ikev2 "vpn-eap" passive tunnel esp inet from 0.0.0.0/0 to 0.0.0.0/0 local 
> 23.AAA.AAA.129 peer any ikesa enc aes-128-gcm,aes-256-gcm prf 
> hmac-sha2-256,hmac-sha2-384,hmac-sha2-512,hmac-sha1 group 
> curve25519,ecp521,ecp384,ecp256,modp4096,modp3072,modp2048,modp1536,modp1024 
> ikesa enc aes-256,aes-192,aes-128,3des prf 
> hmac-sha2-256,hmac-sha2-384,hmac-sha2-512,hmac-sha1 auth 
> hmac-sha2-256,hmac-sha2-384,hmac-sha2-512,hmac-sha1 group 
> curve25519,ecp521,ecp384,ecp256,modp4096,modp3072,modp2048,modp1536,modp1024 
> childsa enc aes-128-gcm,aes-256-gcm esn,noesn childsa enc 
> aes-256,aes-192,aes-128 auth 
> hmac-sha2-256,hmac-sha2-384,hmac-sha2-512,hmac-sha1 esn,noesn srcid 
> vpn.ipaperbox.com lifetime 10800 bytes 536870912 eap "MSCHAP_V2" config 
> address 10.0.2.0 config netmask 255.255.0.0 config name-server 10.0.0.1
> /etc/iked.conf: loaded 2 configuration rules
> ca_privkey_serialize: type RSA_KEY length 1192
> ca_pubkey_serialize: type RSA_KEY length 270
> config_new_user: inserting new user windows
> user "windows" "password"
> config_getpolicy: received policy
> ca_privkey_to_method: type RSA_KEY method RSA_SIG
> config_getpfkey: received pfkey fd 3
> ca_getkey: received private key type RSA_KEY length 1192
> config_getcompile: compilation done
> config_getsocket: received socket fd 4
> config_getsocket: received socket fd 5
> config_getsocket: received socket fd 6
> config_getsocket: received socket fd 7
> config_getstatic: dpd_check_interval 60
> config_getstatic: no enforcesingleikesa
> config_getstatic: no fragmentation
> config_getstatic: mobike
> config_getstatic: nattport 4500
> ca_getkey: received public key type RSA_KEY length 270
> ca_dispatch_parent: config reset
> ca_reload: loaded ca file ca.crt
> ca_reload: loaded crl file ca.crl
> ca_reload: /C=US/ST=State/L=City/O=Company Name/OU=Information 
> Systems/CN=vpn.company.com/emailAddress=t...@company.com
> ca_reload: loaded 1 ca certificate
>

Buying a New Laptop

[Coppock, Patrick H]

Hi,

I'm thinking about getting a new laptop, and I want to get something with good 
OpenBSD support. I know ThinkPads have had good support historically, and I'm 
wondering if that holds for recent machines. In particular, I've been eyeing 
the L13. Does anyone have a similar machine running OpenBSD that could comment 
on the hardware support?

Thanks,
Patrick

Buying a New Laptop

[Coppock, Patrick H]

Hi,

I'm thinking about getting a new laptop, and I want to get something with good 
OpenBSD support. I know ThinkPads have had good support historically, and I'm 
wondering if that holds for recent machines. In particular, I've been eyeing 
the L13. Does anyone have a similar machine running OpenBSD that could comment 
on the hardware support?

Thanks,
Patrick

Re: 4G mini PCI-e modem support?

[Patrick Wildt]

Am Fri, Jan 08, 2021 at 02:29:02PM + schrieb Peter Kay:
> There appear to be no 4G modem support at the moment, specifically a
> mini PCI-e one so I can stick it in a PC engines apu4d4 and have a
> backup connection.
> 
> Presuming a driver would need to be written, but just checking if I've
> missed anything?

There's umb(4).  It supports USB's MBIM standard.  There are some MBIM
compatible chips around, one for instance is this one:

https://www.varia-store.com/de/produkt/87272-simcom-sim7600e-h-mpcie-eu-lte-cat-4-modul.html

You'll probably need to switch it into MBIM mode once via a specific
AT-command over the serial, but otherwise it should do.

I'm sure there are plenty of other MBIM-compatible devices, this is just
the one from the top of my head.

Re: M2 SSD in a PCI-E adapter

[Patrick Wildt]

Am Fri, Jan 08, 2021 at 08:46:20AM -0700 schrieb Todd C. Miller:
> On Fri, 08 Jan 2021 16:19:02 +0100, Jan Stary wrote:
> 
> > I know the disk itself works: this is the disk plugged into
> > an M.2 slot in a Dell Latitude E5570 (full dmesg below):
> > sd0 at scsibus1 targ 0 lun 0:  
> > naa.5001b448b85325
> > 30
> > sd0: 238475MB, 512 bytes/sector, 488397168 sectors, thin
> 
> That is not an NVME SSD, it is an M.2 SATA SSD.  You need a different
> adaptor.
> 
>  - todd
> 

Yes, todd is right.  It's a M2 SATA SSD, but the Adapter will only
work with M2 NVMe SSDs.  So you might need a different adapter.  Some-
thing like these two could maybe work:

https://www.delock.de/produkte/1140_M-2/89388/merkmale.html
https://www.delock.de/produkte/1140_M-2/89379/merkmale.html

Both say "supports Key B+M on SATA basis" and both have active chipsets
which should be PCIe AHCI-compatible controller.

Re: -current amd64 packages not updated? Impatient or broken?

[Patrick Wildt]

Oh, and another correction: it's libc++ 10.0.1, we're not going 11 yet.

Am Thu, Jan 07, 2021 at 06:59:52PM +0100 schrieb Patrick Wildt:
> No, that's not correct.  The libc++ 11 (*not* LLVM 11) has not yet been
> committed.  This issue is because of libunwind 11.  With libc++ 11 we
> have made a separate ports build first, to check the fallout.  Once the
> fallout is mostly fixed, we'll do the switch to libc++ 11.  Until then
> snapshots are not harmed in anyway, apart from the libunwind update.
> 
> Am Thu, Jan 07, 2021 at 11:56:07AM -0600 schrieb Amit Kulkarni:
> > Like naddy@ mentioned on ports@ they are trying to figure out the
> > fallout from the switch to LLVM 11 as system compiler. This is why the
> > packages are being delayed. Please wait a while till it is sorted out.
> > 
> > thanks
> > 
> > On Thu, Jan 7, 2021 at 10:56 AM Steve Williams
> >  wrote:
> > >
> > > Hi,
> > >
> > > I hesitate to send this because perhaps I'm just too impatient, but then
> > > again, perhaps not.  This is not critical/time sensitive.
> > >
> > > I just thought I'd check if there a problem with the current packages
> > > folder from the mirrors?
> > >
> > > I am trying to update my development system (to resume work on a port).
> > >
> > > I did the initial upgrade on January 4, 2020 and my packages wouldn't
> > > update because of missing library versions.  I was told this is just a
> > > discrepancy between the OS and the packages and to "wait a few days" for
> > > everything to synchronize.
> > >  "Unfortunate timing as key system libraries have had version bumps
> > > recently. Wait for a new package build (usually a few days on the faster
> > > cpu architectures) and try again."
> > >
> > > I am watching the packages folder on various mirrors and they are all
> > > from January 3, 2020, which is when my kernel is from.
> > > pulseaudio-14.0.tgz03-Jan-2021
> > >
> > > I am currently on:
> > > OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan  3 15:25:58 MST 2021
> > >
> > > This morning, I still can't add/update select packages.
> > >
> > > desktop# sysupgrade -s
> > > Fetching from
> > > https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/
> > > SHA256.sig   100%
> > > |***|
> > > 2144   00:00
> > > Signature Verified
> > > Already on latest snapshot.
> > > desktop# pkg_add pulseaudio
> > > quirks-3.506 signed on 2021-01-03T15:41:44Z
> > > Can't install spidermonkey78-78.5.0v1 because of libraries
> > > |library c++.5.0 not found
> > > | /usr/lib/libc++.so.4.0 (system): bad major
> > > | /usr/lib/libc++.so.6.0 (system): bad major
> > > |library c++abi.3.0 not found
> > > | /usr/lib/libc++abi.so.2.1 (system): bad major
> > > | /usr/lib/libc++abi.so.4.0 (system): bad major
> > > Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3
> > > nspr-4.29 icu4c-68.2v0
> > > Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0
> > > Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1
> > > Can't install consolekit2-1.2.2: can't resolve polkit-0.118
> > > Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2
> > > Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0
> > > spidermonkey78-78.5.0v1
> > > desktop#
> > >
> > > Am I being too impatient?
> > >
> > > Thanks,
> > > Steve Williams
> > >
> > >
> > >
> > 
> 

Re: -current amd64 packages not updated? Impatient or broken?

[Patrick Wildt]

No, that's not correct.  The libc++ 11 (*not* LLVM 11) has not yet been
committed.  This issue is because of libunwind 11.  With libc++ 11 we
have made a separate ports build first, to check the fallout.  Once the
fallout is mostly fixed, we'll do the switch to libc++ 11.  Until then
snapshots are not harmed in anyway, apart from the libunwind update.

Am Thu, Jan 07, 2021 at 11:56:07AM -0600 schrieb Amit Kulkarni:
> Like naddy@ mentioned on ports@ they are trying to figure out the
> fallout from the switch to LLVM 11 as system compiler. This is why the
> packages are being delayed. Please wait a while till it is sorted out.
> 
> thanks
> 
> On Thu, Jan 7, 2021 at 10:56 AM Steve Williams
>  wrote:
> >
> > Hi,
> >
> > I hesitate to send this because perhaps I'm just too impatient, but then
> > again, perhaps not.  This is not critical/time sensitive.
> >
> > I just thought I'd check if there a problem with the current packages
> > folder from the mirrors?
> >
> > I am trying to update my development system (to resume work on a port).
> >
> > I did the initial upgrade on January 4, 2020 and my packages wouldn't
> > update because of missing library versions.  I was told this is just a
> > discrepancy between the OS and the packages and to "wait a few days" for
> > everything to synchronize.
> >  "Unfortunate timing as key system libraries have had version bumps
> > recently. Wait for a new package build (usually a few days on the faster
> > cpu architectures) and try again."
> >
> > I am watching the packages folder on various mirrors and they are all
> > from January 3, 2020, which is when my kernel is from.
> > pulseaudio-14.0.tgz03-Jan-2021
> >
> > I am currently on:
> > OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan  3 15:25:58 MST 2021
> >
> > This morning, I still can't add/update select packages.
> >
> > desktop# sysupgrade -s
> > Fetching from
> > https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/
> > SHA256.sig   100%
> > |***|
> > 2144   00:00
> > Signature Verified
> > Already on latest snapshot.
> > desktop# pkg_add pulseaudio
> > quirks-3.506 signed on 2021-01-03T15:41:44Z
> > Can't install spidermonkey78-78.5.0v1 because of libraries
> > |library c++.5.0 not found
> > | /usr/lib/libc++.so.4.0 (system): bad major
> > | /usr/lib/libc++.so.6.0 (system): bad major
> > |library c++abi.3.0 not found
> > | /usr/lib/libc++abi.so.2.1 (system): bad major
> > | /usr/lib/libc++abi.so.4.0 (system): bad major
> > Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3
> > nspr-4.29 icu4c-68.2v0
> > Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0
> > Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1
> > Can't install consolekit2-1.2.2: can't resolve polkit-0.118
> > Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2
> > Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0
> > spidermonkey78-78.5.0v1
> > desktop#
> >
> > Am I being too impatient?
> >
> > Thanks,
> > Steve Williams
> >
> >
> >
> 

Re: -current amd64 packages not updated? Impatient or broken?

[Patrick Wildt]

I committed an update to libunwind which made a major bump necessary.
Maybe I should have asked ports to run with the build first, so that
base and packages would be aligned.  Too late for that now.  Time will
fix it though.

Am Thu, Jan 07, 2021 at 09:54:39AM -0700 schrieb Steve Williams:
> Hi,
> 
> I hesitate to send this because perhaps I'm just too impatient, but then
> again, perhaps not.  This is not critical/time sensitive.
> 
> I just thought I'd check if there a problem with the current packages folder
> from the mirrors?
> 
> I am trying to update my development system (to resume work on a port).
> 
> I did the initial upgrade on January 4, 2020 and my packages wouldn't update
> because of missing library versions.  I was told this is just a discrepancy
> between the OS and the packages and to "wait a few days" for everything to
> synchronize.
>     "Unfortunate timing as key system libraries have had version bumps
> recently. Wait for a new package build (usually a few days on the faster cpu
> architectures) and try again."
> 
> I am watching the packages folder on various mirrors and they are all from
> January 3, 2020, which is when my kernel is from.
> pulseaudio-14.0.tgz    03-Jan-2021
> 
> I am currently on:
> OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan  3 15:25:58 MST 2021
> 
> This morning, I still can't add/update select packages.
> 
> desktop# sysupgrade -s
> Fetching from
> https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/
> SHA256.sig   100% 
> |***|
> 2144   00:00
> Signature Verified
> Already on latest snapshot.
> desktop# pkg_add pulseaudio
> quirks-3.506 signed on 2021-01-03T15:41:44Z
> Can't install spidermonkey78-78.5.0v1 because of libraries
> |library c++.5.0 not found
> | /usr/lib/libc++.so.4.0 (system): bad major
> | /usr/lib/libc++.so.6.0 (system): bad major
> |library c++abi.3.0 not found
> | /usr/lib/libc++abi.so.2.1 (system): bad major
> | /usr/lib/libc++abi.so.4.0 (system): bad major
> Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3
> nspr-4.29 icu4c-68.2v0
> Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0
> Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1
> Can't install consolekit2-1.2.2: can't resolve polkit-0.118
> Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2
> Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0
> spidermonkey78-78.5.0v1
> desktop#
> 
> Am I being too impatient?
> 
> Thanks,
> Steve Williams
> 
> 
> 

Re: clock not set on boot

[Patrick Wildt]

On Sat, Dec 05, 2020 at 09:10:19PM +, Maurice McCarthy wrote:
> Perhaps add
> 
> ntpd_flags="-s"
> 
> to /etc/rc.conf.local
> 

-s doesn't exist anymore.

Re: PayPal pool for developer M1 Mac mini for OpenBSD port

[Patrick Wildt]

This really has shown how much interest there is in having OpenBSD
running on those machines.  Still, we would all not be here without
the OpenBSD project itself.  Not being able to host hackathons due to
COVID-19 leaves an impact, and I hope that soon(TM) we'll be able to
get back together to shut up and hack.

I'm sure you all love using OpenBSD and hacking on OpenBSD as much as I
do, so to help OpenBSD run infrastructure, organize hackathons and to
flourish even more, please consider donating!

https://www.openbsdfoundation.org/donations.html
https://www.openbsd.org/donations.html

Also a shoutout to marcan, who'll be doing a lot of reverse engineering
on the M1.  He's pretty good, and I'm supporting his project by being a
patron.  I'm looking forward to his work, because of all the people out
there who can do it, he's definitely one of them.

https://www.patreon.com/marcan

Patrick

Am Thu, Dec 03, 2020 at 02:33:34PM -0700 schrieb Ben Goren:
> Oh, wow — it hasn’t even been a full day since I sent this out...and already 
> enough of you have chipped in enough to buy not just a single M1 system for 
> Patrick, but also a second one for his partner in crime, Mark Kettenis.
> 
> Thank you to all! This show of generosity and support and excitement is most 
> welcome. (And, frankly, a bit overwhelming.)
> 
> If anybody reading this still wishes to donate to the cause, despite the 
> immediate needs being met, the money will be put to good use. There are other 
> developers who will eventually need their own hardware, and there are always 
> other sorts of expenses related to development. Feel free to chip in at 
> Patrick’s original link:
> 
> https://www.paypal.com/pools/c/8uPSkfNJMp
> 
> ...or, of course, to the OpenBSD general fund (which can *ALWAYS* use 
> donations):
> 
> https://www.openbsd.org/donations.html
> 
> Thanks again, everybody!
> 
> b&
> 
> > On Dec 2, 2020, at 2:59 PM, Ben Goren  wrote:
> > Greetings, all!
> > 
> > Patrick Wildt has set up a PayPal pool to raise funds to purchase an M1 Mac 
> > mini so he can start porting OpenBSD to the platform. If you’d like to be 
> > able to run OpenBSD on an M1 system, now would be a great time to throw 
> > some pennies his way.
> > 
> > The donation link: https://paypal.me/pools/c/8uPSkfNJMp
> > 
> > Read below for an idea of what one might expect if we can get a machine 
> > into Patrick’s hands.
> > 
> > Cheers,
> > 
> > b&
> > 
> > Patrick wrote:
> > 
> >> Yes, kettenis@ and me are the two ones doing the major work on porting
> >> to new devices.  Not sure if kettenis@ is interested, but I can ask him.
> >> I definitely am, a Mac Mini as a dedicated machine to do stuff with and
> >> not care about what is installed would really help.
> >> 
> >> Marcan has started a crowdfunding on Patreon.  He's a really capable
> >> person, and he'll definitely lay a lot of groundwork needed for porting
> >> OpenBSD to the platform.  He apparenetly will also do his work in a
> >> dual-licensed fashion, so the BSDs will easily profit from it.
> >> 
> >> So, the first steps are basically to follow Marcan's work and use all
> >> that information and code to port OpenBSD as well.
> >> 
> >> This *will* take some time, because essentially there are only the
> >> binary drivers, but it's doable and I think with a bit of patience
> >> we will have OpenBSD running on the M1 as well.
> >> 
> >> Biggest hurdle, as always, will be support for graphics acceleration.

Re: Snapshot crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)

[Patrick Wildt]

On Sun, Nov 08, 2020 at 06:30:25PM +0400, Michel von Behr wrote:
> Upgrading to snapshot did the trick - thanks for the great work!
> 
> FWIW, I still see a quick message "entry point at: ..." just blinking, but
> the system boots normally. There are a few devices not identified, most
> importantly the Touchpad (i.e., HTIX5288). Below is dmesg:

That message is *not* an error message.  It simply tells you where to
which address the bootloader will now jump.  I'd be concerned if it
didn't show up. ;)

> OpenBSD 6.8-current (GENERIC.MP ) #164: Thu Nov  5
> 15:11:03 MST 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> real mem = 8388608000 (8000MB)
> avail mem = 8119074816 (7742MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7a01f000 (78 entries)
> bios0: vendor American Megatrends Inc. version "E.G140J.D8.E1.016.bin" date
> 11/29/2019
> bios0: Default string LapBook Pro
> acpi0 at bios0: ACPI 6.1
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP FPDT FIDT MSDM MCFG HPET LPIT APIC NPKT SSDT SSDT
> SSDT SSDT SSDT SSDT SSDT SSDT SSDT UEFI TPM2 DBGP DBG2 WDAT WSMT
> acpi0: wakeup devices LID0(S3) HDAS(S3) XHC_(S3) XDCI(S4) RP01(S4) PXSX(S4)
> RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4)
> RP06(S4) PXSX(S4)
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 1920 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) N4100 CPU @ 1.10GHz, 1097.34 MHz, 06-7a-01
> 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,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu0: 4MB 64b/line 16-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 19MHz
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Celeron(R) N4100 CPU @ 1.10GHz, 1096.97 MHz, 06-7a-01
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu1: 4MB 64b/line 16-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Celeron(R) N4100 CPU @ 1.10GHz, 1096.97 MHz, 06-7a-01
> cpu2:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu2: 4MB 64b/line 16-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Celeron(R) N4100 CPU @ 1.10GHz, 1096.97 MHz, 06-7a-01
> cpu3:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu3: 4MB 64b/line 16-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (RP01)
> acpiprt2 at acpi0: bus -1 (RP02)
> acpiprt3 at acpi0: bus 1 (RP03)
> acpiprt4 at acpi0: bus -1 (RP04)
> acpiprt5 at acpi0: bus -1 (RP05)
> acpiprt6 at acpi0: bus -1 (RP06)
> acpiec0 at acpi0
> acpi0: GPE 0x26 already enabled
> glkgpio0 at acpi0 GPO3 uid 4 addr 0xd0c8/0x82f irq 14, 35 pins
> acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> acpiac0 at acpi0: AC unit offline
> acpibat0 at acpi0: BAT0 model "Li-ion Battery" serial 00 type Lion oem "GLK
> MRD"
> acpibtn0 at acpi0: LID0
> "HTIX5288" at acpi0 not configured
> "ID9001" at acpi0 

Re: Anyone tried NanoPi R2S or a 2 LAN SBC?

[Patrick Wildt]

On Tue, Aug 18, 2020 at 09:59:29PM +0200, Dani Deni wrote:
> Hello,
> 
> trying to find a low powered single board computer with two gigabit LAN for
> router purposes.
> 
> already checked the https://www.openbsd.org/arm64.html page, but google
> doesn't brings up any arm64 based SBC with 2 gigabit network ports that
> OpenBSD supports.
> 
> or the NanoPi R2S can run OpenBSD? Anyone tried?
> 
> https://www.friendlyarm.com/index.php?route=product/product_id=282
> 
> 22$ ! cheap, low power usage and two gbit ethernet! It would be great if
> they wouldn't officially advert it with some custom OS :(

I have one, and I actually ordered a few more.  First thing you need is
U-Boot.  There is a patchset on the u-boot mailing lists.

The DTB part of that u-boot is good enough to boot, but I don't see the
USB show up.  I think for that we'd need to find another DTB.

Also, if you look through the lists, there's someone who already made it
work before.

The price itself isn't as nice anymore once you order it with a few
things, like case and... shipping costs.

Re: USB speakers

[Patrick Harper]

Can you post your /etc/rc.conf.local ?

-- 
  Patrick Harper
  paia...@fastmail.com

On Fri, 14 Aug 2020, at 17:21, Justin Muir wrote:
> Wondering whether anyone has experience with Logitech USB speakers?
> 
> Plugged in mine, did the rcctl rsnd/0 thingi from multimedia FAQ:
> # rcctl set sndiod flags -f rsnd/0 -F rsnd/1
> # rcctl restart sndiod
> 
> It doesn't work. As a matter of fact, the speaker light doesn't even come
> on now.
> 
> Any suggestions?
> 
> 
> tia!
> 
> J
> 
> Dmesg output below:
> 
> uaudio0 at uhub4 port 2 configuration 1 interface 1 "Logitech Logitech USB
> Speaker" rev 1.10/0.07 addr 3
> uaudio0: class v1, full-speed, sync, channels: 2 play, 0 rec, 7 ctls
> audio1 at uaudio0
> uhidev2 at uhub4 port 2 configuration 1 interface 2 "Logitech Logitech USB
> Speaker" rev 1.10/0.07 addr 3
> uhidev2: iclass 3/0
> uhid3 at uhidev2: input=2, output=0, feature=0
>

Re: OpenBSD Hangs On

[Patrick Dohman]

> On Jul 19, 2020, at 5:44 PM, Tom Smyth  wrote:
> 
> Im not sure what you mean? 

I can has all your VM’s in carbonite.
Regards
Patrick

Re: OpenBSD Hangs On

[Patrick Dohman]

> On Jun 23, 2020, at 11:31 AM, Tom Smyth  wrote:
> 
> But newerversions of kvm / linux kernels  are unaffected
> By the bug fyi

Sounds like FUD.
B.T.W where is Boba’s ride?
Regards
Patrick

Re: IKEDv2 and alias addresses

[Patrick Wildt]

On Fri, Jun 19, 2020 at 11:19:11AM -0400, Sonic wrote:
> With IKEDv1 I was able to use alias addresses for the VPN tunnels with
> a Listen-on directive in isakmpd.conf:
> ==
> [General]
> Listen-on=  1.2.3.7
> ==
> 
> So far my attempts with IKEDv2 have been unsuccessful at using alias
> addresses. Is it possible?
> 
> Thanks!
> 
> Chris

iked(8) listens on all addresses.  It binds on 0.0.0.0:500 and receives
all IKE messages that arrive, unless there's an isakmpd(8) runnin on the
same address.  Thus there's no need to specify an additional address,
because it's already listening on all addresses.

If you want to use a specific address for a policy, you can use the
"local" keyword to specify it.  This is part of the policy, not a global
option.

Then iked(8) continues to losten on 0.0.0.0:500, but the policy will
only match if the IP address match to the one specified as "local".

Patrick

Re: IKEv2 difference with 6.7

[Patrick Wildt]

On Tue, Jun 16, 2020 at 02:11:21PM -0400, Daniel Ouellet wrote:
> 
> 
> On 6/16/20 1:35 PM, Patrick Wildt wrote:
> > On Tue, Jun 16, 2020 at 01:09:32PM -0400, Daniel Ouellet wrote:
> >> Hi Tobias,
> >>
> >> I put below the full configuration and the flows as well with the 6.6
> >> binary and switch to the 6.7 binary without any other changes as well as
> >> the full config.
> >>
> >> The config may be a bit weird at first as I tunnel routable IP's over
> >> the iked over a Verizon Fios line. You can't get routable IP's from Fios
> >>  and I have needs for it. So that was my way around it for years now.
> >>
> >> Anyway, here below:
> >>
> >> gateway$ doas cat /etc/ipsec.conf
> >> flow esp out from ::/0 to ::/0 type deny
> >> flow esp from 66.63.44.64/27 to 66.63.44.96/28 type bypass
> >> flow esp from 66.63.44.96/28 to 66.63.44.64/27 type bypass
> >> flow esp from 66.63.44.67 to 66.63.44.97 type bypass
> >> flow esp from 66.63.44.90 to 66.63.44.97 type bypass
> >>
> >> (This above was to allow the two local subnet to take to one an other as
> >> they are in different dmz. I can delete that config and it changed
> >> nothing anyway. Just wanted to write why in case you wonder.)
> >>
> >> gateway$ doas cat /etc/iked.conf
> >> # All IP from 66.63.44.79 are Etienne computer to Riot on AS 6507 in
> >> Ashburn.
> >> ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com
> >>
> >> ikev2 "Flow" active \
> >> from re1 to tunnel.realconnect.com \
> >> from re1 to stats.realconnect.com \
> >> from 66.63.44.66 to 0.0.0.0/0 \
> >> from 66.63.44.67 to 66.63.0.0/18 \
> >> from home.ouellet.us to 0.0.0.0/0 \
> >> from 66.63.44.96/28 to 0.0.0.0/0 \
> >>from 66.63.44.79 to 43.229.64.0/22 \
> >>from 66.63.44.79 to 45.7.36.0/22 \
> >>from 66.63.44.79 to 103.240.224.0/22 \
> >>from 66.63.44.79 to 104.160.128.0/19 \
> >>from 66.63.44.79 to 162.249.72.0/21 \
> >>from 66.63.44.79 to 185.40.64.0/22 \
> >>from 66.63.44.79 to 192.64.168.0/21 \
> >> peer tunnel.realconnect.com
> >>
> >> (Here above for the 66.63.44.79, again a weird stuff, that's only for my
> >> older son. When he play LoL over Fios it suck! But when I tunnel it to
> >> my tunnel and then directly to Equinix where Riot is and I peer at, all
> >> is great and hard to believe I am sure, but latency is much lower. Again
> >> not relevant, just in case you wonder. I know, it's stupid, but I do a
> >> lots of work from home and I need to keep the family happy too. (;)
> >>
> >> On 6/16/20 6:09 AM, Tobias Heider wrote:
> >>> Hi Daniel,
> >>>
> >>> On Mon, Jun 15, 2020 at 08:04:43PM -0400, Daniel Ouellet wrote:
> >>>>> Probably related to the following change documented in
> >>>>> https://www.openbsd.org/faq/upgrade67.html:
> >>>>>
> >>>>> iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by 
> >>>>> iked(8) or
> >>>>> isakmpd(8) was changed from "use" to "require". This means unencrypted 
> >>>>> traffic
> >>>>> matching the flows will no longer be accepted. Flows of type "use" can 
> >>>>> still be
> >>>>> set up manually in ipsec.conf(5). 
> >>>>
> >>>> I have what appear to be similar problem. I used iked form 5.6 all the
> >>>> way to 6.6 no problem, wel some, but I worked it out. All in archive.
> >>>>
> >>>> But going from 6.6 to 6.7 I can't get it to work anymore. Nothing
> >>>> changed, same configuration, just a sysupgrade and that's it.
> >>>>
> >>>> I read this and I can understand the words, but may be I am think, but I
> >>>> don't understand what to do with it.
> >>>
> >>> The default behavior if IPsec flows was changed to not accept unencrypted
> >>> packets matching a registered flow.
> >>> You can list your flows with 'ipsecctl -sf'.
> >>
> >> gateway$ doas ipsecctl -sf
> >> flow esp in from 0.0.0.0/0 to 66.63.44.66 peer 66.63.5.250 srcid
> >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> >> flow esp in from 0.0.0.0/0 to 66.63.44.90 peer 66.63.5.250 srci

Re: IKEv2 difference with 6.7

[Patrick Wildt]

use
> flow esp in from 66.63.5.250 to 66.63.44.65 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 66.63.5.250 to 72.83.103.147 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 103.240.224.0/22 to 66.63.44.79 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 104.160.128.0/19 to 66.63.44.79 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 162.249.72.0/21 to 66.63.44.79 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 185.40.64.0/22 to 66.63.44.79 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 192.64.168.0/21 to 66.63.44.79 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp out from 66.63.44.65 to 66.63.5.245 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require
> flow esp out from 66.63.44.65 to 66.63.5.250 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require
> flow esp out from 66.63.44.66 to 0.0.0.0/0 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require
> flow esp out from 66.63.44.67 to 66.63.0.0/18 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require
> flow esp out from 66.63.44.79 to 43.229.64.0/22 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require
> flow esp out from 66.63.44.79 to 45.7.36.0/22 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require
> flow esp out from 66.63.44.79 to 103.240.224.0/22 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require
> flow esp out from 66.63.44.79 to 104.160.128.0/19 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require
> flow esp out from 66.63.44.79 to 162.249.72.0/21 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require
> flow esp out from 66.63.44.79 to 185.40.64.0/22 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require
> flow esp out from 66.63.44.79 to 192.64.168.0/21 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require
> flow esp out from 66.63.44.90 to 0.0.0.0/0 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require
> flow esp out from 66.63.44.96/28 to 0.0.0.0/0 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require
> flow esp out from 72.83.103.147 to 66.63.5.250 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require
> flow esp out from ::/0 to ::/0 type deny
> 
> SAD:
> esp tunnel from 66.63.5.250 to 72.83.103.147 spi 0x9f629698 auth
> hmac-sha2-256 enc aes-256
> esp tunnel from 72.83.103.147 to 66.63.5.250 spi 0xba228cb0 auth
> hmac-sha2-256 enc aes-256
> esp tunnel from 66.63.5.250 to 72.83.103.147 spi 0xc44b9bb8 auth
> hmac-sha2-256 enc aes-256
> esp tunnel from 72.83.103.147 to 66.63.5.250 spi 0xc5d5aa26 auth
> hmac-sha2-256 enc aes-256
> 
> 
> 
> Now if I put the iked 6.7 binary instead, I see the traffic going out,
> enter the remote tunnel, getting out of the tunnel to come back, but
> never coming in the gateway unit.
> 
> Nothing changed, just the binary 6.7 replacing the binary 6.6
> 
> See full display of step by step with proof of binary in use and all.
> 
> Cut and paste from the terminal as is. I can't never get a flow going on
> 6.7 with the exact same configuration as 6.6. Just using 6.6 works as
> is. So I obviously do something wrong, just can't say what and I have to
> say, it's most likely really stupid, but I can't see it.
> 
> gateway$ ls -l /sbin/iked*
> -r-xr-xr-x  1 root  bin  436584 Jun 15 20:42 /sbin/iked
> -r-xr-xr-x  1 root  bin  436584 Jun 15 20:42 /sbin/iked.66
> -r-xr-xr-x  1 root  bin  448744 May  7 12:52 /sbin/iked.67
> gateway$ date
> Tue Jun 16 12:51:13 EDT 2020
> gateway$ doas /etc/rc.d/iked stop
> iked(ok)
> gateway$ doas cp -p /sbin/iked.67 /sbin/iked
> gateway$ doas /etc/rc.d/iked start
> iked(ok)
> gateway$ doas ipsecctl -sa
> FLOWS:
> No flows
> 
> SAD:
> No entries
> gateway$ date
> Tue Jun 16 12:51:54 EDT 2020
> gateway$ ls -l /sbin/iked*
> -r-xr-xr-x  1 root  bin  448744 May  7 12:52 /sbin/iked
> -r-xr-xr-x  1 root  bin  436584 Jun 15 20:42 /sbin/iked.66
> -r-xr-xr-x  1 root  bin  448744 May  7 12:52 /sbin/iked.67
> 
> 
> >> My guess is that it is simple and I don't think about it properly, but I
> >> am hitting a road block trying to figure it out.
> >>
> >> I am a bit at a lost and any clue stick would be greatly appreciated.
> >>
> >> Thanks
> >>
> >> Daniel
> >>
> > 
> > - Tobias
> > 
> 

Hi,

thanks for the detailed input.  But there's one thing missing:  The
log output of the daemon.  It'll probably end up somewhere in /var/log/
daemon or /var/log/messages or so.

Since you see no SA or Flow at all, iked maybe hasn't successfully
created them at all, and for that we need to see what iked complains
about, which it probably did in the log files.

Best regards,
Patrick

Re: Realtek Edimax AC1750 USB gets properly detected but not configurable in ifconfig

[Patrick Harper]

Judging by the dmesg there is at least one unoccupied PCIe slot that could 
accommodate an adapter such as a Silverstone ECWA2-LITE.

This would allow you to use Mini-PCIe cards that normally go in laptops, 
including all of the iwm(4) devices.

-- 
  Patrick Harper
  paia...@fastmail.com

On Sat, 6 Jun 2020, at 19:44, Tristan wrote:
> Oh sorry,  my mistake, I might need some sleep :)
> 
> Thanks for the list of USB adapters, that helps a lot.
> 
> > On Jun 6, 2020, at 9:35 PM, Stuart Henderson  wrote:
> > 
> > On 2020/06/06 19:14, Tristan wrote:
> >> Ok thanks. Yes I’m looking for just using 11n.
> > 
> > You already replied saying that!
> > 
> > It doesn't matter if you only want to use 11n, OpenBSD does not have a
> > driver for the controller used in that adapter.
> > 
> > For USB adapters look for a device using one of these:
> > 
> > bwfm(4) - Broadcom and Cypress IEEE 802.11a/ac/b/g/n wireless network device
> > otus(4) - Atheros USB IEEE 802.11a/b/g/n wireless network device
> > rsu(4) - Realtek RTL8188SU/RTL8192SU USB IEEE 802.11b/g/n wireless network 
> > device
> > run(4) - Ralink Technology/MediaTek USB IEEE 802.11a/b/g/n wireless network 
> > device
> > urtwn(4) - Realtek RTL8188CU/RTL8188EU/RTL8192CU/RTL8192EU USB IEEE 
> > 802.11b/g/n wireless network device
> > 
> > (or there are some 11g-only ones but not much point looking for them).
> > 
> > 
> >> 
> >>>> On Jun 6, 2020, at 5:55 AM, Stuart Henderson  
> >>>> wrote:
> >>> 
> >>> On 2020-06-05, Tristan  wrote:
> >>>> Just plugged in a Realtek Edimax AC1750 USB card into a ASRock B450M 
> >>>> board.
> >>>> I can see the card being detected and registered properly in dmesg and
> >>>> usbdevs, but cannot configure it.
> >>>> Is this card supported?
> >>> 
> >>> No. The only supported 11ac USB devices are the limited and fairly hard 
> >>> to get
> >>> hold of bwfm(4) devices. (Some PCIe 11ac are supported but not in 11ac 
> >>> mode.)
> >>> 
> >>> 
> >>> 
> >> 
> > 
> 
>

Re: uvideo0: can't find interface assoc descriptor

[Patrick Wildt]

On Sat, May 30, 2020 at 07:47:17PM +0200, Jan Stary wrote:
> On May 30 18:50:12, h...@stare.cz wrote:
> > This is current/amd64 on a MacBook2,1 (dmesg below)
> > With the latest upgrade, it has lost video0:
> > 
> > uvideo0 at uhub0 port 4 configuration 1 interface 0 "Micron Built-in 
> > iSight" rev 2.00/1.84 addr 2
> > uvideo0: can't find interface assoc descriptor
> 
> Similar thing happens with current/i386 on a MacBook1,1 (dmesg below):
> uvideo0: can't find video interface
> 
>   Jan

Yeah, this is due to the change to support multiple cameras in one
device.  You can try this diff, let me know if this works on both
of your machines.

Patrick

diff --git a/sys/dev/usb/uvideo.c b/sys/dev/usb/uvideo.c
index d33e3079acd..da00d0d3d0d 100644
--- a/sys/dev/usb/uvideo.c
+++ b/sys/dev/usb/uvideo.c
@@ -510,6 +510,8 @@ uvideo_attach(struct device *parent, struct device *self, 
void *aux)
int i;
 
sc->sc_udev = uaa->device;
+   sc->sc_iface = uaa->ifaceno;
+   sc->sc_nifaces = uaa->nifaces;
 
/* Find the first unclaimed video interface. */
for (i = 0; i < uaa->nifaces; i++) {
@@ -521,10 +523,8 @@ uvideo_attach(struct device *parent, struct device *self, 
void *aux)
if (id->bInterfaceClass == UICLASS_VIDEO)
break;
}
-   if (i == uaa->nifaces) {
-   printf("%s: can't find video interface\n", DEVNAME(sc));
-   return;
-   }
+   if (i == uaa->nifaces)
+   goto attach;
 
/* Find out which interface association we belong to. */
usbd_desc_iter_init(sc->sc_udev, );
@@ -540,30 +540,38 @@ uvideo_attach(struct device *parent, struct device *self, 
void *aux)
break;
desc = usbd_desc_iter_next();
}
-   if (desc == NULL) {
-   printf("%s: can't find interface assoc descriptor\n",
-   DEVNAME(sc));
-   return;
-   }
+   if (desc != NULL) {
+   /*
+* Claim all interfaces of our association.  Interfaces must be
+* claimed during attach, during attach hooks is too late.
+*/
+   for (i = iad->bFirstInterface;
+   i < iad->bFirstInterface + iad->bInterfaceCount; i++) {
+   if (usbd_iface_claimed(sc->sc_udev, i)) {
+   printf("%s: interface already claimed\n",
+   DEVNAME(sc));
+   return;
+   }
+   usbd_claim_iface(sc->sc_udev, i);
+   }
 
-   /*
-* Claim all interfaces of our association.  Interfaces must be
-* claimed during attach, during attach hooks is too late.
-*/
-   for (i = iad->bFirstInterface;
-   i < iad->bFirstInterface + iad->bInterfaceCount; i++) {
-   if (usbd_iface_claimed(sc->sc_udev, i)) {
-   printf("%s: interface already claimed\n",
-   DEVNAME(sc));
-   return;
+   /* Remember our association by saving the first interface. */
+   sc->sc_iface = iad->bFirstInterface;
+   sc->sc_nifaces = iad->bInterfaceCount;
+   } else {
+   /* No association, so simply claim them all. */
+   for (i = 0; i < uaa->nifaces; i++) {
+   if (usbd_iface_claimed(sc->sc_udev, i))
+   continue;
+   id = 
usbd_get_interface_descriptor(>sc_udev->ifaces[i]);
+   if (id == NULL)
+   continue;
+   if (id->bInterfaceClass == UICLASS_VIDEO)
+   usbd_claim_iface(sc->sc_udev, i);
}
-   usbd_claim_iface(sc->sc_udev, i);
}
 
-   /* Remember our association by saving the first interface. */
-   sc->sc_iface = iad->bFirstInterface;
-   sc->sc_nifaces = iad->bInterfaceCount;
-
+attach:
/* maybe the device has quirks */
sc->sc_quirk = uvideo_lookup(uaa->vendor, uaa->product);
 

Re: More than 16 partitions

[Patrick Harper]

> Medoesn't a care a flying fsck about what is "trendy".

Is this the most ironic sentence ever posted on here? Dubiously censoring an 
expletive with a common 'Unix' utility isn't motivated by some sort of desire 
to feel like a part of the righteous ones? Come on.

Re: More than 16 partitions

[Patrick Harper]

If you didn't make any of this up, you dumbed it down to the point where 
there's no useful info left. You seem to operate on the assumption that merely 
dissing the work of companies and from ecosystems you don't like, as though 
it's the 'trendy' thing to do, is enough for you to get by on this forum 
without scrutiny.

-- 
  Patrick Harper
  paia...@fastmail.com

On Thu, 23 Apr 2020, at 18:06, zeurk...@volny.cz wrote:
> "Groot"  wrote:
> > I've tried and failed to create more than 16
> > partitions on OpenBSD. First of all I don't
> > understand the difference between the operations
> > performed by fdisk and disklabel. Is it that
> > OpenBSD sees partitions differently? First we
> > create an OpenBSD partition with fdisk and then
> > with disklabel we can create at the most 16 more
> > filesystem partitions within it.
> 
> Traditionally, BSD has used only its own disklabel(5). Unfortunately,
> mess-dos on the IBM pee-cee set a competing standard, the "Master Boot
> Record", with a separate partition table (and a lot of kludging to
> support more than 4 partitions). While it was (and AFAIK remains)
> possible to use the whole disk the traditional way (only a BSD
> disklabel, as on e.g. sparc64), it has become common practice to wrap
> the BSD stuff in a mess-dos partition, with the caveat that some of the
> mess-dos partition entries are duplicated in the BSD label.
> 
> Thus, the BSD label is essentially OpenBSD's version of the structure of
> things on the disk. But is an imperfect version: 16 partitions *is* the
> limit for an OpenBSD label, and, of course, mess-dos partition
> identifiers (which are more *ahem* fine-grained) are not used. To top it
> off, partitions which rest within the mess-dos OpenBSD partition are not
> necessarily represented on the mess-dos level (this would count, from
> the mess-dos perspective, as overlap between partitions and thus confuse
> a great many tools). 
> 
> Then GPT entered the story to make the mess complete. But me'll remain
> blissfully unaware of the inner workings of that particular clusterfsck,
> if you don't mind ;)
> 
> It's no shame to be confused by this garbage. Almost all of us'd like
> better, but for the above hysterical raisins, it's not so easy to make
> it so.
> 
>   --zeurkous.
> 
> -- 
> Friggin' Machines!
> 
>

Re: Iridium vs Chromium

[Patrick Harper]

I'm puzzled that you thought my statements were a complaint.

-- 
  Patrick Harper
  paia...@fastmail.com

On Sun, 12 Apr 2020, at 22:30, Theo de Raadt wrote:
> Patrick Harper  wrote:
> 
> > I mean that all Chromium releases are made available for OpenBSD-stable 
> > (excluding the previous release at any given time, as with all existing 
> > port maintenance).
> 
> So you want constant Chromium updates in -stable.
> 
> Who's going to do that?
> 
> Are you going to do it?
> 
> And why pick only on Chromium.  Should the same policy be to update all
> *all* packages to -stable, all the time, continuously?
> 
> Who's going to do that?
> 
> Won't we need twice as many people, so that -current ports are maintained,
> as well as -stable ports?  Or if we can't find more people, won't that mean
> a reduction in development of packages in the next release?  Which means
> that -current won't get updated, which means -stable will fall behind
> even further?
> 
> You don't seem to know this:  -stable is done by *one person*
>  
> > My understanding of -current is that it is meant for testing, not usage.
> 
> -current turns into a -release.  So if you don't want good -release,
> which will be followed by good -stable, then how do you think this is
> going to work?
> 
> You don't think.  You just believe deliverable-product you can conceive
> of being possible, should be delivered to you.  Probably on a silver
> plate?
> 
> I believe I've identified the problem precisely.  It is not a software
> problem, it is a people with out-of-touch expectation problem.  It may be
> connected to "the less people pay, the more they expect".  It might also
> be connected to "wow this group looks open, I can participate by demanding
> they do things for me".
> 
> 
>

Re: Iridium vs Chromium

[Patrick Harper]

I mean that all Chromium releases are made available for OpenBSD-stable 
(excluding the previous release at any given time, as with all existing port 
maintenance).

My understanding of -current is that it is meant for testing, not usage.

-- 
  Patrick Harper
  paia...@fastmail.com

On Sun, 12 Apr 2020, at 21:38, Kevin Chadwick wrote:
> On April 12, 2020 7:07:01 PM UTC, Patrick Harper  wrote:
> >The effort to support Chromium and Firefox (sans ESR) on OpenBSD akin
> >to Windows/macOS/'Linux' has not happened.
> 
> On atleast current as Theo showed, Chromium is just as well if not 
> better supported on OpenBSD than on Linux, these days.
> 
> I assume you are judging by a while ago. Or perhaps you mean Chrome 
> where pre-built binaries for Linux are released by Google? I used to 
> install chrome on debian/ubuntu to get the extra days.
> 
>

Re: Iridium vs Chromium

[Patrick Harper]

The effort to support Chromium and Firefox (sans ESR) on OpenBSD akin to 
Windows/macOS/'Linux' has not happened.

-- 
  Patrick Harper
  paia...@fastmail.com

On Sun, 12 Apr 2020, at 16:49, Raymond, David wrote:
> My problem with iridium is that it is based on an older version of
> chromium and I am not sure that they keep up with inevitable flow of
> security fixes.  That said, I am a bit nervous about OpenBSD's lags in
> keeping up with browser security fixes.  (I'm not criticizing -- I
> understand that OpenBSD is a small operation without the people needed
> to keep track of non-core packages.  And I just converted from Arch
> Linux, in which the storm of updates and resulting incompatibilities
> drove me crazy and contributed to my shift to OpenBSD.  Still, I am a
> bit nervous about even slightly out-of-date browsers at this point and
> I am not sure that iridium is an improvement in this regard.)
> 
> Dave
> 
> On 4/12/20, Elias M. Mariani  wrote:
> > I'm not much of a browser savy guy.
> > Is Iridium really safer than Chromium?
> > Leaving aside the "Google is tracking you!".
> >
> > Any recommendations on the browser front on performance, security and
> > compatibility?
> > I've been using Chrome and Chromium for years, but maybe there are
> > better alternatives that I'm unaware of...
> >
> > Cheers.
> > Elias.
> >
> >
> 
> 
> -- 
> David J. Raymond
> david.raym...@nmt.edu
> http://physics.nmt.edu/~raymond
> 
>

Re: bwfm NVRAM file

[Patrick Wildt]

On Fri, Mar 13, 2020 at 12:12:18PM +0100, Rob Schmersel wrote:
> Hello,
> 
> In order to use a SDIO based bwfm device a "NVRAM" configuration file
> will be needed besides the firmware file. This configuration file is
> expected to be in the /etc/firmware directory, in the form of
>  brcmfmac{chip}-sdio.txt OR brcmfmac{chip}-sdio.nvram
> 
> The need for this configuration file is not described in the man page.
> However the device will not be usable without one and an error message
> will be shown in the dmesg:
>   "failed loadfirmware of file: brcmfmac{chip}-sdio.txt"
> 
> Can I suggest to below attached patch. 
> 
> I'm a bit unsure on how to indicate where the configuration file comes from:
> Under Linux it is recommended that you read the NVRAM contents from
> EFI, which I don't think is possible to do under OpenBSD
> 
> Hunting down the configuration file through your favorite search engine
> can be a frustrating excercise, although you can find them
> occasionally included in a windows driver or a linux distro.
> 
> Question: Are there plans to include the NVRAM files in bwfm_firmware
> package?

It all depends!  The NVRAM file is board-design-specific.  So, let's
assume OpenBSD and NetBSD would each build their own machine, using
the same chip and firmware.  The NVRAM file contains a configuration
for the chip, so that it e.g. can limit TX/antenna gain or whatever.
This is important for stuff like CE certification.  There are quite a
few settings, so it's very likely that the one board's chip needs a
different configuration than the other one's chip.

So where do we get this file?  If it's an x86-based machine, it's
likely they stored it as EFI variable.  In OpenBSD, so far only the
ARM ports support calling into the Runtime Services using efi(4).
Since we don't have support for efi(4) on x86, OpenBSD cannot read
the EFI variables.  For that you'll have to boot Linux, or some
other OS that has that feature.  On some other x86 machines, the
vendor might provide the file as part of a Windows firmware package.

Is it different on ARMs?  Well, yes, but not sure if worse or even
better.  The NVRAM file can usually be found on the vendor's Github.

linux-firmware.git has started collecting and distributing some of
the files.  So that will be a helpful source for us.  Otherwise we
will have to collect them ourselves.

For ARM there's still one commit left so that we can supply per-
board NVRAM files more easily.  In essence: We're working on it!

Patrick

Re: FreeBSD daemon(8)-like command for OpenBSD

[Patrick Kristiansen]

On Fri, Jan 31, 2020, at 09:29, Janne Johansson wrote:
> Den tors 30 jan. 2020 kl 21:08 skrev Patrick Kristiansen 
> :
> >  > Properly starting up a daemon process requires several steps,
> >  > often involving unveil(2), pledge(2), chroot(2), prviledge
> >  > dropping, sometimes fork+exec for privilege separation, and so on
> > 
> >  The process I need to run is written in Clojure and thus runs on the
> >  Java Virtual Machine. Do you have any suggestions on how to best go
> >  about making it "daemon-like"? I am not sure that I can call unveil(2),
> >  pledge(2) and chroot(2) from Clojure without some strange sorcery.
> 
> So not related to only Clojure but rather on runtimes that are large
> and unwieldy, this seems to be exactly why plegde() and unveil() came
> into being in the first place, after seeing things that needs to do
> certain privileged operations at some early point, but because of
> design/runtime/hard-to-pledge or whatever has to run with the sum of
> all privileges, all capabilities at all times and at the same time
> being exposed to potential hostile data.

Yes. I completely understand the motivation behind pledge, unveil and
similar constructs. I also understand that it sort of runs counter to
using one of the world's most secure-by-default operating systems if you
then run an insecure monstrosity on top of it. I was just starting to
like the OpenBSD experience as a user and sysadmin. :-)

But I also think that it is unrealistic to expect applications to be
written to the same standard as OpenBSD, given the resources needed for
that. Many startups would never get off the ground if that were the
case.

> I can fully see why Ingo would say "I would not run things like that
> exposed", partly because I figure he actually has a choice to not do
> it, but regardless of what electric fences you like (Selinux,
> capsicum, pledge/unveil, chroots) if you create a huge monolith
> running in an environment which actively prevents you from activating
> any kinds of protections, then I can see how you would see some
> friction.

I would like to get more information about doing application programming
for an OS like OpenBSD. I understand that if you program your
applications in C, you have readily available pledge/unveil, etc. But
many applications are written in higher-level languages, and in my case
at least, it seems to be nearly impossible to write a secure application
without changing to C or some other language that can easily use
OpenBSD's system calls. And for a mediocre programmer, or just an
inexperienced one, it exposes you to a whole host of other problems that
can lead to worse security and quality.

The solution is probably just to be a good programmer. ;-)

Re: FreeBSD daemon(8)-like command for OpenBSD

[Patrick Kristiansen]

On Thu, Jan 30, 2020, at 23:32, Ingo Schwarze wrote:
> In general, size and complexity tend to hurt security, but i know
> too little about Java to say how relevant that general rule of thumb
> is to the question of running a daemon using a Java Virtual Machine.
> For example, Perl 5 is also a fairly large and complex system, but
> it still supports writing daemons that are secure enough for many
> purposes, when used properly - even though i'd probably prefer a
> simpler approach when i have a choice.

Trying to learn some valuable lessons from our interaction, could you
give some examples of what you mean by 'simpler approach' in this
context?

Do you mostly do systems programming?

Best regards,
Patrick

Re: FreeBSD daemon(8)-like command for OpenBSD

[Patrick Kristiansen]

On Thu, Jan 30, 2020, at 21:10, Ingo Schwarze wrote:
> Hi Patrick,
> 
> Patrick Kristiansen wrote on Thu, Jan 30, 2020 at 09:05:11PM +0100:
> 
> > The process I need to run is written in Clojure and thus runs on the
> > Java Virtual Machine.  Do you have any suggestions on how to best go
> > about making it "daemon-like"?
> 
> No, i'm sorry i have no advice on that.  I would certainly not run
> soemthing like that under any circumstances, on any machine, and even
> less so on any machine connected to the Internet.

Out of genuine curiosity, and not to be inflammatory, are you saying
that running any internet-facing service/process/program is inadvisible
under all circumstances if not written to the standards of a daemon
shipping with OpenBSD and with the facilities (pledge, unveil, etc.)
available in OpenBSD?

Best regards,
Patrick

Re: FreeBSD daemon(8)-like command for OpenBSD

[Patrick Kristiansen]

Hi Ingo,

On Thu, Jan 30, 2020, at 18:35, Ingo Schwarze wrote:
> Hi Patrick,
> 
> Patrick Kristiansen wrote on Tue, Jan 28, 2020 at 09:29:20AM +0100:
> 
> > But another use for daemon(8) is for its ability to detach the child
> > process from the controlling terminal and furthermore redirect its
> > stdout/stderr to syslog. Is there some mechanism to do that from the
> > shell? Perhaps a combination of nohup and starting a background job?
> 
> That doesn't strike me as a particularly bright idea either.
>
> Properly starting up a daemon process requires several steps, often
> involving unveil(2), pledge(2), chroot(2), prviledge dropping,
> sometimes fork+exec for privilege separation, and so on. Typically,
> these steps need to be intermixed in exactly the right order with
> option parsing, environment parsing, parsing of configuration files
> and various kinds of initialization.

The process I need to run is written in Clojure and thus runs on the
Java Virtual Machine. Do you have any suggestions on how to best go
about making it "daemon-like"? I am not sure that I can call unveil(2),
pledge(2) and chroot(2) from Clojure without some strange sorcery. I
read in some blog post, that the way to detach from the controlling
terminal is by closing stdin, stdout and stderr, which I admittedly
haven't tried.

> Writing wrappers usually just doesn't work, and it seems doubtful to
> me whether daemon(8) is up to what is usually needed.

If I were writing my program in C, I could fairly easily call daemon(3),
I guess, but I am not. I am starting to think that tmux(1) would be the
easiest way to go about it on OpenBSD... but it feels wrong.

Best regards,
Patrick

Re: FreeBSD daemon(8)-like command for OpenBSD

[Patrick Kristiansen]

Hi Ingo

Thank you for your reply.

I can't say I disagree with your and the OpenBSD team's attitude about
bug-free daemons. But I am just a lowly application programmer, and
sometimes I introduce horrible bugs that make our systems crash. In many
cases it will be preferable to just start the process again (and, of
course, fix the bug) for the purposes of keeping our business running.

But another use for daemon(8) is for its ability to detach the child
process from the controlling terminal and furthermore redirect its
stdout/stderr to syslog. Is there some mechanism to do that from the
shell? Perhaps a combination of nohup and starting a background job?

Best regards,
Patrick

> Hi Patrick,
> 
> Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100:
> 
>> Is there something like the FreeBSD daemon(8) command for OpenBSD,
>> which can run a process in the background and restart it if it
>> crashes?
> 
> Absolutely not, we are strongly convinced this is an utterly stupid
> idea and a serious security risk.
> 
> If a daemon crashes, it has a bug.  Many bugs that cause crashes
> are also exploitable.  So if a daemon crashes, you first have to
> understand why it crashed, fix or at least mitigate the bug, and
> can only restart it afterwards.
> 
> Restarting it automatically is an irresponsible thing to do.
> 
> If a daemon keeps crashing so frequently that you can only run it
> in production with automatic restarts, then running it at all is
> irresponsible in the first place.
> 
> Yours,
>  Ingo

FreeBSD daemon(8)-like command for OpenBSD

[Patrick Kristiansen]

Hi everyone,

Is there something like the FreeBSD daemon(8) command for OpenBSD, which
can run a process in the background and restart it if it crashes? That
is, is there a command that comes with OpenBSD's base image with these
capabilities? Surprisingly, Google hasn't revealed anything useful to
me.

Thanks,
Patrick Kristiansen

Re: Issues with X and Gnome on OpenBSD new install

[Patrick Harper]

Did you follow /usr/local/share/doc/pkg-readmes/gnome ?


-- 
  Patrick Harper
  paia...@fastmail.com

On Tue, 7 Jan 2020, at 23:05, Michael G Workman wrote:
> Hello,
> 
> OpenBSD is a great operating system, glad to have been to installed it
> successfully.
> 
> I installed OpenBSD on a Dell Vostro 1500 laptop with dual core 2ghz intel
> processor, 2 GB of RAM, and 120 GB hard drive (circa 2008 laptop)
> 
> I had problems with firefox, but installed Chromium instead and Chrome
> works great for web browsing.
> 
> I also installed bash and nano, and also installed Gnome. Hoping to use
> Gnome instead of the default window manager.
> 
> But encountered a fatal error, the X server could not be found, and also a
> driver called xf86OpenConsole was missing, causing a fatal server error.
> 
> When I installed it, I chose openbsd-dell for the hostname, and then
> OpenBSD tacked on attlocal.net to it to make it openbsd-dell.attlocal.net,
> but not sure how that happened, an nslookup on attlocal.net says it is an
> invalid domain.
> 
> I am sure it must be a simple fix, here is my Xorg.1.log file:
> 
> Thanks.
> 
> [  6760.324]
> X.Org X Server 1.20.5
> X Protocol Version 11, Revision 0
> [  6760.324] Build Operating System: OpenBSD 6.6 amd64
> [  6760.324] Current Operating System: OpenBSD openbsd-dell.attlocal.net
> 6.6 GENERIC.MP#372 amd64
> [  6760.324] Build Date: 12 October 2019  11:22:22AM
> [  6760.324]
> [  6760.325] Current version of pixman: 0.38.4
> [  6760.325] Before reporting problems, check http://wiki.x.org
> to make sure that you have the latest version.
> [  6760.325] Markers: (--) probed, (**) from config file, (==) default
> setting,
> (++) from command line, (!!) notice, (II) informational,
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [  6760.325] (==) Log file:
> "/home/mworkman72/.local/share/xorg/Xorg.1.log", Time: Tue Jan  7 15:01:09
> 2020
> [  6760.341] (==) Using system config directory
> "/usr/X11R6/share/X11/xorg.conf.d"
> [  6760.351] (==) No Layout section.  Using the first Screen section.
> [  6760.351] (==) No screen section available. Using defaults.
> [  6760.351] (**) |-->Screen "Default Screen Section" (0)
> [  6760.351] (**) |   |-->Monitor ""
> [  6760.352] (==) No monitor specified for screen "Default Screen Section".
> Using a default monitor configuration.
> [  6760.352] (==) Automatically adding devices
> [  6760.352] (==) Automatically enabling devices
> [  6760.352] (==) Not automatically adding GPU devices
> [  6760.352] (==) Max clients allowed: 256, resource mask: 0x1f
> [  6760.401] (==) FontPath set to:
> /usr/X11R6/lib/X11/fonts/misc/,
> /usr/X11R6/lib/X11/fonts/TTF/,
> /usr/X11R6/lib/X11/fonts/OTF/,
> /usr/X11R6/lib/X11/fonts/Type1/,
> /usr/X11R6/lib/X11/fonts/100dpi/,
> /usr/X11R6/lib/X11/fonts/75dpi/
> [  6760.401] (==) ModulePath set to "/usr/X11R6/lib/modules"
> [  6760.401] (II) The server relies on wscons to provide the list of input
> devices.
> If no devices become available, reconfigure wscons or disable
> AutoAddDevices.
> [  6760.401] (II) Loader magic: 0xef025473000
> [  6760.402] (II) Module ABI versions:
> [  6760.402] X.Org ANSI C Emulation: 0.4
> [  6760.402] X.Org Video Driver: 24.0
> [  6760.402] X.Org XInput driver : 24.1
> [  6760.404] X.Org Server Extension : 10.0
> [  6760.404] (EE)
> Fatal server error:
> [  6760.404] (EE) xf86OpenConsole: No console driver found
> Supported drivers: wscons
> Check your kernel's console driver configuration and /dev entries(EE)
> [  6760.404] (EE)
> Please consult the The X.Org Foundation support
> at http://wiki.x.org
>  for help.
> [  6760.404] (EE) Please also check the log file at
> "/home/mworkman72/.local/share/xorg/Xorg.1.log" for additional information.
> [  6760.405] (EE)
> [  6760.406] (EE) Server terminated with error (1). Closing log file.
> 
> *Michael G. Workman*
> (321) 432-9295
> michael.g.work...@gmail.com
>

Re: Solid-Run's HoneyComb LX2K for OpenBSD

[Patrick Wildt]

On Tue, Dec 10, 2019 at 10:25:57PM +1100, VanL wrote:
> 
> > How good are the chances of the 'HoneyComb LX2K' running OpenBSD?  [1]
> >
> > Footnotes: 
> > [1]  https://www.solid-run.com/nxp-lx2160a-family/honeycomb-workstation/
> 
> For future reference, the more specific place to ask is a...@openbsd.org
> and the places to see before asking are:
> 
>   https://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/INSTALL.arm64
>   https://ftp.openbsd.org/pub/OpenBSD/6.6/arm64/INSTALL.arm64
>   https://www.openbsd.org/arm64.html

I thought about buying one, but that SoC is from another architecture
team at NXP which means that we'd need to another stack of drivers just
to support the SoC used there.  Though with ACPI some things might get
easier.

So, as of now, I don't think there's a chance OpenBSD runs on that LX2K
hardware, unless someone from us gets such a machine and starts writing
support for it.

Patrick

Re: What happened to 6.6/sgi?

[Patrick Harper]

https://marc.info/?l=openbsd-cvs=156941089510768=2

-- 
  Patrick Harper
  paia...@fastmail.com

On Sun, 8 Dec 2019, at 16:29, Stefan Hagen wrote:
> Hello *
> 
> I was browsing around and noticed that there are no files for the SGI 
> platform on the mirrors. SGI is mentioned in the 6.6/README, so I assume
> it is supported. Did it get lost somehow? (snapshot/sgi exists)
> 
> Bye,
> Stefan
> 
> 
>

Re: Home NAS

[Patrick Marchand]

Hi,

On 11/17, Predrag Punosevac wrote:
> Patrick Marchand  wrote:
> > On 11/15, Predrag Punosevac wrote:
> > > Patrick Marchand wrote:
> > > > I'll be playing around with DragonflyBSD Hammer2 (and multiple offsite
> > > > backups) for a home NAS over the next few weeks. I'll probably do a
> > > > presentation about the experience at the Montreal BSD user group
> > > > afterwards. It does not require as many ressources as ZFS or BTRFS,
> > > > but offers many similar features.
> > > >
> > >
> > > Been there, done that!
> > Cool ! I might ping you off-list with questions when I get to it.
> >
>
> Any time. Either this private email or at my work predr...@cs.cmu.edu
> I wish I was a bit closer to Montreal to come to your monthly meeting. I
> love Quebec and Montreal in particular.
Thanks !

> > I'm not planning on using jails much, instead I'll be using the
> > DFly NFS with OpenBSD to experiment with virtualization.
> >
>
>
> I am not sure that I am following. How is DF NFS server related to
> OpenBSD (if I understand correctly) virtualization. Are you trying to
> store OpenBSD vmm images on the NFS share exported from a DF server?
> That is a really, really bad idea.
>
>
> https://marc.info/?l=dragonfly-users=140384130921709=2
MirageOS and PXE booted OpenBSD is what I really want to play with,
but well see as I go along, breaking stuff is kind of the idea here.

>
> > > DragonFly which gets it software RAID discipline through old
> > > unmaintained FreeBSD natacontrol utility. Hardware RAID cards are not
> > > frequently tested and community seems to be keen on treating DF as a
> > > desktop OS rather than a storage workhorse. Having said that HDD are
> > > cheap this days and home users probably don't need anything bigger than
> > > a 12TB mirror.
> > I dont store much anyways, so I'll see as I go.
> >
>
> 12 TB is the sweet spot when it comes GB/dollar for platter HDDs.
As it's more for an experiment and maybe some bsd systems work and
it will be running in my room, I started with a 1TB ssd.

Re: Iked/unbound ~ more info.

[Patrick Dohman]

> On Nov 17, 2019, at 11:45 AM, Dale C.  wrote:
> 
> Hi again,
> 
> Still trying to forward DNS to a local unbound resolver on the
> responder of an IKE tunnel.
> 
> Providing more information here. Everything works, but DNS.
> 
> It's worth noting I've tried many, many variations on these configs,
> cannot get DNS to the remote unbound resolver.
> 
> So, my questions are: What is the correct way to forward DNS to a
> local unbound resolver on the responder?
> 
> If there is more information that is helpful, please let me know what
> you need and I'll post it ;)
> 
> Thanks!


Dale
Is it possible to place the ESP nterface in debug?
Can you log PF/UDP traffic on the local unbound?
Regards
Patrick

Re: Home NAS

[Patrick Marchand]

Hello,

On 11/15, Predrag Punosevac wrote:
> Patrick Marchand wrote:
> > I'll be playing around with DragonflyBSD Hammer2 (and multiple offsite
> > backups) for a home NAS over the next few weeks. I'll probably do a
> > presentation about the experience at the Montreal BSD user group
> > afterwards. It does not require as many ressources as ZFS or BTRFS,
> > but offers many similar features.
> >
>
> Been there, done that!
Cool ! I might ping you off-list with questions when I get to it.

> H2 lacks built in backup mechanism. I was hoping that H2 will get some
> kind "hammer mirror-copy" of H1, or "zfs send/receive". My server is
> still on H1 and I really enjoy being able to continuously back it up.
> That's the only thing I am missing in H2. On the positive note H2 did
> get support for boot environment manager last year.
>
> https://github.com/newnix/dfbeadm
>
> Also DF jails are stuck in 2004 or something like that. I like their
> NFSv3.
I'm not planning on using jails much, instead I'll be using the
DFly NFS with OpenBSD to experiment with virtualization.

> DragonFly which gets it software RAID discipline through old
> unmaintained FreeBSD natacontrol utility. Hardware RAID cards are not
> frequently tested and community seems to be keen on treating DF as a
> desktop OS rather than a storage workhorse. Having said that HDD are
> cheap this days and home users probably don't need anything bigger than
> a 12TB mirror.
I dont store much anyways, so I'll see as I go.

Regards

Re: Home Nas -> Montreal BUG

[Patrick Marchand]

Hey,

Since I'm getting off-list questions from more than one person,
I'll post here as well.

On 11/15, Patrick Marchand wrote:
> I'll be playing around with DragonflyBSD Hammer2 (and multiple offsite
> backups) for a home NAS over the next few weeks. I'll probably do a
> presentation about the experience at the Montreal BSD user group afterwards.
> It does not require as many ressources as ZFS or BTRFS, but offers many
> similar features.

It's brand spanking new and I havent advertised much beyond Mastodon
and l'Agenda du Libre. (Somebody at work posted it in the work owned
meetup, but that's not a platform I want as a main base).

The actual link for the next event (on the 27th of november) is
here: https://agendadulibre.qc.ca/events/2050, I'm planning it as
a free (as in free of scheduled activities) session where people
will have access to food, drinks and wifi so they can ask configuration
questions, install a BSD, work on a port, etc..

We've had one meeting already (https://agendadulibre.qc.ca/events/2038),
where I presented my experience with building an OpenBSD based home
router and we had a round table of discussion on BSD systems in
general. Including me and two work colleagues, we were 10 people
(I honestly thought nobody would come at first, so I'm happy!).
I'll post the slides online soon.

Format wise I'm thinking of holding it monthly, alternating
presentations and free sessions. Presentations can be given in the
language of your choice, but french is encouraged. Nothing is set
in stone yet, so we'll see how it evolves. I do need to create a
website, mailing list and caldav for it, but for now questions and
ideas for presentations can be sent to m...@patrickmarchand.com or
@mathuin@bsd.network (mastodon)

Au plaisir

Re: Home NAS

[Patrick Marchand]

Hi,


I'll be playing around with DragonflyBSD Hammer2 (and multiple offsite 
backups) for a home NAS over the next few weeks. I'll probably do a 
presentation about the experience at the Montreal BSD user group 
afterwards. It does not require as many ressources as ZFS or BTRFS, but 
offers many similar features.


As for OpenBSD as a home NAS, I'm sure it would be fine if you're 
diligent about backups. You might also want to get a small UPS for it (I 
bought a refurbished APC for 80$), so frequent but short power 
interruptions do not require an FFS integrity check. (I do this for my 
router)


Pleasure

Re: OpenBSD -current on T495

[Patrick Wildt]

On Sat, Nov 09, 2019 at 12:08:35PM +0100, Thomas de Grivel wrote:
> Everything works except wifi, suspend/resume and screen backlight, and
> mute speakers button.

Hi,

I have an X395 which is basically the same machine.

For Wifi I have temporarily replaced the Intel WiFi with a bwfm(4), the
Dell Wireless DW1820a (note the a), which has two antenna connectors.
There's the DW1830 which has three.  My X395 has two connectors, so I
just put in the DW1820a.  Both can be purchased cheaply on eBay.

The mute speaker button works for me, but the light doesn't show up.

I will try to have a look at suspend/resume at one of the next OpenBSD
hackathons.

For the screen backlight I have come up with a diff, but it's not yet
ready to be committed, as it should be done in a different fashion.
Still, I have attached the diff if you want to give it a go.

Patrick

diff --git a/sys/dev/acpi/acpivideo.c b/sys/dev/acpi/acpivideo.c
index 9498465a418..a46a99a67f7 100644
--- a/sys/dev/acpi/acpivideo.c
+++ b/sys/dev/acpi/acpivideo.c
@@ -149,7 +149,7 @@ acpi_foundvout(struct aml_node *node, void *arg)
if (node->parent != sc->sc_devnode)
return (0);
 
-   if (aml_searchname(node, "_BCM") && aml_searchname(node, "_BQC")) {
+   if (aml_searchname(node, "_BCM")) {
memset(, 0, sizeof(aaa));
aaa.aaa_iot = sc->sc_acpi->sc_iot;
aaa.aaa_memt = sc->sc_acpi->sc_memt;
diff --git a/sys/dev/acpi/acpivout.c b/sys/dev/acpi/acpivout.c
index 5fb6973f595..b1957b0c652 100644
--- a/sys/dev/acpi/acpivout.c
+++ b/sys/dev/acpi/acpivout.c
@@ -60,6 +60,7 @@ struct acpivout_softc {
 
int *sc_bcl;
size_t  sc_bcl_len;
+   int sc_bcl_cur;
 };
 
 void   acpivout_brightness_cycle(struct acpivout_softc *);
@@ -113,10 +114,16 @@ acpivout_attach(struct device *parent, struct device 
*self, void *aux)
aml_register_notify(sc->sc_devnode, aaa->aaa_dev,
acpivout_notify, sc, ACPIDEV_NOPOLL);
 
+   acpivout_get_bcl(sc);
+   if (!sc->sc_bcl_len)
+   return;
+
+   sc->sc_bcl_cur = sc->sc_bcl[sc->sc_bcl_len - 1];
+   sc->sc_bcl_cur = acpivout_get_brightness(sc);
+   acpivout_set_brightness(sc, sc->sc_bcl_cur);
+
ws_get_param = acpivout_get_param;
ws_set_param = acpivout_set_param;
-
-   acpivout_get_bcl(sc);
 }
 
 int
@@ -130,12 +137,15 @@ acpivout_notify(struct aml_node *node, int notify, void 
*arg)
break;
case NOTIFY_BRIGHTNESS_UP:
acpivout_brightness_step(sc, 1);
+   wsdisplay_change_brightness(1);
break;
case NOTIFY_BRIGHTNESS_DOWN:
acpivout_brightness_step(sc, -1);
+   wsdisplay_change_brightness(-1);
break;
case NOTIFY_BRIGHTNESS_ZERO:
acpivout_brightness_zero(sc);
+   wsdisplay_change_brightness(0);
break;
case NOTIFY_DISPLAY_OFF:
/* TODO: D3 state change */
@@ -200,7 +210,9 @@ acpivout_get_brightness(struct acpivout_softc *sc)
struct aml_value res;
int level;
 
-   aml_evalname(sc->sc_acpi, sc->sc_devnode, "_BQC", 0, NULL, );
+   if (aml_evalname(sc->sc_acpi, sc->sc_devnode, "_BQC", 0, NULL, ))
+   return sc->sc_bcl_cur;
+
level = aml_val2int();
aml_freevalue();
DPRINTF(("%s: BQC = %d\n", DEVNAME(sc), level));
@@ -242,6 +254,7 @@ acpivout_set_brightness(struct acpivout_softc *sc, int 
level)
aml_evalname(sc->sc_acpi, sc->sc_devnode, "_BCM", 1, , );
 
aml_freevalue();
+   sc->sc_bcl_cur = level;
 }
 
 void
diff --git a/sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c 
b/sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c
index 02a90069f8d..4bad51b7d5f 100644
--- a/sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c
+++ b/sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c
@@ -1656,7 +1656,7 @@ amdgpu_wsioctl(void *v, u_long cmd, caddr_t data, int 
flag, struct proc *p)
case WSDISPLAYIO_PARAM_BRIGHTNESS:
dp->min = 0;
dp->max = bd->props.max_brightness;
-   dp->curval = bd->ops->get_brightness(bd);
+   dp->curval = bd->props.brightness;
return (dp->max > dp->min) ? 0 : -1;
}
break;
diff --git a/sys/dev/wscons/wsdisplay.c b/sys/dev/wscons/wsdisplay.c
index 61ccd2dae43..eda5c9d8843 100644
--- a/sys/dev/wscons/wsdisplay.c
+++ b/sys/dev/wscons/wsdisplay.c
@@ -3369,3 +3369,43 @@ mouse_remove(struct wsscreen *scr)
 }
 
 #endif /* HAVE_WSMOUSED_SUPPORT */
+
+int
+wsdisplay_change_brightness(int dir)
+{
+   struct wsdisplay_softc *sc;
+   struct wsdisplay_param dp;
+   int step, ret;
+
+   sc = (struct wsdispla

Re: Broadcom firmwares and nvram files

[Patrick Wildt]

On Sun, Nov 03, 2019 at 10:05:38AM +0100, Patrick Wildt wrote:
> On Sun, Nov 03, 2019 at 12:08:08AM +0100, Stefano Enrico Mendola wrote:
> > Hi,
> > 
> > my bad, I thought the grepped output was enough.
> > Here's the complete dmesg(8) output. =
> > OpenBSD 6.6 (GENERIC.MP) #372: Sat Oct 12 10:56:27 MDT 2019
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 2056568832 (1961MB)
> > avail mem = 1981595648 (1889MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7c31a010 (16 entries)
> > bios0: vendor American Megatrends Inc. version "X205TA.212" date
> > 09/04/2015
> > bios0: ASUSTeK COMPUTER INC. X205TA
> > acpi0 at bios0: ACPI 5.0
> > acpi0: sleep states S0 S5
> > acpi0: tables DSDT FACP TCPA UEFI OEM0 DBG2 HPET LPIT APIC MCFG SSDT SSDT
> > SSDT SSDT FPDT SSDT SSDT SSDT SSDT TPM2 BGRT CSRT MSDM
> > acpi0: wakeup devices WLAN(S0)
> > acpihpet0 at acpi0: 14318179 Hz
> > acpimadt0 at acpi0 addr 0xfee0
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.58 MHz, 06-37-08
> > cpu0:
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> > cpu0: 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 83MHz
> > cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
> > cpu1 at mainbus0: apid 2 (application processor)
> > cpu1: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.33 MHz, 06-37-08
> > cpu1:
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> > cpu1: 1MB 64b/line 16-way L2 cache
> > cpu1: smt 0, core 1, package 0
> > cpu2 at mainbus0: apid 4 (application processor)
> > cpu2: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz, 06-37-08
> > cpu2:
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> > cpu2: 1MB 64b/line 16-way L2 cache
> > cpu2: smt 0, core 2, package 0
> > cpu3 at mainbus0: apid 6 (application processor)
> > cpu3: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz, 06-37-08
> > cpu3:
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> > cpu3: 1MB 64b/line 16-way L2 cache
> > cpu3: smt 0, core 3, package 0
> > ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 87 pins, remapped
> > acpimcfg0 at acpi0
> > acpimcfg0: addr 0xe000, bus 0-255
> > acpiprt0 at acpi0: bus 0 (PCI0)
> > acpiec0 at acpi0: not present
> > acpicpu0 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x51),
> > C1(1000@1 mwait.1), PSS
> > acpicpu1 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x51),
> > C1(1000@1 mwait.1), PSS
> > acpicpu2 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x51),
> > C1(1000@1 mwait.1), PSS
> > acpicpu3 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x51),
> > C1(1000@1 mwait.1), PSS
> > acpipwrres0 at acpi0: PLPE
> > acpipwrres1 at acpi0: USBC, resource for XHC1, EHC1, OTG1
> > acpipwrres2 at acpi0: CLK0, resource for CAM1
> > acpipwrres3 at acpi0: CLK1, resource for CAM0
> > acpipwrres4 at acpi0: P28X
> > acpipwrres5 at acpi0: P18X
> > acpipwrres6 at acpi0: P28P
> > acpipwrres7 at acpi0: P18P
> > acpipwrres8 at acpi0: P28T, resource for CAM0, CAM1
> > acpipwrres9 at acpi0: P18T, resource for CAM0, CAM1
> > acpipwrres10 at acpi0: P1XT
> > acpitz0 at acpi0: no critical temperature

Re: Broadcom firmwares and nvram files

[Patrick Wildt]

emulation)
> bwfm0: failed loadfirmware of file brcmfmac43340-sdio.nvram
> = Sent: Saturday, November 02, 2019 at 11:54
> PM
> From: "Brad Smith" 
> To: "Stefano Enrico Mendola" 
> Subject: Re: Broadcom firmwares and nvram filesPost a dmesg from the
> system if you want people to help you.
> 
> On 11/2/2019 6:50 PM, Stefano Enrico Mendola wrote:
> > Hi Folks,
> > A friend of mine gave me an Asus X250TA to use as a low-power home
> > server.
> > I don't want to waste any of the two USB2 ports for an USB-Ethernet
> > adaptor,
> > but I'd like to use the integrated wifi module instead.
> >
> > After launching fw_update(1) using an USB tethered connection,
> > the firmware gets installed, but it's apparently lacking a .nvram file.
> > Here's the error I'm getting:
> >
> > $ dmesg | grep brcmbwfm0: failed loadfirmware of file
> > brcmfmac43340-sdio.nvram The nvram(4) man page is not even that helpful
> > in this case.
> > I don't think the OpenBSD philosophy is to throw partially working
> > firmwares in the repos,
> > so I think the problem could be related to something else, but I have
> no
> > clue what this
> > something else could be.
> >
> > Also, the firmware repository does not contain any .nvram file, which
> > makes me doubteven more that the problem is related to something
> > partially supported.
> >
> > Any ideas? Best regards
> > Stefano

Hi,

all of the SDIO connected chips need an NVRAM, which can not be provided
by the firmware image, since it really is a per-device setting.  So one
could start collecting them, but I'm not sure if that would lead to
covering most of the machines.  Maybe we could cover at least those that
complained...

Anyway, it looks like your NVRAM is stored in a specific EFI variable,
like it is on some other x86 machines, and since we unfortunately have
no support for reading EFI variables yet, you will need to use Linux for
retrieving the file.

mount -t efivarfs efivarfs /sys/firmware/efi/efivars
cp /sys/firmware/efi/efivars/nvram-74b00bd9-805a-4d61-b51f-43268123d113 
/some/external/stick/brcmfmac43340-sdio.txt

I have attached a program that converts that text file into the nvram
file:

cc -o nvram nvram.c
./nvram brcmfmac43340-sdio.txt brcmfmac43340-sdio.nvram

And that's the file you can then put into /etc/firmware to finally use
your bwfm(4) device!

Patrick

Re: Display flickers after upgrade to 6.6

[Patrick Harper]

I can confirm that switching to EXA made GNOME usable. This'll only work up to 
Northern Islands cards/IGPs though.

Guess I'll be holding off of a GPU upgrade for a while longer.

-- 
  Patrick Harper
  paia...@fastmail.com

On Thu, 31 Oct 2019, at 13:47, Patrick Harper wrote:
> I haven't tried those settings yet (in my case GNOME Shell and 
> Xfdashboard cause the display to corrupt and seize up except the 
> cursor) but ShadowPrimary is a glamor option that should be irrelevant 
> if EXA is used.
> 
> For years I've also observed text flickering in the console after drm 
> is loaded, but in 6.5 and prior 3D-accelerated stuff was usable. Cayman 
> should be fine with 8 million pixels.
> 
> -- 
>   Patrick Harper
>   paia...@fastmail.com
> 
> On Wed, 30 Oct 2019, at 13:12, Jeff wrote:
> > On Sat, 19 Oct 2019 17:59:41 +0200
> > Federico Giannici  wrote:
> > 
> > > On 2019-10-19 16:17, Andre Stoebe wrote:
> > > > Hi,
> > > > 
> > > > I ran into the same issue this morning. Disabling the compositor
> > > > worked for me, but I noticed later that this is also documented in
> > > > the package readme:
> > > > 
> > > > Screen compositor
> > > > =
> > > > If you're using the modesetting X driver and experience window
> > > > flickering when
> > > > the compositor is enabled, you should force the window manager to
> > > > use the XPresent method for vblank:
> > > > 
> > > > $xfwm4 --vblank=xpresent --replace &  
> > > 
> > > I tried that command but it screwed all my windows (no more window 
> > > decorations and buttons, I cannot operate on windows)!
> > > Now I had to came back to KDE...
> > > :-(
> > > 
> > > Regards
> > > 
> > > 
> > > > This is documented upstream at
> > > > https://git.xfce.org/xfce/xfwm4/tree/COMPOSITOR#n114
> > > > 
> > > > Haven't tested that yet and left the compositor disabled, but I
> > > > guess this will fix your issues. If it does, that's probably a good
> > > > reminder to first look in the readme next time (me included). ;)
> > > > 
> > > > Regards,
> > > > André
> > > >   
> > 
> > Hi, I thought I'd relate my experience: I also experienced this issue on
> > a machine recently upgraded to OpenBSD 6.6 which uses the aruba
> > chipset and also running xfce.  My workaround
> > (which was based on 'try stuff to see what works') involved turning off
> > compositing and
> > (via xorg.conf.d):
> > 
> > ...
> > Option "AccelMethod" "EXA"
> > Option "ShadowPrimary" "on"
> > Option "SwapbuffersWait" "off"
> > Option "EnablePageFlip" "off"
> > ...
> > 
> > This resolved issues with flickering, the mouse pointer vanishing and
> > re-appearing depending on which window is below the pointer (enabling
> > software mouse pointer for this was worse as garbage was rendered in a
> > rect surrounding the pointer), and also *some* issues with logging
> > in-out of an X session via xenodm.
> > 
> > I still experience problems with the machine going to sleep and waking
> > up, as sometimes, upon wake-up, the graphics go wonky, or don't update
> > at all, or the mouse pointer goes wonky.
> > 
> > Beyond the aforementioned, this set-up seems to allow me to use the
> > machine as before, however, I am not an X11 expert nor a radeondrm
> > driver expert; your mileage may very.
> > 
> > If I ever try Andre's hint in the future (thank-you), I might report on
> > success/failure.
> > 
> > regards,
> > 
> > Jeff
> > 
> >
> 
>

Suspend on Dell Inspiron 6000

[Patrick Coppock]

Hi, All:

I am new to OpenBSD; I recently installed 6.5 on a Dell Inspiron 6000
and upgraded to 6.6 yesterday. Suspend did not work in 6.5 and still
doesn't in 6.6.

What is the best way for me to go about debugging this issue? So far,
I have checked:
- dmesg for ACPI wake devices
- syslog for suspend messages

Specifically, the suspend works; however, when I attempt to wake the
device, the laptop seems to respond and attempt to wake, but the
display never turns on, and I cannot SSH into the machine. Below are
the dmesg and relevant syslog entries.

dmesg
=

OpenBSD 6.6 (GENERIC) #0: Sat Oct 26 05:57:51 MDT 2019
r...@syspatch-66-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 527790080 (503MB)
avail mem = 502480896 (479MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 09/28/05, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 
0xf80e0 (44 entries)
bios0: vendor Dell Inc. version "A09" date 09/28/2005
bios0: Dell Inc. Inspiron 6000
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG BOOT SSDT SSDT
acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) USB0(S0) USB1(S0) USB2(S0) 
USB4(S0) USB3(S0) MODM(S3) PCIE(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) M processor 1.30GHz ("GenuineIntel" 686-class) 1.30 
GHz, 06-0d-06
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,PERF,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimcfg0: addr 0x0, bus 0-0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 3 (PCIE)
acpicpu0 at acpi0: !C3(250@85 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1 halt)
acpitz0 at acpi0: critical temperature is 99 degC
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "DELL F51336" serial 1988 type LION oem "Sanyo"
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PBTN
acpibtn2 at acpi0: SBTN
"PNP0A03" at acpi0 not configured
acpicmos0 at acpi0
acpivideo0 at acpi0: VID_
acpivideo1 at acpi0: VID_
acpivideo2 at acpi0: VID2
bios0: ROM list: 0xc/0xf800! 0xcf800/0x800
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82915GM Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel 82915GM Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xc000, size 0x1000
inteldrm0: apic 1 int 16
"Intel 82915GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: apic 1 int 16
uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x03: apic 1 int 17
uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x03: apic 1 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x03: apic 1 int 19
ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x03: apic 1 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
ppb0 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xd3
pci1 at ppb0 bus 3
bce0 at pci1 dev 0 function 0 "Broadcom BCM4401B1" rev 0x02: apic 1 int 18, 
address 00:11:43:70:7f:12
bmtphy0 at bce0 phy 1: BCM4401 10/100baseTX PHY, rev. 0
cbb0 at pci1 dev 1 function 0 "Ricoh 5C476 CardBus" rev 0xb3: apic 1 int 19
"Ricoh 5C552 Firewire" rev 0x08 at pci1 dev 1 function 1 not configured
sdhc0 at pci1 dev 1 function 2 "Ricoh 5C822 SD/MMC" rev 0x17: apic 1 int 17
sdhc0: SDHC 1.0, 33 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
bwi0 at pci1 dev 3 function 0 "Broadcom BCM4306" rev 0x03: apic 1 int 17, 
address 00:0b:7d:15:3a:24
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 4 device 0 cacheline 0x0, lattimer 0x20
pcmcia0 at cardslot0
auich0 at pci0 dev 30 function 2 "Intel 82801FB AC97" rev 0x03: apic 1 int 16, 
ICH6
ac97: codec id 0x83847652 (SigmaTel STAC9752/53)
ac97: codec features headphone, 20 bit DAC, 20 bit ADC, SigmaTel 3D
audio0 at auich0
"Intel 82801FB Modem" rev 0x03 at pci0 dev 30 function 3 not configured
ichpcib0 at pci0 dev 31 function 0 "Intel 82801FBM LPC" rev 0x03: PM disabled
pciide0 at pci0 dev 31 function 2 "Intel 82801FBM SATA" rev 0x03: DMA, channel 
0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA, 28615MB, 58605120 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 

Re: Display flickers after upgrade to 6.6

[Patrick Harper]

I haven't tried those settings yet (in my case GNOME Shell and Xfdashboard 
cause the display to corrupt and seize up except the cursor) but ShadowPrimary 
is a glamor option that should be irrelevant if EXA is used.

For years I've also observed text flickering in the console after drm is 
loaded, but in 6.5 and prior 3D-accelerated stuff was usable. Cayman should be 
fine with 8 million pixels.

-- 
  Patrick Harper
  paia...@fastmail.com

On Wed, 30 Oct 2019, at 13:12, Jeff wrote:
> On Sat, 19 Oct 2019 17:59:41 +0200
> Federico Giannici  wrote:
> 
> > On 2019-10-19 16:17, Andre Stoebe wrote:
> > > Hi,
> > > 
> > > I ran into the same issue this morning. Disabling the compositor
> > > worked for me, but I noticed later that this is also documented in
> > > the package readme:
> > > 
> > > Screen compositor
> > > =
> > > If you're using the modesetting X driver and experience window
> > > flickering when
> > > the compositor is enabled, you should force the window manager to
> > > use the XPresent method for vblank:
> > > 
> > > $xfwm4 --vblank=xpresent --replace &  
> > 
> > I tried that command but it screwed all my windows (no more window 
> > decorations and buttons, I cannot operate on windows)!
> > Now I had to came back to KDE...
> > :-(
> > 
> > Regards
> > 
> > 
> > > This is documented upstream at
> > > https://git.xfce.org/xfce/xfwm4/tree/COMPOSITOR#n114
> > > 
> > > Haven't tested that yet and left the compositor disabled, but I
> > > guess this will fix your issues. If it does, that's probably a good
> > > reminder to first look in the readme next time (me included). ;)
> > > 
> > > Regards,
> > > André
> > >   
> 
> Hi, I thought I'd relate my experience: I also experienced this issue on
> a machine recently upgraded to OpenBSD 6.6 which uses the aruba
> chipset and also running xfce.  My workaround
> (which was based on 'try stuff to see what works') involved turning off
> compositing and
> (via xorg.conf.d):
> 
> ...
> Option "AccelMethod" "EXA"
> Option "ShadowPrimary" "on"
> Option "SwapbuffersWait" "off"
> Option "EnablePageFlip" "off"
> ...
> 
> This resolved issues with flickering, the mouse pointer vanishing and
> re-appearing depending on which window is below the pointer (enabling
> software mouse pointer for this was worse as garbage was rendered in a
> rect surrounding the pointer), and also *some* issues with logging
> in-out of an X session via xenodm.
> 
> I still experience problems with the machine going to sleep and waking
> up, as sometimes, upon wake-up, the graphics go wonky, or don't update
> at all, or the mouse pointer goes wonky.
> 
> Beyond the aforementioned, this set-up seems to allow me to use the
> machine as before, however, I am not an X11 expert nor a radeondrm
> driver expert; your mileage may very.
> 
> If I ever try Andre's hint in the future (thank-you), I might report on
> success/failure.
> 
> regards,
> 
> Jeff
> 
>

Re: Softraid data recovery

[Patrick Dohman]

> On Oct 14, 2019, at 3:04 PM, Steven Surdock wrote:
> 
> root@host# more /var/backups/disklabel.sd1.backup
> # /dev/rsd1c:
> type: SCSI
> disk: SCSI disk
> label: SR RAID 1
> duid: 8ec2330eabf7cd26
> flags:
> bytes/sector: 512
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 486401
> total sectors: 7814036576
> boundstart: 64
> boundend: 7814036576
> drivedata: 0
> 
> 16 partitions:
> #size   offset  fstype [fsize bsize   cpg]
>  a:   2147488704   64  4.2BSD   8192 65536 1 # 
> /home/public/
>  c:   78140365760  unused
>  d:   5666547712   2147488768  4.2BSD   8192 65536 1 # 
> /home/Backups/
> 


A combination of revised partition lettering & a custom fstab may allow for 
mounting of the partitions without a software device.

For example:

$cat /etc/fstab
/dev/wd0a  /home ffs rw,nodev,nosuid 1 2
/dev/wd0d  /home/Backups/ ffs rw,nodev,nosuid 1 2

The device naming may take some massaging to work...
man fstab & disklabel for more info.

Regards
Patrick

HTTPD directory index

[Patrick Dohman]

Hoping to clarify if OpenBSD HTTPD supports index.html & index.php 
simultaneously?
The following config appears to be supported:

# A minimal default server
server "default" {
listen on $ext_addr port 80
directory { index "index.html" }
location "/*.php*" {
root { "/htdocs" }
fastcgi socket "/run/php-fpm.sock"}

However different varieties of the following directive:

directory { index “index.html”, index “index.php”} or { index “index.html”, 
“index.php”}

Results in either a successful reload or the following syntax error:

httpd[35299]: parent_sig_handler: reload requested with SIGHUP
httpd[35299]: /etc/httpd.conf:20: syntax error
httpd[35299]: no actions, nothing to do

Regards
Patrick

Re: Cannot add login class (ports/meta/gnome/pkg/README-main)

[Patrick Harper]

Adding an empty line at the end of login.conf fixed my problem.

-- 
  Patrick Harper
  paia...@fastmail.com

On Tue, 17 Sep 2019, at 14:21, Patrick Harper wrote:
> Hi All,
> 
> For a while this file has instructed a new login class to be added to 
> the end of /etc/login.conf, as per below.
> 
> gnome:\
>   :datasize-cur=1024M:\
>   :tc=default:
> 
> On both my amd64 machines, this does not effectuate following a reboot. 
> If I try to create a new user in the class with adduser and try to 
> specify gnome,
> 
> gnome: is not allowed!
> 
> is printed. gnome is not listed in the 'Default login class list' 
> either. If I use the usermod command as written in the readme,
> 
> usermod: No such login class `gnome'
> 
> is printed.
> 
> If I try to force the gnome class by editing the chpass database for 
> the user and rebooting, users will appear on the gdm greeter but it is 
> impossible to login to them. Users created through the GNOME Settings 
> are added to the default class and are also impossible to login to, I 
> think because the password encoding is different.
> 
> My workaround for now is to use the 'staff' login class, which seems to 
> have resource limits high enough for gnome to work, although it is "not 
> recommended". With this setup there is a functionality issue - logging 
> out through the UI causes gdm to exit to the console (although the 
> daemon seems to continue running), whereas it should display the gdm 
> greeter. Whether or not this is a byproduct of the staff class settings 
> I don't know.
> 
> -- 
>   Patrick Harper
>   paia...@fastmail.com
> 
>

Re: Cannot add login class (ports/meta/gnome/pkg/README-main)

[Patrick Harper]

I'm using 6.5-stable including the binary package updates.

-- 
  Patrick Harper
  paia...@fastmail.com

On Tue, 17 Sep 2019, at 14:21, Patrick Harper wrote:
> Hi All,
> 
> For a while this file has instructed a new login class to be added to 
> the end of /etc/login.conf, as per below.
> 
> gnome:\
>   :datasize-cur=1024M:\
>   :tc=default:
> 
> On both my amd64 machines, this does not effectuate following a reboot. 
> If I try to create a new user in the class with adduser and try to 
> specify gnome,
> 
> gnome: is not allowed!
> 
> is printed. gnome is not listed in the 'Default login class list' 
> either. If I use the usermod command as written in the readme,
> 
> usermod: No such login class `gnome'
> 
> is printed.
> 
> If I try to force the gnome class by editing the chpass database for 
> the user and rebooting, users will appear on the gdm greeter but it is 
> impossible to login to them. Users created through the GNOME Settings 
> are added to the default class and are also impossible to login to, I 
> think because the password encoding is different.
> 
> My workaround for now is to use the 'staff' login class, which seems to 
> have resource limits high enough for gnome to work, although it is "not 
> recommended". With this setup there is a functionality issue - logging 
> out through the UI causes gdm to exit to the console (although the 
> daemon seems to continue running), whereas it should display the gdm 
> greeter. Whether or not this is a byproduct of the staff class settings 
> I don't know.
> 
> -- 
>   Patrick Harper
>   paia...@fastmail.com

Cannot add login class (ports/meta/gnome/pkg/README-main)

[Patrick Harper]

Hi All,

For a while this file has instructed a new login class to be added to the end 
of /etc/login.conf, as per below.

gnome:\
:datasize-cur=1024M:\
:tc=default:

On both my amd64 machines, this does not effectuate following a reboot. If I 
try to create a new user in the class with adduser and try to specify gnome,

gnome: is not allowed!

is printed. gnome is not listed in the 'Default login class list' either. If I 
use the usermod command as written in the readme,

usermod: No such login class `gnome'

is printed.

If I try to force the gnome class by editing the chpass database for the user 
and rebooting, users will appear on the gdm greeter but it is impossible to 
login to them. Users created through the GNOME Settings are added to the 
default class and are also impossible to login to, I think because the password 
encoding is different.

My workaround for now is to use the 'staff' login class, which seems to have 
resource limits high enough for gnome to work, although it is "not 
recommended". With this setup there is a functionality issue - logging out 
through the UI causes gdm to exit to the console (although the daemon seems to 
continue running), whereas it should display the gdm greeter. Whether or not 
this is a byproduct of the staff class settings I don't know.

-- 
  Patrick Harper
  paia...@fastmail.com

Re: What is you motivational to use OpenBSD

[Patrick Harper]

What motivates me to stay on OpenBSD is that I want the free desktop concept to 
work. This system + Arcan + GNOME-like interface seems, to me, like an 
compelling way to get there. I hope I can shoehorn this project into my life 
and then reality in some fashion.

-- 
  Patrick Harper
  paia...@fastmail.com

On Wed, 28 Aug 2019, at 15:32, Mohamed salah wrote:
> I wanna put something in discussion, what's your motivational to use
> OPENBSD what not other bsd's what not gnu/Linux, if something doesn't work
> fine on openbsd and you love this os so much what will do?
>

Re: [OpenIKED] Network traffic over VPN site-to-site tunnel stalls few times a day

[Patrick Dohman]

Radek
In my opinion upstream DNS & UDP issues can cause interrupts with some ISP's.
I also believe that defining specific proto's in your nat rule can decrease 
interrupts. 
You might consider the following to modification to your nat rule to 
specificity allow UDP & ICMP.

match out log on $ext_if inet proto { tcp, udp, icmp } rom { $lan_rac_local, 
$backup_local } nat-to $ext_if set prio (3, 7)

It appears that you have ICMP allow rules which is a good idea in my opinion.
Have you ever done any logging of these packets. Is there any legitimate 
requests from your ISP?
Do you have an alternate DNS server you can test against? Are you using your 
ISP’s DNS?
Perhaps the new OpenBSD unwind package is worth investigating ;)
]Regards
Patrick

> On Aug 25, 2019, at 1:31 PM, Radek  wrote:
> 
> Hello Patrick, 
> 
>> In my opinion your net5501’s system calls per interval are relatively high.
>> The (traps sys) column on my firewall hovers between 40 & 50 quite 
>> consistently.
>> My understanding is that system calls are things like program calls & 
>> library access.
> Is there any way to decrease these values?
> 
>> Many commercial routers run a customized kernel & rely on a striped down 
>> user-land.
>> The kernel is also recompiled to run TCP/IP4 only & can no longer execute 
>> things like storage or virtualization.
>> The OpenBSD O.S includes all the user-land tools such as ping & top in 
>> addition to a standardized precompiled kernel. 
> Ok, I get it.
> 
> 
> On Fri, 23 Aug 2019 21:12:35 -0500
> Patrick Dohman  wrote:
> 
>> In my opinion your net5501’s system calls per interval are relatively high.
>> The (traps sys) column on my firewall hovers between 40 & 50 quite 
>> consistently.
>> My understanding is that system calls are things like program calls & 
>> library access.
>> 
>> In addition your net5501’s memory requests per second seem heavy.
>> You have fifty eight million 1024 bucket requests per second.
>> My firewall has a max of one hundred thousand 128 bucket requests per second.
>> 
>> Many commercial routers run a customized kernel & rely on a striped down 
>> user-land.
>> The kernel is also recompiled to run TCP/IP4 only & can no longer execute 
>> things like storage or virtualization.
>> The OpenBSD O.S includes all the user-land tools such as ping & top in 
>> addition to a standardized precompiled kernel. 
>> Regards
>> Patrick
>> .
>>> 
>>> 
>>> On Thu, 22 Aug 2019 19:12:55 -0500
>>> Patrick Dohman  wrote:
>>> 
>>>> Radek
>>>> 
>>>> I’ve found that fast networking is actually CPU & memory intensive. 
>>>> Pentium 4 and Xeon's are increasingly a necessity for stable firewalls in 
>>>> my opinion.
>>>> Keep in mind OpenBSD is a monolithic kernel & isn’t a one to one ratio 
>>>> with a commercial router.
>>>> 
>>>> What are your context switches & interrupts doing while the VPN is up & 
>>>> traffic is flowing?
>>>> 
>>>> vmstat -w 4
>>>> 
>>>> What is your memory high water mark during a peak traffic?
>>>> 
>>>> vmstat -m
>>>> 
>>>> Regards
>>>> Patrick
>>>> 
>>>>> On Aug 21, 2019, at 12:34 AM, radek  wrote:
>>>>> 
>>>>> Hello Patrick,
>>>>> I am sorry for the late reply.
>>>>> 
>>>>>> Do you consider memory an issue?
>>>>> No, I do not. I have a bunch of old Soekris/net5501-70 and ALIX2d2/2d3, 
>>>>> that I use for VPN testing.
>>>>> Current testing set (6.5/i386) is net5501-70 <-> ALIX2d3
>>>>> Production set (6.3/i386) is net5501-70 <-> ALIX2d2
>>>>> Also have tried net5501-70 <-> net5501-70 - the same VPN problem occurs
>>>>> It is unlikely that every box has any hardware issue.
>>>>> 
>>>>>> Unix load average can occasionally be deceiving.
>>>>> I did not know.
>>>>> 
>>>>>  net5501-70 
>>>>> $top -d1 | head -n 4
>>>>> load averages:  0.05,  0.01,  0.00RAC-fw65-test.PRAC 10:58:14
>>>>> 38 processes: 1 running, 35 idle, 1 dead, 1 on processor  up 3 days, 18:02
>>>>> CPU states:  0.5% user,  0.0% nice,  0.4% sys,  0.0% spin,  0.2% intr, 
>>>>> 98.8% idle
>>>>> Memory: Real: 18M/267M act/tot Free: 222M Cache: 97M Swap: 0K/256M
>>&

Re: [OpenIKED] Network traffic over VPN site-to-site tunnel stalls few times a day

[Patrick Dohman]

In my opinion your net5501’s system calls per interval are relatively high.
The (traps sys) column on my firewall hovers between 40 & 50 quite consistently.
My understanding is that system calls are things like program calls & library 
access.

In addition your net5501’s memory requests per second seem heavy.
You have fifty eight million 1024 bucket requests per second.
My firewall has a max of one hundred thousand 128 bucket requests per second.

Many commercial routers run a customized kernel & rely on a striped down 
user-land.
The kernel is also recompiled to run TCP/IP4 only & can no longer execute 
things like storage or virtualization.
The OpenBSD O.S includes all the user-land tools such as ping & top in addition 
to a standardized precompiled kernel. 
Regards
Patrick
.
> 
> 
> On Thu, 22 Aug 2019 19:12:55 -0500
> Patrick Dohman  wrote:
> 
>> Radek
>> 
>> I’ve found that fast networking is actually CPU & memory intensive. 
>> Pentium 4 and Xeon's are increasingly a necessity for stable firewalls in my 
>> opinion.
>> Keep in mind OpenBSD is a monolithic kernel & isn’t a one to one ratio with 
>> a commercial router.
>> 
>> What are your context switches & interrupts doing while the VPN is up & 
>> traffic is flowing?
>> 
>> vmstat -w 4
>> 
>> What is your memory high water mark during a peak traffic?
>> 
>> vmstat -m
>> 
>> Regards
>> Patrick
>> 
>>> On Aug 21, 2019, at 12:34 AM, radek  wrote:
>>> 
>>> Hello Patrick,
>>> I am sorry for the late reply.
>>> 
>>>> Do you consider memory an issue?
>>> No, I do not. I have a bunch of old Soekris/net5501-70 and ALIX2d2/2d3, 
>>> that I use for VPN testing.
>>> Current testing set (6.5/i386) is net5501-70 <-> ALIX2d3
>>> Production set (6.3/i386) is net5501-70 <-> ALIX2d2
>>> Also have tried net5501-70 <-> net5501-70 - the same VPN problem occurs
>>> It is unlikely that every box has any hardware issue.
>>> 
>>>> Unix load average can occasionally be deceiving.
>>> I did not know.
>>> 
>>>  net5501-70 
>>> $top -d1 | head -n 4
>>> load averages:  0.05,  0.01,  0.00RAC-fw65-test.PRAC 10:58:14
>>> 38 processes: 1 running, 35 idle, 1 dead, 1 on processor  up 3 days, 18:02
>>> CPU states:  0.5% user,  0.0% nice,  0.4% sys,  0.0% spin,  0.2% intr, 
>>> 98.8% idle
>>> Memory: Real: 18M/267M act/tot Free: 222M Cache: 97M Swap: 0K/256M
>>> 
>>>  ALIX2d3 
>>> $top -d1 | head -n 4
>>> load averages:  0.00,  0.00,  0.00mon65.home 07:30:05
>>> 37 processes: 1 running, 35 idle, 1 on processor  up 13:46
>>> CPU states:  0.3% user,  0.0% nice,  1.1% sys,  0.0% spin,  0.4% intr, 
>>> 98.3% idle
>>> Memory: Real: 125M/223M act/tot Free: 14M Cache: 47M Swap: 73M/256M
>>> 
>>> 
>>> 
>>>> What is the speed of your memory?
>>>> What make of Ethernets are you running?
>>> Dmesgs below
>>> 
>>>  net5501-70 
>>> OpenBSD 6.5 (GENERIC) #2: Tue Jul 23 23:08:46 CEST 2019
>>>   r...@syspatch-65-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
>>> real mem  = 536363008 (511MB)
>>> avail mem = 511311872 (487MB)
>>> mpath0 at root
>>> scsibus0 at mpath0: 256 targets
>>> mainbus0 at root
>>> bios0 at mainbus0: date 20/80/26, BIOS32 rev. 0 @ 0xfac40
>>> pcibios0 at bios0: rev 2.0 @ 0xf/0x1
>>> pcibios0: pcibios_get_intr_routing - function not supported
>>> pcibios0: PCI IRQ Routing information unavailable.
>>> pcibios0: PCI bus #0 is the last bus
>>> bios0: ROM list: 0xc8000/0xa800
>>> cpu0 at mainbus0: (uniprocessor)
>>> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 
>>> 500 MHz, 05-0a-02
>>> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
>>> mtrr: K6-family MTRR support (2 registers)
>>> amdmsr0 at mainbus0
>>> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
>>> 0:20:0: io address conflict 0x6100/0x100
>>> 0:20:0: io address conflict 0x6200/0x200
>>> pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
>>> glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
>>> vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, 
>>> address 00:00:24:cb:4f:cc
>>> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
>>

Re: [OpenIKED] Network traffic over VPN site-to-site tunnel stalls few times a day

[Patrick Dohman]

Radek

I’ve found that fast networking is actually CPU & memory intensive. 
Pentium 4 and Xeon's are increasingly a necessity for stable firewalls in my 
opinion.
Keep in mind OpenBSD is a monolithic kernel & isn’t a one to one ratio with a 
commercial router.

What are your context switches & interrupts doing while the VPN is up & traffic 
is flowing?

vmstat -w 4

What is your memory high water mark during a peak traffic?

vmstat -m

Regards
Patrick

> On Aug 21, 2019, at 12:34 AM, radek  wrote:
> 
> Hello Patrick,
> I am sorry for the late reply.
> 
>> Do you consider memory an issue?
> No, I do not. I have a bunch of old Soekris/net5501-70 and ALIX2d2/2d3, that 
> I use for VPN testing.
> Current testing set (6.5/i386) is net5501-70 <-> ALIX2d3
> Production set (6.3/i386) is net5501-70 <-> ALIX2d2
> Also have tried net5501-70 <-> net5501-70 - the same VPN problem occurs
> It is unlikely that every box has any hardware issue.
> 
>> Unix load average can occasionally be deceiving.
> I did not know.
> 
>  net5501-70 
> $top -d1 | head -n 4
> load averages:  0.05,  0.01,  0.00RAC-fw65-test.PRAC 10:58:14
> 38 processes: 1 running, 35 idle, 1 dead, 1 on processor  up 3 days, 18:02
> CPU states:  0.5% user,  0.0% nice,  0.4% sys,  0.0% spin,  0.2% intr, 98.8% 
> idle
> Memory: Real: 18M/267M act/tot Free: 222M Cache: 97M Swap: 0K/256M
> 
>  ALIX2d3 
> $top -d1 | head -n 4
> load averages:  0.00,  0.00,  0.00mon65.home 07:30:05
> 37 processes: 1 running, 35 idle, 1 on processor  up 13:46
> CPU states:  0.3% user,  0.0% nice,  1.1% sys,  0.0% spin,  0.4% intr, 98.3% 
> idle
> Memory: Real: 125M/223M act/tot Free: 14M Cache: 47M Swap: 73M/256M
> 
> 
> 
>> What is the speed of your memory?
>> What make of Ethernets are you running?
> Dmesgs below
> 
>  net5501-70 
> OpenBSD 6.5 (GENERIC) #2: Tue Jul 23 23:08:46 CEST 2019
>r...@syspatch-65-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem  = 536363008 (511MB)
> avail mem = 511311872 (487MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 20/80/26, BIOS32 rev. 0 @ 0xfac40
> pcibios0 at bios0: rev 2.0 @ 0xf/0x1
> pcibios0: pcibios_get_intr_routing - function not supported
> pcibios0: PCI IRQ Routing information unavailable.
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xc8000/0xa800
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 
> 500 MHz, 05-0a-02
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
> mtrr: K6-family MTRR support (2 registers)
> amdmsr0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> 0:20:0: io address conflict 0x6100/0x100
> 0:20:0: io address conflict 0x6200/0x200
> pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
> glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
> vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address 
> 00:00:24:cb:4f:cc
> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> 0x004063, model 0x0034
> vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5, address 
> 00:00:24:cb:4f:cd
> ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> 0x004063, model 0x0034
> vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9, address 
> 00:00:24:cb:4f:ce
> ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> 0x004063, model 0x0034
> vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, address 
> 00:00:24:cb:4f:cf
> ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> 0x004063, model 0x0034
> glxpcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 
> 3579545Hz timer, watchdog, gpio, i2c
> gpio0 at glxpcib0: 32 pins
> iic0 at glxpcib0
> pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 
> wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0: 
> wd0: 1-sector PIO, LBA48, 7629MB, 15625216 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> pciide0: channel 1 ignored (disabled)
> ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 15, version 
> 1.0, legacy support
> ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 15
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00 
> addr 1
> isa0 at glxpcib0
> isadma0 at isa0
&

Re: Bluetooth support status

[patrick keshishian]

On Wed, Aug 7, 2019 at 10:40 AM Theo de Raadt  wrote:

> Wow, look -- more useless chatter on the topic.
>
> The bt stack we had was designed as "network code", and all sorts of
> complex layer violations and device hand-offs were very complicated and
> troublesome.
>
> The code was not deleted because bluetooth is shit.  The code was
> deleted *because it was shitty and unsuited to the purpose*
>
> And then noone stepped up to write new code.  THAT IS THE WHOLE STORY.
>
> People on misc often want some complicated conspiracy, and fails to
> understand it is ALWAYS that "someone has to write the code and maintain
> it", and if such a person doesn't exist then either (a) the code doesn't
> exist, or (b) the code sucks and people complain about it until (c) we
> delete it and then (d) people on misc try to invent fake history.
>
> Since no such person existed, (a) led to (c) and here we are at (d).
>
> I wish everyone would stop making uneducated guesses and trying to
> rewrite history that isn't STUDIED and understand.  In particular what
> bothers me is the LACK OF STUDY, but this is misc, STUDYING stuff is
> clearly too hard, and making uneducated guesses is the norm.
>

Might find following from "Axis of Easy #109" by Mark E. Jeftovic of
easyDNS:

Major bluetooth security flaw discovered.

Researchers at the Center for IT-Security, Privacy and Accountability
 (CISPA) have discovered a major new vulnerability in the 20+ year-old
Bluetooth protocol.  The “Key Negotiation of Bluetooth”, aka “KNOB” attack
lets attackers, without any prior knowledge of details of either side of
the conversation, trick two endpoints in a Bluetooth handshake into using
an encryption key that can then be brute-forced (I think they do this by
tricking each side into using a 1-byte encryption key).

Of course, once the key is cracked the attacker has access to all
communications on the Bluetooth channel.

The Bluetooth spec is being upgraded to specify longer encryption keys, and
users are urged to remain current with all manufacturer updates.

Read:
https://www.forbes.com/sites/zakdoffman/2019/08/15/critical-new-bluetooth-security-issue-leaves-your-devices-and-data-open-to-attack/
And: https://knobattack.com/


And if your "manufacturer" has EOLed your product, you're SOOL.
--patrick



> John Brahy  wrote:
>
> > Right, without reading the code and only reading this commit message
> it's all conjecture.
> > I was just hoping to hear something more if someone was inclined to
> share.
> >  inclined. The commit message seems like some sort of inside joke.
> >
> > Log message:
> > "It's not the years, honey; it's the mileage."
> >
> > bluetooth support doesn't work and isn't going anywhere. the current
> > design is a dead end, and should not be the basis for any future support.
> > general consensus says to whack it so as to not mislead the unwary.
> >
> > On Wed, Aug 7, 2019 at 10:06 AM Theo de Raadt 
> wrote:
> >
> >  Bryan Wright  wrote:
> >
> >  > Are there technical/philosophical problems that make all versions of
> >  > Bluetooth incompatible with the project, or is it a just matter of
> >  > removing what is not being maintained?
> >
> >  I'm sure a bunch of you can come up with theories about what actually
> >  transpired, without reading any of the code that used to be here, or
> >  the commit messages.
> >
> >  Basically, feel free to keep making up stuff.
> >
>
>

Re: [OpenIKED] Network traffic over VPN site-to-site tunnel stalls few times a day

[Patrick Dohman]

Do you consider memory an issue?
What is the speed of your memory?
Unix load average can occasionally be deceiving.
What make of Ethernets are you running?
Regards
Patrick

> On Aug 19, 2019, at 5:28 AM, radek  wrote:
> 
> Hello Patrick,
> 
>> Does your ISP implement authoritative DNS?
>> Do you suspect a UDP issue?
> My VPN is configured with IPs, not with domain names. Does DNS and/or UDP 
> matter anyway?
> 
>> Is a managed (switch) involved?
> No, it is not. I do not use any switches in my testing setup.
> GW1--ISP1_modem--.--ISP2_modem--GW2
> 
> Has duplex ever been an issue?
> I have never noticed any duplex issue.
> 
> 
> On Sun, 18 Aug 2019 16:07:14 -0500
> Patrick Dohman  wrote:
> 
>> Does your ISP implement authoritative DNS?
>> Do you suspect a UDP issue?
>> Is a managed (switch) involved? Has duplex ever been an issue?
>> Regards
>> Patrick  
>> 
>>> On Aug 18, 2019, at 1:03 PM, Radek  wrote:
>>> 
>>> Hello,
>>> 
>>> I have two testing gateways (6.5/i386) with site-to-side VPN between its 
>>> LANs (OpenIKED).
>>> Both gws are fully syspatched, have public IPs and the same iked/pf 
>>> configuration.
>>> 
>>> Unfortunately, the network traffic over the VPN tunnel stalls few times a 
>>> day. 
>>> 
>>> On the one side I use a script to monitor VPN tunnel with ping, it restarts 
>>> iked and emails me if there is no ping over the VPN tunnel.
>>> Date: Sat, 17 Aug 2019 22:10:30 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 06:00:20 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 11:09:00 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 19:03:02 +0200 (CEST)
>>> 
>>> 
>>> In 6.3/i386 I have the same problem, but more frequently.
>>> Date: Sat, 17 Aug 2019 23:03:56 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 01:37:50 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 04:12:31 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 06:46:25 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 09:20:22 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 11:59:08 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 14:34:38 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 17:12:57 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 19:47:16 +0200 (CEST)
>>> 
>>> Do I have any bugs/deficiencies in my configs, missed something? 
>>> Is there any way to make it work uninterruptedly?
>>> I would be very greatful if you could help me with this case.
>>> 
>>> $cat /etc/hostname.enc0
>>> up
>>> 
>>> $cat /etc/hostname.vr3
>>> inet 10.0.17.254 255.255.255.0 NONE description "LAN17"
>>> group trust
>>> 
>>> $cat /etc/iked.conf
>>> local_gw_RAC17  = "10.0.17.254" # lan_RAC
>>> local_lan_RAC17 = "10.0.17.0/24"
>>> remote_gw_MON   = "1.2.3.5" # fw_MON
>>> remote_lan_MON  = "172.16.1.0/24"
>>> ikev2 quick active esp \
>>> from $local_gw_RAC17 to $remote_gw_MON \
>>> from $local_lan_RAC17 to $remote_lan_MON peer $remote_gw_MON \
>>> childsa enc chacha20-poly1305 \
>>> psk "psk"
>>> 
>>> $cat /etc/pf.conf
>>> # RAC-fwTEST
>>> ext_if  = "vr0"
>>> lan_rac_if  = "vr3" # vr3 -
>>> lan_rac_local   = $lan_rac_if:network # 10.0.17.0/24
>>> backup_if   = "vr2" # vr2 - lewy port
>>> backup_local= $backup_if:network # 10.0.117/24
>>> 
>>> bud = "1.2.3.0/25"
>>> rdk_wy  = "1.2.3.4"
>>> rdk_mon = "1.2.3.5"
>>> panac_krz   = "1.2.3.6"
>>> panac_rac   = "1.2.3.7"
>>> 
>>> set fingerprints "/dev/null"
>>> set skip on { lo, enc0 }
>>> set block-policy drop
>>> set optimization normal
>>> set ruleset-optimization basic
>>> 
>>> antispoof quick for {lo0, $lan_rac_if, $backup_if }
>>> 
>>> match out log on $ext_if from { $lan_rac_local, $backup_local } nat-to 
>>> $ext_if set prio (3, 7)
>>> 
>>> block all
>>> 
>>> match in all scrub (no-df random-id)
>>> match out all scrub (no-df random-id)
>>> pass out on egress keep state
>>> 
>>> pass from { 10.0.201.0/24, $lan_rac_local, $backup_local } to any set prio 
>>> (3, 7) keep state
>>> 
>>> ssh_port= "1071"
>>> table  const { $bud, $rdk_wy, $rdk_mon, $panac_krz, $pa

Re: Ergonomic USB wired mouse

[Patrick Marchand]

Hello,

On 08/19, Oliver Marugg wrote:
> I am preparing switching my desktop from another OS to OpenBSD. Is anyone
> using an Evoluent USB Wired Mouse (C/4 or 4 small) with OpenBSD? Or any
> other great ideas about an ergonomic mouse working with OpenBSD?

Most mouses should work, though I remember having problems with
mouses that have more than 3 buttons (The extra buttons didnt do
anything)

I'm using the contour unimouse right now and it works great.
Trackballs work as well.

Have a nice day

Re: [OpenIKED] Network traffic over VPN site-to-site tunnel stalls few times a day

[Patrick Dohman]

Does your ISP implement authoritative DNS?
Do you suspect a UDP issue?
Is a managed (switch) involved? Has duplex ever been an issue?
Regards
Patrick  

> On Aug 18, 2019, at 1:03 PM, Radek  wrote:
> 
> Hello,
> 
> I have two testing gateways (6.5/i386) with site-to-side VPN between its LANs 
> (OpenIKED).
> Both gws are fully syspatched, have public IPs and the same iked/pf 
> configuration.
> 
> Unfortunately, the network traffic over the VPN tunnel stalls few times a 
> day. 
> 
> On the one side I use a script to monitor VPN tunnel with ping, it restarts 
> iked and emails me if there is no ping over the VPN tunnel.
> Date: Sat, 17 Aug 2019 22:10:30 +0200 (CEST)
> Date: Sun, 18 Aug 2019 06:00:20 +0200 (CEST)
> Date: Sun, 18 Aug 2019 11:09:00 +0200 (CEST)
> Date: Sun, 18 Aug 2019 19:03:02 +0200 (CEST)
> 
> 
> In 6.3/i386 I have the same problem, but more frequently.
> Date: Sat, 17 Aug 2019 23:03:56 +0200 (CEST)
> Date: Sun, 18 Aug 2019 01:37:50 +0200 (CEST)
> Date: Sun, 18 Aug 2019 04:12:31 +0200 (CEST)
> Date: Sun, 18 Aug 2019 06:46:25 +0200 (CEST)
> Date: Sun, 18 Aug 2019 09:20:22 +0200 (CEST)
> Date: Sun, 18 Aug 2019 11:59:08 +0200 (CEST)
> Date: Sun, 18 Aug 2019 14:34:38 +0200 (CEST)
> Date: Sun, 18 Aug 2019 17:12:57 +0200 (CEST)
> Date: Sun, 18 Aug 2019 19:47:16 +0200 (CEST)
> 
> Do I have any bugs/deficiencies in my configs, missed something? 
> Is there any way to make it work uninterruptedly?
> I would be very greatful if you could help me with this case.
> 
> $cat /etc/hostname.enc0
> up
> 
> $cat /etc/hostname.vr3
> inet 10.0.17.254 255.255.255.0 NONE description "LAN17"
> group trust
> 
> $cat /etc/iked.conf
> local_gw_RAC17  = "10.0.17.254" # lan_RAC
> local_lan_RAC17 = "10.0.17.0/24"
> remote_gw_MON   = "1.2.3.5" # fw_MON
> remote_lan_MON  = "172.16.1.0/24"
> ikev2 quick active esp \
> from $local_gw_RAC17 to $remote_gw_MON \
> from $local_lan_RAC17 to $remote_lan_MON peer $remote_gw_MON \
> childsa enc chacha20-poly1305 \
> psk "psk"
> 
> $cat /etc/pf.conf
> # RAC-fwTEST
> ext_if  = "vr0"
> lan_rac_if  = "vr3" # vr3 -
> lan_rac_local   = $lan_rac_if:network # 10.0.17.0/24
> backup_if   = "vr2" # vr2 - lewy port
> backup_local= $backup_if:network # 10.0.117/24
> 
> bud = "1.2.3.0/25"
> rdk_wy  = "1.2.3.4"
> rdk_mon = "1.2.3.5"
> panac_krz   = "1.2.3.6"
> panac_rac   = "1.2.3.7"
> 
> set fingerprints "/dev/null"
> set skip on { lo, enc0 }
> set block-policy drop
> set optimization normal
> set ruleset-optimization basic
> 
> antispoof quick for {lo0, $lan_rac_if, $backup_if }
> 
> match out log on $ext_if from { $lan_rac_local, $backup_local } nat-to 
> $ext_if set prio (3, 7)
> 
> block all
> 
> match in all scrub (no-df random-id)
> match out all scrub (no-df random-id)
> pass out on egress keep state
> 
> pass from { 10.0.201.0/24, $lan_rac_local, $backup_local } to any set prio 
> (3, 7) keep state
> 
> ssh_port= "1071"
> table  const { $bud, $rdk_wy, $rdk_mon, $panac_krz, $panac_rac, 
> 10.0.2.0/24, 10.0.15.0/24, 10.0.100.0/24 }
> table  persist counters
> block from 
> pass in log quick inet proto tcp from  to $ext_if port $ssh_port 
> flags S/SA \
>set prio (7, 7) keep state \
>(max-src-conn 15, max-src-conn-rate 2/10, overload  flush 
> global)
> 
> icmp_types  = "{ echoreq, unreach }"
> pass inet proto icmp all icmp-type $icmp_types \
>set prio (7, 7) keep state
> 
> table  const { $rdk_mon, $panac_rac, $panac_krz }
> pass out quick on egress proto esp from (egress:0) to  
>  set prio (6, 7) keep state
> pass out quick on egress proto udp from (egress:0) to  port {500, 
> 4500} set prio (6, 7) keep state
> pass  in quick on egress proto esp from  to (egress:0) 
>  set prio (6, 7) keep state
> pass  in quick on egress proto udp from  to (egress:0) port {500, 
> 4500} set prio (6, 7) keep state
> pass out quick on trust received-on enc0 set prio (6, 7) keep state
> 
> pass in on egress proto udp from any to (egress:0) port {isakmp,ipsec-nat-t} 
> set prio (6,7) keep state
> pass in on egress proto {ah,esp} set prio (6,7) keep state
> 
> # By default, do not permit remote connections to X11
> block return in on ! lo0 proto tcp to port 6000:6010
> 
> $cat iked_monitor.sh
> #!/bin/sh
> while true
> do
> vpn=`ping -c 3 -w 1 -I 10.0.17.254 172.16.1.254 | grep packets | awk -F " " 
> '{print $4}'`
> 
> if [ "${vpn}" -eq 0 ] ; then
> mon=`ping -c 3 -w 1 the_other_side_WAN_IP | grep packets | awk -F " " '{print 
> $4}'`
> wan=`ping -c 3 -w 1 8.8.8.8 | grep packets | awk -F " " '{print $4}'`
> 
>if [ "${mon}" -gt 0 ] && [ "${wan}" -gt 0 ] ; then
>echo vpn: ${vpn}, mon: ${mon}, wan: ${wan} | mail -s "no ping through 
> VPN RACTEST-MON! restartng iked!" em...@example.com
>rcctl restart iked
>fi
> fi
> sleep 32
> done
> 
> 
> -- 
> Radek
> 

Re: syspatch Octeon and arm64 alternatives

[Patrick Wildt]

On Wed, Jul 17, 2019 at 02:32:22PM -0400, Predrag Punosevac wrote:
> Hi Misc,
> 
> Are there any plans to build syspathes for Octeon platform in the
> future? Octeon platform has matured nicely since the introduction in
> 2013 and is becoming my goto platform for SOHO environments. Apart of
> the lack of hardware clocks the main nuisance is the lack of binary
> patches. 
> 
> 
> I know that arm64 is vigorously developed and I do have few ROCK64
> boards but is there a consumer grade network hardware built on the top
> of arm64? Can one run OpenBSD on something like SG-1100
> 
> https://www.netgate.com/solutions/pfsense/sg-1100.html
> 
> and how does it compare to edgerouter 4
> 
> https://www.ui.com/edgemax/edgerouter-4/
> 
> Thanks,
> Predrag
> 

Hi,

the SG-1100 is using the same SoC as the Turris Mox, which I intend
to support.  I recently received mine.  As long as the SG-1100 uses
a recent (as in 2017/2018) U-Boot it should be possible to support
that hardware once the Turris Mox support got better.

That said, I would assume that the USB 3.0 ports work already and the
the WAN port should do as well.  The eMMC is not yet supported.  If I
had one I could have a look.

Patrick

Re: IPsec performance regression between 6.3 and 6.4

[Patrick Wildt]

Hi,

we recently found that the switch to constant-time AES has quite a heavy
impact on IPsec performance.  But since according to CVS that was part
of OpenBSD 6.2 already, it's probably something else.

https://github.com/openbsd/src/commit/d223d7cb85c1f2f705da547a0134b949655abe6a

Patrick

On Wed, Jul 17, 2019 at 12:26:31PM +, pierre1.bar...@orange.com wrote:
> Hello,
> 
> I'm currently doing some IPsec performance testing between OpenBSD 6.3 and 
> 6.5.
> Dmesg and ipsec.conf is below for information.
> 
> Testing with iperf3 and 1500B packets, throughput drops around 1/3, from 919 
> Mbps to 623 Mbps.
> I also tried 6.4, which has similar perfomance to 6.5.
> I went through plus64.html without finding a change that could explain this.
> 
> 
> Could someone explain me what caused such a performance drop ?
> Is there any solutions or plans to get the original performance back ?
> 
> Thank you
> 
> 
> root@bsdWAN ~ # cat /etc/ipsec.conf
> # Conf transport
> ike esp transport proto gre \
>   from 192.168.3.254 to 192.168.3.1 peer 192.168.3.1 \
>   main auth hmac-sha2-256 enc aes-256 group modp1024 lifetime 86400 \
>   quick auth hmac-sha2-256 enc aes-256 group modp1024 lifetime 28800 \
>   psk "mekmitasdigoat"
> 
> root@bsdWAN ~ # dmesg
> OpenBSD 6.5 (GENERIC.MP) #2: Tue May 14 10:19:35 UTC 2019
> root@openbsd65.local:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8395776000 (8006MB)
> avail mem = 8131694592 (7754MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x8ef68000 (45 entries)
> bios0: vendor Dell Inc. version "1.4.5" date 08/09/2016
> bios0: Dell Inc. PowerEdge R330
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S5
> acpi0: tables DSDT FACP BOOT SSDT SLIC HPET LPIT APIC MCFG WDAT SSDT DBGP 
> DBG2 SSDT SSDT SSDT SSDT SSDT SSDT PRAD HEST BERT ERST EINJ DMAR FPDT
> acpi0: wakeup devices PEGP(S0) PEG0(S0) PEGP(S0) PEG1(S0) PEGP(S0) PEG2(S0) 
> XHC_(S0) XDCI(S0) PXSX(S0) RP01(S0) PXSX(S0) RP02(S0) PXSX(S0) RP03(S0) 
> PXSX(S0) RP04(S0) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 2399 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3293.54 MHz, 06-5e-03
> 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 24MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3292.34 MHz, 06-5e-03
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3292.34 MHz, 06-5e-03
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3292.34 MHz, 06-5e-03
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,P

Re: OT: hardware war with manufacturers (espionage claims)

[Patrick Dohman]

> On Jul 5, 2019, at 10:49 PM, Theo de Raadt  wrote:
> 
> So this is misc, which is full of lots of talk about nothing, by people
> who can't change the ecosystem.  Having worried vocally about this
> before, I know I can't change it.  Pretty sad to see people who are even
> less capable find the energy to moan about it.  Especially americans.
> Know what I mean?

I currently suspect the well known Chinese conglomerates are not participating 
of industrial espionage.
At this point the trade war is an effort to continue with existing 
relationships that have existed for decades.
It’s well understood that the Agro business is a growing consideration for the 
likes of China & Vietnam & that manufacturing in those countries is a tug of 
war with demand.
As the predominance of fast food & connivence continues to explode it’s 
possible that American trade dominance may actually increase.
Regards
Patrick

Re: bwfm bcm43569

[Patrick Wildt]

On Tue, Jun 25, 2019 at 12:06:51AM +0300, 3 wrote:
> i know that wifi adapters never worked in obsd(excluding those
> adapters for which drivers were written by vendors), but i found one
> that shows signs of life in 11n(11ac 2t2r supported by chip). it can
> be bought anywhere where there are samsung tv. moreover it even works
> in hostap mode(unlike the buggy athn).
> but without a ton of bugs not done:
> bwfm0: could not read register: TIMEOUT
> bwfm0: could not open rx pipe: IN_USE
> bwfm0: could not init bus
> bwfm0: firmware did not start up
> .and sometimes kernel panic on boot, but works would still!
> meet https://wikidevi.com/wiki/Samsung_WCH730B
> bwfm0 at uhub0 port 1 configuration 1 interface 0 "Broadcom BCMUSB 802.11 
> Wireless Adapter" rev 2.10/0.01 addr 2
> photo without cover: http://pichost.org/images/2019/06/24/Untitled-138.jpg 
> it is shown where to solder the wires for wifi. on the right through
> two pins(ground is first) is bluetooth, but for obsd this does not
> matter(thx theo).  
> data sheet for chip: https://www.cypress.com/file/310246/download

Did you solder that yourself?  As long as nothing has changed, bwfm(4)
on USB worked fine with the one USB one that I had:  The official
raspberry Pi USB WiFi stick that they sold before they put the WiFi
chip onto the board itself.  I wouldn't blame that on the driver.
Did you try the stick with Linux?  If it works with Linux then maybe
it's my fault after all.

Patrick

Re: Puffy — format SVG

[Patrick Harper]

An SVG with the textual logo exists at 
https://upload.wikimedia.org/wikipedia/en/8/83/OpenBSD_Logo_-_Cartoon_Puffy_with_textual_logo_below.svg

-- 
  Patrick Harper
  paia...@fastmail.com

On Thu, 13 Jun 2019, at 19:37, Stephane HUC "PengouinBSD" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> For a little project to promote, I had the idea to convert the gif image
> about Puffy, into svg with Inkscape.
> 
> Some will consider it a bad idea ... !
> At least, the image in SVG format exists.
> 
> it is available on my server:
> https://stephane-huc.net/img/EBNH/OBSD/Puffy.svg
> 
> Voilà! :D
> 
> PS: If someone wants to put it on the openbsd www, it's up to you! ;)
> 
> - -- 
> ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD "   +=<<<
> - 
> Stephane HUC as PengouinBSD or CIOTBSD
> b...@stephane-huc.net
> -BEGIN PGP SIGNATURE-
> 
> iHUEARYKAB0WIQScTRXz7kMlZfGpDZMTq98t3AMG7wUCXQKXrgAKCRATq98t3AMG
> 755TAQCe6mlsM7iYoYlYQSdE7nh7uaxR7C/xTOP19l5lk6+YVQD/fgqPutl2dm4s
> 2XpB5OhLUZp4GM4MSz/Xw8qPY+UyPwk=
> =FjrT
> -END PGP SIGNATURE-
> 
>

Re: Installing OpenBSD on Supermicro A2SDi-4C-HLN4F

[Patrick Dohman]

My understanding is that a well known linux vendor was disabling kernel ACPI 
APEI & EINJ parameter support by default.

"ACPI provides an error injection mechanism, EINJ, for debugging and testing
the ACPI Platform Error Interface (APEI) and other RAS features. If
supported by the firmware, ACPI specification 5.0 and later provide for a
way to specify a physical memory address to which to inject the error.

Injecting errors through EINJ can produce errors which to the platform are
indistinguishable from real hardware errors. This can have undesirable
side-effects, such as causing the platform to mark hardware as needing
replacement.

While it does not provide a method to load unauthenticated privileged code,
the effect of these errors may persist across reboots and affect trust in
the underlying hardware, so disable error injection through EINJ if
securelevel is set."

Regards
Patrick

> On Jun 15, 2019, at 3:02 AM, Richard Laysell  
> wrote:
> 
> 
> Hello,
> 
> I was trying OpenBSD on a Supermicro A2SDi-4C-HLN4F which uses an Intel
> Atom CPU (Denverton).  The board boots but most devices are not
> detected because ACPI can't be enabled.
> 
> Does anyone know if this is likely to be supported at some point?
> 
> Full dmesg is below
> 
> OpenBSD 6.5 (RAMDISK_CD) #3: Sat Apr 13 14:55:38 MDT 2019
>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> real mem = 17125621760 (16332MB)
> avail mem = 16602619904 (15833MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7f0c3000 (35 entries)
> bios0: vendor American Megatrends Inc. version "1.1b" date 12/17/2018
> bios0: Supermicro Super Server
> acpi0 at bios0: rev 2, can't enable ACPI
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, 2200.41 MHz, 06-5f-01
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu0: 2MB 64b/line 16-way L2 cache
> cpu0: cannot disable silicon debug
> cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE
> pci0 at mainbus0 bus 0
> 0:31:5: mem address conflict 0xfe01/0x1000
> pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x1980 rev 0x11
> pchb1 at pci0 dev 4 function 0 vendor "Intel", unknown product 0x19a1 rev 0x11
> vendor "Intel", unknown product 0x19a2 (class system subclass root complex 
> event, rev 0x11) at pci0 dev 5 function 0 not configured
> ppb0 at pci0 dev 6 function 0 vendor "Intel", unknown product 0x19a3 rev 0x11
> pci1 at ppb0 bus 1
> vendor "Intel", unknown product 0x19e2 (class processor subclass 
> Co-processor, rev 0x11) at pci1 dev 0 function 0 not configured
> ppb1 at pci0 dev 10 function 0 vendor "Intel", unknown product 0x19a5 rev 0x11
> pci2 at ppb1 bus 2
> ppb2 at pci0 dev 16 function 0 vendor "Intel", unknown product 0x19aa rev 0x11
> pci3 at ppb2 bus 3
> ppb3 at pci0 dev 17 function 0 vendor "Intel", unknown product 0x19ab rev 0x11
> pci4 at ppb3 bus 4
> ppb4 at pci4 dev 0 function 0 "ASPEED Technology AST1150 PCI" rev 0x03
> pci5 at ppb4 bus 5
> "ASPEED Technology AST2000" rev 0x30 at pci5 dev 0 function 0 not configured
> vendor "Intel", unknown product 0x19ac (class system subclass miscellaneous, 
> rev 0x11) at pci0 dev 18 function 0 not configured
> ahci0 at pci0 dev 19 function 0 vendor "Intel", unknown product 0x19b2 rev 
> 0x11: unable to map interrupt
> ahci1 at pci0 dev 20 function 0 vendor "Intel", unknown product 0x19c2 rev 
> 0x11: unable to map interrupt
> xhci0 at pci0 dev 21 function 0 vendor "Intel", unknown product 0x19d0 rev 
> 0x11: couldn't map interrupt
> ppb5 at pci0 dev 22 function 0 vendor "Intel", unknown product 0x19d1 rev 0x11
> pci6 at ppb5 bus 6
> vendor "Intel", unknown product 0x15e4 (class network subclass ethernet, rev 
> 0x11) at pci6 dev 0 function 0 not configured
> vendor "Intel", unknown product 0x15e4 (class network subclass ethernet, rev 
> 0x11) at pci6 dev 0 function 1 not configured
> ppb6 at pci0 dev 23 function 0 vendor "Intel", unknown product 0x19d2 rev 0x11
> pci7 at ppb6 bus 7
> vendor "Intel", unknown product 0x15e5 (class network subclass ethernet, rev 
> 0x11) at pci7 dev 0 function 0 not configured
> vendor "Intel", unknown product 0x15e5 (class network subclass ethernet, rev 
&

Re: chrome pledge "", syscall 289

[Patrick Dohman]

> On Jun 3, 2019, at 6:46 PM, Cord  wrote:
> 
> Hi,
> I have found the following errors on the log:
> 
> /bsd: chrome[18585]: pledge "", syscall 289
> 
> they appear everytime I start chrome.. they are about 4 or 5, what means?
> It's the first time, yesterday and in the past there aren't any.
> 

Withstanding the obvious have you tried --enable-unveil?
Regards
Patrick

Re: Lenovo w/ AMD Ryzen CPU

[Patrick Wildt]

I'd love to have one as well...

On Tue, May 28, 2019 at 11:16:51AM -0600, Theo de Raadt wrote:
> I am hoping to get one also... and as a rule whatever I get my hands on tends 
> to work out well.
> 
> danieljb...@icloud.com wrote:
> 
> > I just ordered some E495s (not 'T', but pretty similar). I think
> > they're supposed to arrive today. I'll do a test boot and send in a
> > dmesg.
> > 
> > On Tue, May 28, 2019 at 10:44:44AM -0400, David Anthony wrote:
> > > All,
> > > 
> > > The Lenovo release of T*95 series laptops with AMD Ryzen CPU appears 
> > > imminent. 
> > > 
> > > Would these be poor choices for OpenBSD? Are there any anticipated 
> > > ???gotchas??? that I should be aware of? Any thoughts would be greatly 
> > > appreciated.
> > > 
> > > Respectfully,
> > > David Anthony
> > > 
> > 
> 

Re: Installer doesn't see sd0 on qemu guest 6.5-current

[Patrick Wildt]

As you can see in dmesg, it actually sees sd0, and it does not detach.
Instead, the device node just isn't in /dev, because the insaller does
create that on the fly.  Since you are not using the installer, you
have to manually type cd /dev && sh MAKEDEV sd0

On Sat, Jun 01, 2019 at 09:08:58PM +0300, Maksym Sheremet wrote:
> There is a 6.5-current VM running with QEMU on linux host. Usually the
> VM is being updated to the latest snapshot once per 10 days. Everything
> was OK with with 2019-04-21 snapshot. The problem has been appeared
> since 2019-05-01 snapshot.
> 
> The VM is installed on a dedicated drive with FDE. It is detected as sd0
> by bsd.rd booted from install65.iso. But once installer is started the
> drive disappears. Here is full output:
> 
> >> OpenBSD/amd64 CDBOOT 3.43
> boot> 
> cannot open cd0a:/etc/random.seed: No such file or directory
> booting cd0a:/6.5/amd64/bsd.rd: 3691345+1532928+3889096+0+598016
> [373454+128+451752+300829]=0xa58318
> entry point at 0x81001000
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>  The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2019 OpenBSD. All rights reserved.
>  https://www.OpenBSD.org
> 
> OpenBSD 6.5-current (RAMDISK_CD) #50: Fri May 31 20:22:49 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> real mem = 2130558976 (2031MB)
> avail mem = 2062069760 (1966MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5b10 (9 entries)
> bios0: vendor SeaBIOS version "1.12.0-20181126_142135-anatol"
> date 04/01/2014
> bios0: QEMU Standard PC (i440FX + PIIX, 1996)
> acpi0 at bios0: rev 0
> acpi0: tables DSDT FACP APIC
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: QEMU Virtual CPU version 2.5+, 2295.00 MHz, 06-06-03
> cpu0:
> FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF,MELTDOWN
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> 64b/line 16-way L2 cache
> cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu0: apic clock running at 1000MHz
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu at acpi0 not configured
> "ACPI0006" at acpi0 not configured
> "PNP0A03" at acpi0 not configured
> acpicmos0 at acpi0
> "PNP0A06" at acpi0 not configured
> "PNP0A06" at acpi0 not configured
> "PNP0A06" at acpi0 not configured
> "QEMU0002" at acpi0 not configured
> "ACPI0010" at acpi0 not configured
> pvbus0 at mainbus0: KVM
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
> "Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured
> pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA,
> channel 0 wired to compatibility, channel 1 wired to compatibility
> pciide0: channel 0 disabled (no drives)
> pciide0: channel 1 disabled (no drives)
> uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0
> int 11
> "Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured
> vga1 at pci0 dev 2 function 0 "Bochs VGA" rev 0x02
> vga1: aperture needed
> wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
> virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
> vio0 at virtio0: address 08:00:27:77:c1:d5
> virtio0: msix shared
> virtio1 at pci0 dev 5 function 0 "Qumranet Virtio Storage" rev 0x00
> vioblk0 at virtio1
> scsibus0 at vioblk0: 2 targets
> sd0 at scsibus0 targ 0 lun 0:  SCSI3 0/direct
> fixed
> sd0: 114473MB, 512 bytes/sector, 234441632 sectors
> virtio1: msix shared
> virtio2 at pci0 dev 6 function 0 "Qumranet Virtio Memory Balloon" rev
> 0x00
> virtio2: no matching child driver; not configured
> ahci0 at pci0 dev 7 function 0 "Intel 82801I AHCI" rev 0x02: apic 0
> int 11, AHCI 1.0
> ahci0: port 0: 1.5Gb/s
> scsibus1 at ahci0: 32 targets
> cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom
> removable
> usb0 at uhci0: USB revision 1.0
> uhub0 at usb0 configuration 1 interface 0 "Intel UHCI root hub" rev
> 1.00/1.00 addr 1
> isa0 at mainbus0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay1
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> root on rd0a swap on rd0b dump on rd0b
> erase ^?, werase ^W, kill ^U, intr ^C, status ^T
> 
> Welcome to the OpenBSD/amd64 6.5 installation program.
> (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? s
> # bioctl -c C -l /dev/sd0a softraid0
> bioctl: could not open /dev/sd0a: No such file or directory
> # ls /dev
> MAKEDEV cua01   klogrcd0c   rrd0c   rwd0g   rwd0o   ttyC0   wd0gwd0o
> bio diskmap kmemrd0arst0rwd0h   rwd0p   urandom wd0hwd0p
> bpf enrst0  

Re: Let's Encrypt ACMEv1 end-of-life

[Patrick Dohman]

> On May 31, 2019, at 10:42 AM, Diogo Pinela  wrote:
> 
> As I understand it, acme-client currently only supports
> ACMEv1. Let's Encrypt recently announced they're going
> to begin progressively deprecating that protocol starting
> this November:

OCSP is an interesting subject.
In my opinion there is still a need for a certificate infrastructure inside 
private LAN's.
I’ve learned that in many situations a DNS authority can not be accommodated & 
certs are non-op.
In addition I find the reliance on public API via browser a potential privacy 
concern.
Regards
Patrick

Re: OpenBSD runs only in RAM from a USB Flash Drive

[Patrick Harper]

FFS isn't a journaling filesystem so any 'wear', even on primitive flash 
storage, won't be enough to worry about.

-- 
  Patrick Harper
  paia...@fastmail.com

On Fri, 31 May 2019, at 03:41, sove...@vivaldi.net wrote:
> 30 May, 2019
> 
> Greetings OpenBSD aficionados,
> 
> As a newbie to OpenBSD, I am delighted to have the chance to interact 
> with the OpenBSD Mailing Lists community.
> Since I am about to install OpenBSD 6.5 (amd64) on a USB Flash Drive for 
> the first time, I was wondering if anyone has a solution to the 
> following conundrum.
> 
> In order to minimize wear on the USB Flash memory, is there a way to 
> command OpenBSD to always run in RAM, and at shutdown to either save or 
> not save the session to the USB Flash Drive.
> 
> For instance, Precise Puppy Linux 5.7.1 has a package called Puppy Event 
> Manager. Since Precise Puppy is programmed to run in RAM, you can select 
> the 'Save Session' tab and enter the span of minutes for everything in 
> RAM to be saved to the Precise Puppy SaveFile.
> 
> Best of all, you can enter 0 minutes to only do a save at shutdown. 
> Perfect for minimizing wear on a USB Flash Drive.
> 
> Please accept my apologies if this issue has already been solved. My 
> search so far in sites like https://marc.info has come up empty.
> 
> I thank you for your support.
> 
> Best regards,
> Hugh
> 
>

PCIe SFP Network Adapter's

[Patrick Dohman]

Hoping to clarify if any PCI Express SFP adapters are currently considered 
compatible.
I've recently upgraded my managed switch & now have two SFP 100/1000 uplinks.
At this point I consider my existing Broadcom NetXtreme 10/100/1000 ethernet 
card stable
However testing of SFP functionality on OpenBSD & PF seems worthwhile.
A quick search turned up a StarTech PEX1000SFP2 with the following chipsets:
Realtek - RTL8168E 
Marvell - 88EB1
Please note that I’m hoping to maintain desktop compatibility while 
implementing SFP.
Regards
Patrick

Re: Missing file and Man page for out-of-date

[Patrick Harper]

It was renamed to pkg_outdated.

-- 
  Patrick Harper
  paia...@fastmail.com

On Sat, 25 May 2019, at 22:17, Michael Alaimo wrote:
> The /usr/ports/infrastructure/bin/out-of-date program is missing.
> 
> I remember it being in OpenBSD 6.3.
> 
> It is still referenced in /usr/ports/infrastructure/README in OpenBSD 6.5.
> 
> It is listed with description:
> bin/out-of-date
> Compare installed registered packages with INDEX, try to find out
> of date ports.
> 
> Is it possible to get the script back into ports for OpenBSD 6.5?
> 
> Does anyone know what happened with it?
> 
> Regards,
> 
> Michael
> 
> http://quantum-foam.org/
> 
>