Re: Webcam support on Lenovo Thinkpad T14 Gen3 (Intel)

[Bryan Steele]

Morgan wrote:
> Hello,
>
> $ video -q -f /dev/video1
> video: /dev/video1 has no usable YUV encodings
>
> $ video -s 1920x1080 -f /dev/video1
> video: /dev/video1 has no usable YUV encodings
>
>
> thanks for your suggestion
>
> Morgan

Are there any non-YUV formats supported?

$ ffmpeg -f v4l2 -list_formats all -i /dev/video1

-Bryan.

Re: Problems with HD

[Bryan Steele]

On Thu, Oct 05, 2023 at 05:41:28AM +, Maria Morisot wrote:
> > On Thu, Oct 05, 2023 at 04:08:34AM +, Maria Morisot wrote:
> > 
> > > I have an Asus Vivobook (1400EA),
> > > and the hard drive is not recognized
> > > by OpenBSD. I have the same problem
> > > on some distros of Linux, but on others
> > > it shows up fine.
> > 
> > 
> > My Asus ZenBook had a similar issue, which was resolved
> > by diving into the BIOS "Advanced" section and setting the
> > storage controller to something other than the pseudo-RAID
> > mode. It may we worth checking whether there is such an option
> > available.
> 
> I went into the BIOS and can't see anything about disabling RAID; and the 
> disk itself says there is no RAID on the drive. But I did get into the BIOS 
> info for the drive itself so I'll post that in case someone finds it useful.
> 
> Port: 1.0
> Model Number: Micron_2450_MTFDKBA256
> Serial Number: 214532CBCA77
> Size 238.4GB
> Controller Type: NVMe
> Controller Interface: PCIe

The option may be called "Intel Volume Management Device" (VMD), if you
don't see anything about RAID or Intel Rapid Storage RST.

It would be helpful to see a dmesg to confirm that this is the problem
you're having though.

-Bryan.
(VMD)

Re: Safely remove USB drive

[Bryan Steele]

On Wed, Feb 08, 2023 at 10:34:07AM -0300, vitmau...@gmail.com wrote:
> Hi,
> 
> I'm not using my drives for anything more than copying files, dd etc.
> I just got curious because you mentioned the act of detaching a device
> after umounting it and I don't know how to do that on OpenBSD. On
> Fedora I would issue "udisks --detach /dev/sdX" (older versions) or
> "udisksctl poweroff -b /dev/sdX" (newer versions).
> 
> Best,
> Vitor

Umounting should be good enough, but you can also use eject(1), which
should have the desired effect, e.g:

# disklabel sd1
# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: Flash Disk
...
# eject /dev/rsd1c
# disklabel sd1
disklabel: DIOCGDINFO: Input/output error
#

You'll need to physically reconnect the drive if you want to use it again.

-Bryan.

Re: WhatsApp Web in Chromium under OpenBSD 7.1

[Bryan Steele]

On Mon, May 09, 2022 at 06:50:16PM +0200, Federico Giannici wrote:
> On 5/9/22 18:40, Caspar Schutijser wrote:
> > On Mon, May 09, 2022 at 01:16:15PM +0200, Federico Giannici wrote:
> > > I'm not able to use WhatsApp Web in Chromium under OpenBSD 7.1 (amd64), no
> > > login page appears.
> > > Is there something bad in my configuration or is this a known problem?
> > > Thanks.
> > 
> > That's because by default WebAssembly is not enabled in Chromium (I
> > found out this was the culprit using the Developer Console, there was
> > some error message).
> > 
> > Starting Chromium with ENABLE_WASM=1 in your environment will
> > make it work.
> > 
> > Caspar
> > 
> 
> OK, it worked!
> 
> Now the question is: why WebAssembly is disabled by default under OpenBSD?
> Is there any contraindication to activate it?
> 
> Thanks.

WASM is unusable unless you have user limits set to near infinity,
and having it enabled by default actively broke websites that would
have otherwise worked without it.

https://marc.info/?l=openbsd-ports=154376428820247=2

IMO it was disabled for good reason. An environment variable exists
to override it for the few sites that need it.

I kind of wish this had also happened in Firefox, but that may soon
go in another direction..

-Bryan.

Re: dmesg - cpu, smt, core, package

[Bryan Steele]

pre-Ryzen AMD CPUs did not have SMT, but they had "CMT" or
"clustered multithreading" which is the shared-FPU stuff,
hw.smt=0 disables that too on these CPUs. I believe this
was intentional as this kind of resource sharing between
cores comes with inherent risk-- FPU state can contain
things like AES key data used by AESNI instructions, etc.

-Bryan.

Re: C states no longer recognized?

[Bryan Steele]

On Mon, Jan 31, 2022 at 02:16:20PM +0100, Jan Stary wrote:
> This is current/amd64 on a PC, dmesgs below.
> Looking at the diff between a Jan 24 and a Jan 31 dmesg,
> it seems that the C2 and C3 are no longer recognized:
> 
> -acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> -acpicpu1 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> -acpicpu2 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> -acpicpu3 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> +acpicpu0 at acpi0: C1(@1 halt!), PSS
> +acpicpu1 at acpi0: C1(@1 halt!), PSS
> +acpicpu2 at acpi0: C1(@1 halt!), PSS
> +acpicpu3 at acpi0: C1(@1 halt!), PSS
> 
> Is this expected? Is it related to the recent apm change
> of always running at full hw.setperf when on AC?
> 
>   Jan

Have you changed any settings in the BIOS or upgraded it recently? I've
seen this disable "Global C-state control" knob on some boards, not sure
if they'll find this on Intel boards or not.

-Bryan.

> 
> OpenBSD 7.0-current (GENERIC.MP) #0: Mon Jan 24 14:30:19 CET 2022
> h...@biblio.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8419540992 (8029MB)
> avail mem = 8078901248 (7704MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries)
> bios0: vendor Award Software International, Inc. version "F2" date 04/20/2011
> bios0: Gigabyte Technology Co., Ltd. Z68MX-UD2H-B3
> acpi0 at bios0: ACPI 1.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT MATS
> acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) 
> PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf400, bus 0-63
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, 3611.09 MHz, 06-2a-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,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,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 100MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, 3610.61 MHz, 06-2a-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,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,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) Core(TM) i5-2400 CPU @ 3.10GHz, 3610.61 MHz, 06-2a-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,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,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) Core(TM) i5-2400 CPU @ 3.10GHz, 3610.61 MHz, 06-2a-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,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (PEG0)
> acpiprt2 at acpi0: bus -1 (PEG1)
> acpiprt3 at acpi0: bus 2 (PEX0)
> acpiprt4 at acpi0: bus -1 (PEX1)
> acpiprt5 at acpi0: bus -1 (PEX2)
> acpiprt6 at acpi0: bus 3 (PEX3)
> a

Re: lpr woes printing a broken pdf

[Bryan Linton]

On 2021-11-02 16:10:44, Jan Stary  wrote:
> This is current/amd64 on a PC, using lpr with this /etc/printcap:
> lp::lp=:rm=pr.stare.cz:rp=lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:sh:
> which is a Brother DCP9055CDN via ethernet.
> 
> Now, I have this pdf file (attached), broken in a way that puzzles me.
> When viewed with mupdf or gv, it shows one thing, when printed with lpr,
> it shows something else.
> 
> [snip]
> 
> Is that an indication of some particular kind
> of breakage in a pdf file?
> 
> [snip]
>

I have no idea if this is the same issue affecting you, but it
reminded me of how JBIG2 compression can alter text.

To quote Wikipedia [1],

"When used in lossy mode, JBIG2 compression can
potentially alter text in a way that's not discernible as
corruption. ... Since JBIG2 tries to match up similar-looking
symbols, the numbers "6" and "8" may get replaced, for example."

This issue first came to light when it was found that scanned
documents had different numbers in the digital representation than
were on the original.  In one case, an engineer reported that the
size of a room on a technical blueprint changed from 21.11 m^2
down to 14.13 m^2 due to the way that the compression was being
erroneously applied.

However, this was reported when *scanning* documents.  Your issue
is with *printing* documents.  I have no idea if this is the same
issue as what you're experiencing, but I thought it still might be
worth pointing out in case there's some connection between the
two.

[1] https://en.wikipedia.org/wiki/JBIG2#Disadvantages

-- 
Bryan

Re: Samsung SSD X5 with OpenBSD - possible ?

[Bryan Steele]

On Mon, Oct 25, 2021 at 07:11:15PM +, Laura Smith wrote:
> 
> ‐‐‐ Original Message ‐‐‐
> 
> On Monday, October 25th, 2021 at 19:15, Stefan Sperling  
> wrote:
> 
> > On Mon, Oct 25, 2021 at 05:45:22PM +, Laura Smith wrote:
> >
> > > I'm struggling a bit as to what I need to do next here.
> > >
> > > Any time in the past I've connected a USB stick etc. to OpenBSD, 
> > > everything happened automagically in terms of recognition and assigning a 
> > > /dev/sd.
> > >
> > > However this time, its different.  This is the only line that appears in 
> > > dmesg when I plug it in:
> > >
> > > ugen0 at uhub0 port 4 "SAMSUNG ELECTRONICS CO., LTD Portable SSD X5" rev 
> > > 2.01/4.45 addr 2
> > >
> > > sysctl hw.disknames remains unchanged
> > >
> > > Any ideas ?
> >
> > I would guess that no driver is attaching because this drive requires
> >
> > Thunderbolt 3 rather than USB 3 (both use a USB-C type connector).
> 
> Makes sense, thanks !

Could you send a full dmesg with the device connected, and also try 
rebooting the machine with it still connected?

-Bryan.

Re: amd64 7.0 release where can I find original (patched) gcc 4x?

[Bryan Steele]

On Fri, Oct 22, 2021 at 06:20:30PM +, Martin wrote:
> Hi there!
> 
> After upgrading from source, there is no gcc installed into appropriate 
> location.

Upgrading between releases from source is not supported.

> ... how to enable original OpenBSD patched GCC 4x as default compiler?

You don't. clang has been the default compiler on amd64 since 6.2,
which was released back in 2017.

Sounds like the problem with you're having with mutt should be asked
on ports@ instead. You haven't said _what_ was supposedly still
depending on base-gcc, but making it work with clang or ports gcc is
clearly the way forward.

-Bryan.

Re: X220 thinkpad battery issue

[Bryan Linton]

On 2021-07-15 08:57:32, Isak Holmström  wrote:
> Hello,
> I recently discovered that my battery is not charging. I really can’t find 
> anything when searching the web regarding openbsd and batteries. Please 
> advice me how to debug this issue. I cannot find anything on 
> https://marc.info or man sysctl, apm or apmd, sysctl.conf 
> 

A couple thoughts.

1)  The battery may simply be dead.  AFAIUI, modern laptop
batteries have internal circuits that disable the battery if they
detect anything that could be dangerous.  There may be a
(Windows-only) utility that Lenovo offers to check this.

2)  Have you upgraded the laptop's internals, or changed the power
charger you use?  I know that newer models of Thinkpads will
refuse to charge if the charger can't put out enough power to do
so.  Lenovo makes chargers in many different wattage ratings.  Is
the one you're using rated to power an X220 in the configuration
it's in?  I.e. Models with faster CPUs/discrete graphics often
require a higher wattage power supply than those without.

3)  Power sockets get plugged and unplugged a lot, and tend to
wear out over time.  Could the socket itself be loose?  Does
"sysctl hw.sensors" show hw.sensors.acpiac0.indicator0 as being
"on"?  Does wiggling the power cable cause it to
connect/disconnect?

None of these are a definite answer, but hopefully one of them
will help guide you to a solution to your problem.

-- 
Bryan

Re: Unconsistent two-level write speed bouncing on softraid RAID1 SSD's

[Bryan Linton]

On 2021-06-10 11:49:59, Xavier Sanchez  wrote:
> 
> Read somewhere that issuing a security erase could also help. So I
> tried issuing the following:
> 
> # atactl sd0c secsetpass user high  
> User password:   
> Retype user password:
> atactl: ATA device returned error register 0 
> 
> But any sec* command returned:
> atactl: ATA device returned error register 0
> 
> even after a coldboot ( non-frozen ), despite the devices supports the
> Security Mode feature set
> 
> - Am I attempting to issue the security erase the wrong way ?
> 

This is not possible on OpenBSD.  It's actually a feature, not a
bug.  OpenBSD issues the secfreeze command at the driver level
when disks attach.

>From atactl(8):

secfreeze
  Prevents changes to passwords until a following power cycle.
  The purpose of this command is to prevent password setting
  attacks on the security system.  After command completion any
  other commands that update the device lock mode will be aborted.


You can see in src/sys/dev/ata/atascsi.c:408 and
src/sys/dev/ata/wd.c:305 that the same command is issued to all
sd(4) and wd(4) drives as a security measure.

You're going to need to boot from a live CD/USB in order to set a
password on the drive.

You should also double-check that your BIOS doesn't have a setting
to disable this too.  I've heard that some BIOSes have a toggle
for this to help mitigate the above-mentioned password setting
attacks.

Also, another poster mentioned that these are SMR drives.  If
that's the case, then the "stuttering" speeds you described is
normal for them.  SMR drives are good for storing infrequently
accessed files.  They're big and they're cheap, but they're not
always very fast.

Like the old saying goes when it comes to hard drives, "Pick any
two: cheap, fast, big".  SMR drives write data in "stripes".  If
you change even one bit of one byte anywhere in that stripe, the
drive has to read the entire stripe into memory, change what was
changed, then re-write the entire stripe.

This is a limitation of the technology they use.  It allows very
high density drives, but has the drawback of slowing things down a
lot whenever the drive has to re-write a stripe of data.


I've personally found that SMR drives are good enough for my use
case, but I wouldn't recommend them for a live database where
latency is much more critical.

It seems like the new hierarchy is now:

SSD >> PMR > SMR

when it comes to speed.  The inverse is true when it comes to
capacity.

So to summarize, your drive may be working exactly as intended.

-- 
Bryan

Re: fna, fna3d packages GONE on 6.8

[Bryan Steele]

On Fri, Mar 05, 2021 at 02:49:19AM +, jpegb...@dismail.de wrote:

...

> I want to install fna and fna3d to be able to play terraria with fnaify
> but the packages seem to be nonexistant on 6.8-release, and they used
> to be available. I can't use -Dsnap because the new packages depend on
> a new version of sdl2, which depends on a new version of xenocara which
> is not available on 6.8. I would upgrade to 6.9-beta but as I sent in
> a previous email it does not boot on my computer, so I'm at a loss. 
> Does anyone know of a way to fix this? Or why the packages are no 
> longer available? Thanks.

The games/fna and graphics/fna3d ports were committed after 6.8, there
were never any packages for 6.8.

https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/games/fna/
https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/graphics/fna3d/

Re: Intel Turbo Memory in Thinkpad W500

[Bryan Steele]

On Sun, Feb 28, 2021 at 09:00:25PM +0100, Jan Stary wrote:
> This is 6.9-beta/amd64 on a Thinkpad W500 (dmesg below).
> 
> Taking out the unneeded stuff (I usually take out bluetooth,
> replace the wifi with Intel 7260 HMW etc), I also noticed this
> (see attachments). Taking it out, the difference in dmesg shows:
> 
> -"Intel Turbo Memory" rev 0x11 at pci4 dev 0 function 0 not configured
> 
> Given that it's "not configured", I don't think I'm missing much
> (and the Thinkpad's memory doesn't seem any less "Turbo"),
> but does anyone know what it does in the Thinkpad? AFAIG,
> is was supposed to be a thing before 4G of RAM and SSDs
> were common ...
> 
>   Jan

1-4GB of NAND flash on an option card.

There is an incomplete Linux reverse engineering effort, but it doesn't
look particularly all that interesting, and likely slower than an SSD by
today's standards.

https://github.com/yarrick/turbomem

-Bryan.

Re: audio stops frequently with current

[Bryan Steele]

...
> azalia1 at pci11 dev 0 function 4 "AMD 17h/3xh HD Audio" rev 0x00: msi
> azalia1: codecs: Realtek ALC892
> audio0 at azalia1

There is still an issue with MSI interrupts for HD Audio devices on
AMD systems, in the past we've been able to workaround it in the driver.
You can certainly try that. But from previous testing by other users
this trick no longer works for newer AMD chipsets.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/azalia.c.diff?r1=1.246=1.245

Your device would be "PCI_PRODUCT_AMD_17_3X_HDA".

-Bryan.

Re: seeing carp interface state change for unknown reason ; cluestick hunting

[Bryan Stenson]

Thanks for the response.  I've mounted a ramdisk at /mnt and have run
"doas route -n monitor > /mnt/route.monitor" in a tmux session for a
few days.  Here are some details:

erl3-01$ grep carp1 route.monitor  | sort | uniq -c
  91 RTM_ADD: Add Route: len 192, priority 146, table 0, if# 6, name
carp1, pid: 0, seq 0, errno 0
 428 RTM_ADD: Add Route: len 192, priority 18, table 0, if# 6, name
carp1, pid: 0, seq 0, errno 0
  43 RTM_DELETE: Delete Route: len 192, priority 146, table 0, if# 6,
name carp1, pid: 0, seq 0, errno 0
 478 RTM_DELETE: Delete Route: len 192, priority 18, table 0, if# 6,
name carp1, pid: 0, seq 0, errno 0
  31 RTM_IFINFO: iface status change: len 168, if# 6, name carp1,
link: backup, mtu: 1500,
flags:
  31 RTM_IFINFO: iface status change: len 168, if# 6, name carp1,
link: invalid, mtu: 1500, flags:
  31 RTM_IFINFO: iface status change: len 168, if# 6, name carp1,
link: master, mtu: 1500,
flags:
   1 RTM_RESOLVE: Route created by cloning: len 192, priority 146,
table 0, if# 6, name carp1, pid: 0, seq 0, errno 0
 385 RTM_RESOLVE: Route created by cloning: len 192, priority 18,
table 0, if# 6, name carp1, pid: 0, seq 0, errno 0

erl3-01$ grep vlan100 route.monitor  | sort | uniq -c
  31 RTM_IFINFO: iface status change: len 168, if# 8, name vlan100,
link: active, mtu: 1500,
flags:
  31 RTM_IFINFO: iface status change: len 168, if# 8, name vlan100,
link: no carrier, mtu: 1500,
flags:

erl3-01$ grep cnmac2 route.monitor  | sort | uniq -c
  57 RTM_ADD: Add Route: len 192, priority 3, table 0, if# 3, name
cnmac2, pid: 0, seq 0, errno 0
  57 RTM_DELETE: Delete Route: len 192, priority 3, table 0, if# 3,
name cnmac2, pid: 0, seq 0, errno 0
  31 RTM_IFINFO: iface status change: len 168, if# 3, name cnmac2,
link: active, mtu: 1500,
flags:
  31 RTM_IFINFO: iface status change: len 168, if# 3, name cnmac2,
link: no carrier, mtu: 1500,
flags:

It looks like the underlying cnmac2 interface is flapping...so, that's a bummer.

As generally underpowered as this machine is, might the kernel be
overwhelmed with other tasks, and have a watchdog timeout mark the
cnmac2 interface as down (due to some expired timeout)?

Just grasping for something here...my next steps are to swap this unit
out with the other one (to try and eliminate hardware failure of THIS
unit).  Any other suggestions?

On Mon, Feb 1, 2021 at 3:04 AM David Gwynne  wrote:
>
>
>
> > On 1 Feb 2021, at 6:02 pm, Bryan Stenson  wrote:
> >
> > Hi all -
> >
> > I'm trying to setup a pair of ERL3 octeon routers in master/standby
> > mode via carp/pfsync to route traffic from my internal lan to the
> > internet.  I've seen strange behavior wrt carp on these machines, so
> > in an attempt to reduce the problem, I've removed one completely.
> >
> > Even with only a single box (ERL3-01) on the network configured as a
> > carp member, the carp interface state periodically changes (as seen
> > from ifstated(8)).
> >
> > I'm wondering if disconnecting the other ERL3 device is a valid isolated 
> > test.
> > 1.  Will/might this cause issues with the carp device, as it cannot
> > determine state from any other host?
>
> If carp state flaps around while it is the only device on the network, that 
> would imply the parent device is flapping around.
>
> > 2.  Will/might this cause issues as it cannot send/receive pfsync
> > updates (the other node is disconnected).
>
> pfsync doesn't really care about carp state.
>
> > 3.  Is there something else in my setup causing carp to fail here?
>
> I'd be running "route monitor" and looking for link state changes on the carp 
> parent interface.
>
> > 4.  Could this be hardware/temperature related to this ERL3?  Wouldn't
> > I see an additional error in dmesg if the physical device (cnmac2)
> > failed periodically?
> >
> > I'd appreciate any pointers here...I feel like I'm missing something dumb.
>
> My first ideas are above. If it turns out the carp parent is stable we can 
> try come up with something else.
>
> dlg
>
> >
> > Thanks in advance.
> >
> > Bryan
> >
> > Here are some of my configs.  If I've missed including something
> > critical to help describe my setup, please let me know and I'll add
> > it.
> >
> > ## Help me OBSD-Misc Kenobi.  You're my only hope. ##
> >
> > erl3-01# uname -a
> > OpenBSD erl3-01.siliconvortex.com 6.8 GENERIC#522 octeon
> >
> > erl3-01# dmesg
> > ...
> > carp1: state transition: BACKUP -> MASTER
> > carp1: state transition: BACKUP -> MASTER
> > carp1: state transition: BACKUP -> MASTER
> > carp1: state transition: BACKUP -> MASTER
> > carp1: state transition: BACKUP -> MASTER
> > carp1: state transition

seeing carp interface state change for unknown reason ; cluestick hunting

[Bryan Stenson]

Hi all -

I'm trying to setup a pair of ERL3 octeon routers in master/standby
mode via carp/pfsync to route traffic from my internal lan to the
internet.  I've seen strange behavior wrt carp on these machines, so
in an attempt to reduce the problem, I've removed one completely.

Even with only a single box (ERL3-01) on the network configured as a
carp member, the carp interface state periodically changes (as seen
from ifstated(8)).

I'm wondering if disconnecting the other ERL3 device is a valid isolated test.
1.  Will/might this cause issues with the carp device, as it cannot
determine state from any other host?
2.  Will/might this cause issues as it cannot send/receive pfsync
updates (the other node is disconnected).
3.  Is there something else in my setup causing carp to fail here?
4.  Could this be hardware/temperature related to this ERL3?  Wouldn't
I see an additional error in dmesg if the physical device (cnmac2)
failed periodically?

I'd appreciate any pointers here...I feel like I'm missing something dumb.

Thanks in advance.

Bryan

Here are some of my configs.  If I've missed including something
critical to help describe my setup, please let me know and I'll add
it.

## Help me OBSD-Misc Kenobi.  You're my only hope. ##

erl3-01# uname -a
OpenBSD erl3-01.siliconvortex.com 6.8 GENERIC#522 octeon

erl3-01# dmesg
...
carp1: state transition: BACKUP -> MASTER
carp1: state transition: BACKUP -> MASTER
carp1: state transition: BACKUP -> MASTER
carp1: state transition: BACKUP -> MASTER
carp1: state transition: BACKUP -> MASTER
carp1: state transition: BACKUP -> MASTER

erl3-01# tail mbox
Mon, 1 Feb 2021 06:49:26 + (UTC)
From: Charlie Root 
Date: Mon, 1 Feb 2021 06:49:25 + (UTC)
To: root@localhost
Subject: carp master changed
Message-ID: <515eb74cff427...@erl3-01.siliconvortex.com>
Status: RO

master is now erl3-01.siliconvortex.com


erl3-01# sysctl -a | grep carp
net.inet.carp.allow=1
net.inet.carp.preempt=1
net.inet.carp.log=2

erl3-01# cat /etc/hostname.carp1
#carp for lan side
192.168.122.1/23 carpdev vlan100 vhid 1 pass somethinglongandsecret

erl3-01# cat /etc/hostname.vlan100
vnetid 100 parent cnmac2
up

erl3-01# cat /etc/hostname.cnmac2
inet 192.168.1.253 255.255.254.0

erl3-01# cat /etc/hostname.pfsync0
up syncdev cnmac1

erl3-01# cat /etc/hostname.cnmac1
inet 10.10.200.1 255.255.255.252

erl3-01# cat /etc/ifstated.conf
# Initial State
init-state auto

# Macros
if_carp_up="carp1.link.up"
if_carp_down="!carp1.link.up"

state auto {
  if $if_carp_up {
set-state master
  }

  if $if_carp_down {
set-state backup
  }
}

state master {
  init {
run "echo master is now `hostname` | mail -s 'carp master changed'
root@localhost"
}

  if $if_carp_down {
set-state backup
  }
}

state backup {
  init {
run "echo backup is now `hostname` | mail -s 'carp master changed
root@localhost"
  }

  if $if_carp_up {
set-state master
  }
}

erl3-01# cat /etc/pf.conf
# adopted from https://www.openbsd.org/faq/pf/example1.html
wan_dev = cnmac0
lan_dev = cnmac2
carp_dev = vlan100
pfsync_dev = cnmac1
table  { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 \
172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
192.168.0.0/16 198.18.0.0/15 198.51.100.0/24\
203.0.113.0/24 }

# carp
pass quick on $lan_dev proto carp keep state (no-sync)

# pfsync
pass quick on $pfsync_dev proto pfsync keep state (no-sync)

set block-policy drop
set loginterface $wan_dev
set skip on lo0

match in all scrub (no-df random-id max-mss 1440)

# redirect DNS queries to localhost
pass in quick on { $carp_dev $lan_dev } proto { udp tcp } from any to
any port domain rdr-to 192.168.1.253 port domain

# NAT to the world
match out on $wan_dev inet from !($wan_dev:network) to any nat-to ($wan_dev:0)

antispoof quick for { $wan_dev }

# martians
block in quick on $wan_dev from  to any
block return out quick on $wan_dev from any to 

block all

# manage buffer bloat
queue outq on $wan_dev flows 1024 bandwidth 3M max 3M qlimit 1024 default
queue inq on $lan_dev flows 1024 bandwidth 45M max 45M qlimit 1024 default

pass out quick inet

pass in on { $carp_dev $lan_dev } inet

Re: FDE disk setup instructions are misleading when installing from USB

[Bryan Wright]

> On Jan 23, 2021, at 09:34, tetrahe...@danwin1210.me wrote:
> 
> On Fri, Jan 22, 2021 at 04:44:31PM -0800, Bryan Wright wrote:
>> 
>> 
>>> but to set up FDE I had to reference the official FAQ
>> 
>> Referring to the official documentation is a key distinction between 
>> successful OpenBSD use and that of many other systems; the early that gets 
>> hammered home the better, right?  It’s practically unGoogleable, if that’s a 
>> word.
>> 
>> It can be super frustrating at times, but half blindly following a guide or 
>> entering some unexplained command from Stackoverflow, while being much 
>> easier, has got to be among the most dangerous patterns we can adopt.  Using 
>> OpenBSD has been a very humbling experience, but I’ve learned so, so much by 
>> being forced to adopt better practices.
> 
> For the record, I started by reading the FAQ from start to finish, before I 
> installed anything.
> 
> Unfortunately it's a little difficult to connect to reality (or even 
> remember) much of what one reads when one does this.
> 
> "Does this obscure technical reference apply to my situation? I don't know, I 
> haven't worked with anything related to it yet!"
> 
> To make matters worse, there are an awful lot of details that are not 
> realistic to get out of the official documentation... I would have had to 
> read a significant percentage of all the manpages, and a lot of mailing list 
> traffic, in order to arrive at the same steps provided in how-tos like 
> <https://www.c0ffee.net/blog/openbsd-on-a-laptop/>.
> 
> Could I have done that? Sure. Would spending 40-80 hours reading 
> documentation just to get a laptop set up, when I don't know whether I'm 
> going to use it for more than experimental purposes, have been a good use of 
> my time? Certainly not.
> 
> I have no quarrel with OpenBSD requiring new users to immediately dive into 
> parts of the system that other operating systems try as hard as possible to 
> hide... but for practical reasons it does seem necessary to do a little 
> hand-holding along the way.
> 
> I am therefore extremely grateful to Cullum Smith and the other "OpenBSD on a 
> laptop" howtos for making it feasible to get this far.

Yeah, absolutely.  I won’t pretend I didn’t read all the same sources you 
mentioned. I hope I didn’t come across as proud or stuffy; I’m a nobody, and I 
could use a lot of hand holding myself.  I totally hear you. 

I don’t speak for the developers, but it’s been stated many times that they 
make the system for themselves, and if we can use it, great. Growing the number 
of new users would be much easier than multiplying the number of competent, 
contributing developers, and it can turn into us feeling like they owe us 
things they never signed up for. There is plenty of help, for sure, but hand 
holding is not likely to be a priority any time soon.  That’s just how it is, 
and I can’t fault anyone for it.  

Perhaps someone will make some changes to the installer or documentation. But, 
I can tell you, a diff,  or at least a proposed specific solution, will always 
go a lot further than pointing out a potential problem, simply because there 
are relatively few developers and they all have things they are busy with. 
I’m not sure what the best solution would be, but if you’ve got an idea, you 
should definitely submit it.

I hope it all works out for you and that any perceived faults or difficulties 
won’t keep you from finding all the advantages of OpenBSD. 

Re: FDE disk setup instructions are misleading when installing from USB

[Bryan Wright]

> but to set up FDE I had to reference the official FAQ

Referring to the official documentation is a key distinction between successful 
OpenBSD use and that of many other systems; the early that gets hammered home 
the better, right?  It’s practically unGoogleable, if that’s a word.

It can be super frustrating at times, but half blindly following a guide or 
entering some unexplained command from Stackoverflow, while being much easier, 
has got to be among the most dangerous patterns we can adopt.  Using OpenBSD 
has been a very humbling experience, but I’ve learned so, so much by being 
forced to adopt better practices. 

Glad you got yours set up. All the best. 

Re: FDE disk setup instructions are misleading when installing from USB

[Bryan Wright]

Because, there is no guarantee that the drives will be loaded in a given order 
on boot, there would be little benefit in changing the example.  If the entire 
page is read, everything should be clear enough, but if anything were to be 
done, perhaps there could be a reminder within each subsection to verify the 
disk with ‘sysctl hw.disknames’ and ‘disklabel’.  
Simply changing the example, though, won’t fix the problem of a user not paying 
sufficient attention to protect themselves from themselves. 

> On Jan 22, 2021, at 14:20, tetrahe...@danwin1210.me wrote:
> 
> When installing from a USB thumb drive, the machine's internal HDD usually 
> shows up as sd0 and the thumb drive as sd1.
> 
> However, the FDE installation instructions 
>  suggest that we should 
> overwite the first 1MB of sd1 with zeros:
> 
>> # dd if=/dev/zero of=/dev/rsd1c bs=1m count=1
> 
> If the user is installing from a USB drive, this will lead to them 
> overwriting the USB drive, rather than the pseudo-device.
> 

Re: phonetics on OpenBSD: IPA transcription

[Bryan Linton]

On 2021-01-08 20:42:20, Jan Stary  wrote:
> Is there anyone doing phonetics on OpenBSD?
> 
> [...]
> 
> If there are actualy phoneticians running on OpenBSD,
> how do you do it?
> 
>   Thank you
> 
>   Jan
>

Hello,

I wrote about my setup in an email to misc@ about a year ago.

https://marc.info/?l=openbsd-misc=153960218915258=2

(You may need to manually set your browser to UTF-8 to see
the line of IPA symbols in it.)

In brief, I installed ports/inputmethods/uim and use it to switch
into IPA layout.  I can write IPA symbols in both GUI and terminal
applications, though getting the symbols to show up correctly in
terminals requires a little more work.

Base vi doesn't support them, but nvi from ports works fine.
Trying to type commands into (n)vi while in IPA mode obviously
doesn't do what one expects though, so be sure to switch out of
it first.  I don't use emacs or mg, so can't comment on whether or
not they support them, but I suspect emacs most likely does.

I switch between layouts with either CTRL-shift or ALT-shift, and
then type according to the X-SAMPA rules which are documented in
/usr/local/share/uim/ipa-x-sampa.scm
which is installed by the uim port mentioned above.

Hopefully the above should get you a good working setup.  At the
very least, I'd recommend that you get your system set up to allow
X-SAMPA input since that seems to be the universal standard for
reducing the IPA into ASCII.  That way, no matter what system you
type IPA on, you'll have a consistent layout and won't need to
relearn anything.

Hope this helps!

-- 
Bryan

Re: i386 "panic: pci_make_tag: bad request" after acpi sleep states

[Bryan Steele]

On Tue, Dec 29, 2020 at 12:11:29PM -0500, Ian Darwin wrote:
> On Tue, Dec 29, 2020 at 09:42:59AM -0500, Bryan Steele wrote:
> > On Mon, Dec 28, 2020 at 01:20:29PM -0500, Ian Darwin wrote:
> > > Kernel is OpenBSD 6.8-current (GENERIC) #561: Sun Dec 27 18:29:43 MST 2020
> > > 
> > > Machine is a Wyse C90 - orignially sold as a "thin client" - tiny 
> > > machine, no serial port (ps and trace typed in).
> > > HW Info at https://www.parkytowers.me.uk/thin/wyse/cx0/
> > > Was planning to use it as a wifi bridge, so tiny is fine.
> > > 
> > > "Latest" BIOS (2012 edition). "BIOS reset" did not help.
> > > cpu info: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1.01 GHz, 
> > > 06-0d-00
> > > RAM: 1GB (despite reported as 3/4 of that)
> > 
> > Long shot, but could you maybe show the output of "machine memory" for
> > both boot/pxeboot? I'm curious if the memory map is reportedly
> > differently between a working boot and a bad one.
> 
> 
> Good suggestion, and indeed, it differs a little:
> 
> Using pxeboot:
> 
> CLIENT MAC ADDR: 00 80 64 xx xx xx GUID: C2020018-0403-0920-EE9A-0080648793AD
> CLIENT IP: 192.168.42.245 MASK: 255.255.255.0 DHCP IP: 192.168.42.254
> GATEWAY IP: 192.168.42.254
> probing: pc0 pci pxe![2.1] mem[546K 765M a20-on]
> disk: hd0+
> net: nac 00:80:64:xx:xx:xx, ip 192.168.42.245, server 192.168.42.254
> >> OpenBSD, i386 PXEBOOT 3.43 boot> machine mem
> Region 0: type 1 at 0x0 for 546KB
> Region 1: type 2 at 0x88800 for 94KB
> Region 2: type 2 at Oxe for 128KB
> Region 3: type 1 at 0x10 for 784192KB
> Region 4: type 3 at Ox2fed for 28KB
> Region 5: type 4 at 0x2fed7000 for 4KB
> Region 6: type 2 at Ox2fed8000 for 160KB
> Region 7: type 2 at Ox2ff0 for 1024KB
> Region 8: type 2 at Ox3000 for 262144KB
> Region 9: type 2 at Oxe000 for 262144KB
> Region 10: type 2 at Oxfec0 for 64KB
> Region 11: type 2 at Oxfee0 for 4KB
> Region 12: type 2 at Oxfff0 for 1024KB
> Low ram: 546KB High ram: 784192KB Total free nemory: 784738KB
> boot>
>  
> Using /boot:
> 
> >> OpenBSD/i386 BOOT 3.44
> boot> machine mem
> Region 0: Type 1 at 0x0x for 631KB
> Region 1: Type 2 at 0x9dc99 for 9KB
> Region 2: type 2 at 0xe for 128kb
> (remainder the same)
> 
> Could Region 1 being so microscopic cause problems? If it got used for 
> anything?
>
Type 2 here means the memory is reserved (not available for use), while
type 1 (and generally 3) can be used by the bootloader or kernel.

> Thx for looking.

No problem, it's interesting that pxeboot actually has less memory
below 1Meg compared to normal /boot, but I guess that makes sense
in that environmnet.

But curious to hear from people more familiar with the boot blocks
have an ideas.

> > > Full dmesg below; full ACPI attached.
> > > 
> > > Boot used Kernel  FromResult
> > > pxeboot   bsd.rd  tftpOK
> > > pxeboot   bsd hd0aOK (via 
> > > tftpboot/etc/conf)
> > > boot  bsd hd0apanic
> > > 
> > > I.e., Boots fine with pxeboot "set device hd0a", but booting exact same 
> > > kernel off same disk via /boot causes panic.
> > > 
> > > It's an older machine so it's likely a buggy acpi, not worth massive 
> > > investment of time, just wonder if there's an easy workaround.
> > > Presume it's getting something different in some AML, based on where boot 
> > > code loaded from,
> > > or else pxeboot vs boot setting environment slightly differently?
> > > 
> > > On screen after panic:
> > > 
> > > bios0: WYSE C CLASS
> > > acpi0 at bios0: ACPI 3.0
> > > acpi0: sleep states S0 S1 S3 s4 S5panic: pci_make_tag: bad request
> > > Stopped at db_enter+0x4: popl %eb
> > > 
> > > trace:
> > > 
> > > db_enter(d0e5e189,d10f6704,2,0,0) at db_enter+0x4
> > > panic(d0c3d47d,1,d10f6750,d0854f11,0) at panic+0xd3
> > > pci_make_tag(0,0,11,0) at pci_make_tag+0x95
> > > acpi_gasio(d2b1b400,0,2,6e,11,1,1,d10f67d8) at acpi_gasio+0x1f1
> > > aml_opreg_pcicfg_handler(0,0,6e,11,1,d10f67d8) at 
> > > aml_opreg_pcicfg_handler+0x21
> > > aml_rwgen(d2b338c4,373,1,d2b3f304,0,1) at aml_rwgen+0x571
> > > aml_rwfield(d2b2bc04,0,1,d2b3f304,0) at aml_rwfield+0x37a
> > > aml_eval(d2b40704,d2b2bc04,74,d10f692c,0) at aml_eval+0x17a
> > > aml_parse(d2b40704,74,d2b2f804) at aml_parse+0x2b15
> > > aml_parse(d2b4

Re: i386 "panic: pci_make_tag: bad request" after acpi sleep states

[Bryan Steele]

On Mon, Dec 28, 2020 at 01:20:29PM -0500, Ian Darwin wrote:
> Kernel is OpenBSD 6.8-current (GENERIC) #561: Sun Dec 27 18:29:43 MST 2020
> 
> Machine is a Wyse C90 - orignially sold as a "thin client" - tiny machine, no 
> serial port (ps and trace typed in).
> HW Info at https://www.parkytowers.me.uk/thin/wyse/cx0/
> Was planning to use it as a wifi bridge, so tiny is fine.
> 
> "Latest" BIOS (2012 edition). "BIOS reset" did not help.
> cpu info: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1.01 GHz, 
> 06-0d-00
> RAM: 1GB (despite reported as 3/4 of that)

Long shot, but could you maybe show the output of "machine memory" for
both boot/pxeboot? I'm curious if the memory map is reportedly
differently between a working boot and a bad one.

-Bryan.

> Full dmesg below; full ACPI attached.
> 
> Boot used Kernel  FromResult
> pxeboot   bsd.rd  tftpOK
> pxeboot   bsd hd0aOK (via 
> tftpboot/etc/conf)
> boot  bsd hd0apanic
> 
> I.e., Boots fine with pxeboot "set device hd0a", but booting exact same 
> kernel off same disk via /boot causes panic.
> 
> It's an older machine so it's likely a buggy acpi, not worth massive 
> investment of time, just wonder if there's an easy workaround.
> Presume it's getting something different in some AML, based on where boot 
> code loaded from,
> or else pxeboot vs boot setting environment slightly differently?
> 
> On screen after panic:
> 
> bios0: WYSE C CLASS
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S1 S3 s4 S5panic: pci_make_tag: bad request
> Stopped at db_enter+0x4: popl %eb
> 
> trace:
> 
> db_enter(d0e5e189,d10f6704,2,0,0) at db_enter+0x4
> panic(d0c3d47d,1,d10f6750,d0854f11,0) at panic+0xd3
> pci_make_tag(0,0,11,0) at pci_make_tag+0x95
> acpi_gasio(d2b1b400,0,2,6e,11,1,1,d10f67d8) at acpi_gasio+0x1f1
> aml_opreg_pcicfg_handler(0,0,6e,11,1,d10f67d8) at 
> aml_opreg_pcicfg_handler+0x21
> aml_rwgen(d2b338c4,373,1,d2b3f304,0,1) at aml_rwgen+0x571
> aml_rwfield(d2b2bc04,0,1,d2b3f304,0) at aml_rwfield+0x37a
> aml_eval(d2b40704,d2b2bc04,74,d10f692c,0) at aml_eval+0x17a
> aml_parse(d2b40704,74,d2b2f804) at aml_parse+0x2b15
> aml_parse(d2b40704,69,38) at aml_parse+0x351
> aml_parse(d2b40704,54,9,d2b36518,d2b40704) at aml_parse+0x351
> aml_eval(0,d2b36544,74,0,0) at aml_eval+0x277
> aml_evalnode(d10f6b10,d2b36504,0,0,d10f6ac0) at aml_evalnode+0xae
> aml_evalinteger(d1b1b400,d2b36a84,d0c17e38,0,0,d10f6b30) at 
> aml_evalinteger+0xae
> acpi_foundprw(d2b36d04,d2b1b400) at acpi_foundprw+0x2f
> aml_find_node(d2b36a84,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x?2
> aml_find_node(d2b336c4,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
> aml_find_node(d2b296c4,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
> aml_find_node(d2b31484,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
> aml_find_node(d0eba1a8,d0b9299b,d0859b90,d2b1b400) at aml_find_node+0x9b
> acpi_init_gpes (d2b1b400) at acpi_init_gpes+0x195 
> acpi_attach_common(d2b1b400,f67a0) at acpi_attach_common+0x355
> acpi_attach(d2b210c0,d2b1b400,d10f6db8) at acpi_attach+0xZc
> config attach(d2b210c0,d0df60d4,d10f6db8,d0928b30) at config attach+0x18a
> config_found_sm(d2b210c0,d10f6db8,d0928630,0) at config_found_sm+0x29
> biosattach(d2b21080, d2b210c0,d10f6eb8) at biosattach+0x19a
> config attach (d2b21080, d0df 4c94,d10f6eb8, d02431f0) at config_attach+0x18a 
> config_found_sm(dZbZ1080, d10f beb8, d02431f0,0) at config_found_sm+0x29 
> mainbus_attach(0,d2b21080,0) at mainbus attach_0x5c
> config_attach(0,d0df 2614,0,0) at config_attach+0x18a
> cpu_configure(lie340b7,10f 4000, 1103000, 10 7000,0) at cpu_configure+0x24 
> main(0,0,0,0,0) at main+0x311
> ddb>
> 
> ps:
>TID   PID  UID  PRFLAGS  PFLAGS  CPU  COMMAND
> *0 00  0x1  0x200 0  swapper
> 
> Dmesg:
> ssh wyse cat /var/run/dmesg.boot
> OpenBSD 6.8-current (GENERIC) #561: Sun Dec 27 18:29:43 MST 2020
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem  = 803459072 (766MB)
> avail mem = 772513792 (736MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 01/16/12, BIOS32 rev. 0 @ 0xfdd30, SMBIOS rev. 2.6 @ 
> 0x2fed8000 (48 entries)
> bios0: vendor Phoenix Technologies version "1.0G" date 01/16/2012
> bios0: WYSE C CLASS
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP SSDT APIC MCFG HPET
> acpi0: wakeup devices PWRB(S4) PCI0(S5) PS2M(S3) PS2K(S3) USB1(S4) USB2(S4) 
> USB3(S4) USB4(S4) USB5(S4) HDAC(S5) SP2P(

Re: Programmed wakeup from suspend/hibernate

[Bryan Linton]

On 2020-12-24 10:31:22, Ian Darwin  wrote:
> On Thu, Dec 24, 2020 at 11:51:26AM +0100, Gabriel Hondet wrote:
> > Hi,
> > 
> > How can I program my computer to automatically wake from suspend to ram
> > or suspend to disk at a certain time?
> > 
> > My goal is to suspend a server every day from, say, 11 pm to 7am.
> 
> For suspending at night, use see the cron man page.
> 
> For waking up in the morning, of course, the OS isn't running so there is 
> nothing
> it can do. Some but not all PC BIOSes have a scheduling feature. Otherwise a
> $10 mechanical timer to cut the power (well after the suspend is finished!) 
> and
> turn it back on in the morning.
> 

If shutting down the server entirely (instead of suspending it)
were an option, you could schedule a cron job to shut it down at a
given time and send a WoL (Wake on LAN) packet from another
computer on the network to wake it up again.

Oh, I just skimmed the ifconfig manpage and found the following:

wol Enable Wake on LAN (WoL).  When enabled, reception of a 
WoL frame will cause the network card to power up the
system from standby or suspend mode.  WoL frames are sent
using arp(8).

So it looks like you could even do this while the system were
suspended if your network card supports it.  Of course, this
depends on having another server on the same, physical LAN as the
server in question, so the mechanical switch suggestion above might be
the only option if that's not the case.

-- 
Bryan

Re: gcc: error trying to exec 'cc1': execvp: no such file or directory

[Bryan Steele]

On Fri, Nov 20, 2020 at 02:02:56PM +, Rodrigo Readi wrote:
> 
> On Fri, 20 Nov 2020, Bryan Steele wrote:
> 
> > It took you *6* emails before finally mentioning which platform were
> > on, even after being asked..
> 
> Yes, excuse me, I answered to Nick Samsung nc10, but not mentioned i386.
> 
> > i386 removed the base gcc compiler in OpenBSD 6.6, so the binaries were
> 
> Your link for 6.8 says: "Disabled gcc in base on armv7 and i386."

I linked to the 6.6 page, not 6.8. Yes, it was disabled, and henced
removed from the distribution sets for i386 (and armv7), but not from
the tree as other architectures still use base-gcc. New installs do
not include them on i386/armv7, but upgrades do not removed obsolete
binaries in general.

> > obsolete even on your 6.7 install.. i386 has been a default clang arch
> > since OpenBSD /6.2/.
> 
> Clang was default, gcc may be obsolete, but /usr/bin/gcc is till now
> there, broken. In the upgrade instructions is not mentioned to delete
> it:
> 
> https://www.openbsd.org/66.html
> 
> The man page of gcc-local is till now (6.8) delivered in comp68.tgz

The man page is installed on all architectures so that's irrelevant.

> Rod.

Re: gcc: error trying to exec 'cc1': execvp: no such file or directory

[Bryan Steele]

On Fri, Nov 20, 2020 at 11:27:46AM +, Roderick wrote:
> 
> On Thu, 19 Nov 2020, Todd C. Miller wrote:
> 
> > On Thu, 19 Nov 2020 22:07:33 +, Roderick wrote:
> > 
> > > g++, gcc and gcov in /bin are from Apr 13, 2019. The rest are from
> > > Oct 5, 2020.
> > 
> > That explains your problem.  The upgrade would have removed any
> > obsolete /usr/lib/gcc-lib/amd64-unknown-openbsd* directory which
> > the old gcc binaries require.
> 
> tar tvzf base68.tgz | grep gcc
> 
> gives nothing. It seems, gcc was removed from i386. That explains
> the old date of my gcc binary that was never deleted. But that

...

It took you *6* emails before finally mentioning which platform you
were running, even after being asked..

i386 removed the base gcc compiler in OpenBSD 6.6, so the binaries were
obsolete even on your 6.7 install.. i386 has been a default clang arch
since OpenBSD /6.2/!

https://www.openbsd.org/66.html

Re: gcc: error trying to exec 'cc1': execvp: no such file or directory

[Bryan Steele]

Roderick wrote:
> It seems, gcc was removed from i386. That explains the old date of my
gcc binary that was never deleted.

It took you *6* emails before finally mentioning which platform were
on, even after being asked..

i386 removed the base gcc compiler in OpenBSD 6.6, so the binaries were
obsolete even on your 6.7 install.. i386 has been a default clang arch
since OpenBSD /6.2/.

https://www.openbsd.org/66.html

Re: support new

[Bryan Steele]

On Tue, Nov 17, 2020 at 04:55:55PM +0100, Emre Kal wrote:
> If my request is rejected again, please provide me with the *objective* 
> reasons why I am not allowed to list my services as a OpenBSD consultant.

Yeah, no.

> I believe I am entitled ...

There's your mistake right there.

-Bryan.

Re: OpenBSD 6.8 (release) guest (qemu/kvm) on Linux 5.9 host (amd64) fails with protection fault trap

[Bryan Steele]

> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> 
> cpu0 at mainbus0: apid 0 (boot processor)
> 
> cpu0: AMD Opteron 22xx (Gen 2 Class Opteron), 1497.89 MHz, 0f-06-01
> 
> cpu0:
> FPU,VME,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
> 
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 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: smt 0, core 0, package 0
> 
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> 
> cpu0: apic clock running at 999MHz
> 
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
> 
> acpihpet0 at acpi0: 1 Hz
> 
> acpimcfg0 at acpi0
> 
> acpimcfg0: addr 0xb000, bus 0-255
> 
> acpiprt0 at acpi0: bus 0 (PCI0)
> 
> "ACPI0006" at acpi0 not configured
> 
> acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> 
> acpicmos0 at acpi0
> 
> "PNP0A06" at acpi0 not configured
> 
> "PNP0A06" at acpi0 not configured
> 
> "QEMU0002" at acpi0 not configured
> 
> "ACPI0010" at acpi0 not configured
> 
> acpicpu0 at acpi0: C1(@1 halt!)
> 
> pvbus0 at mainbus0: KVM
> 
> pvclock0 at pvbus0
> 
> pci0 at mainbus0 bus 0
> 
> pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00
> 
> vga1 at pci0 dev 1 function 0 "Bochs VGA" rev 0x02
> 
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> 
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> 
> virtio0 at pci0 dev 2 function 0 "Qumranet Virtio Network" rev 0x00
> 
> vio0 at virtio0: address 9a:00:00:00:00:00
> 
> virtio0: msix shared
> 
> xhci0 at pci0 dev 3 function 0 vendor "Red Hat", unknown product 0x000d rev
> 0x01: apic 0 int 23, xHCI 0.0
> 
> usb0 at xhci0: USB revision 3.0
> 
> uhub0 at usb0 configuration 1 interface 0 "Red Hat xHCI root hub" rev
> 3.00/1.00 addr 1
> 
> virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Storage" rev 0x00
> 
> vioblk0 at virtio1
> 
> scsibus1 at vioblk0: 1 targets
> 
> sd0 at scsibus1 targ 0 lun 0: 
> 
> sd0: 51200MB, 512 bytes/sector, 104857600 sectors
> 
> virtio1: msix shared
> 
> pcib0 at pci0 dev 31 function 0 "Intel 82801IB LPC" rev 0x02
> 
> ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x02: msi, AHCI 1.0
> 
> ahci0: port 2: 1.5Gb/s
> 
> scsibus2 at ahci0: 32 targets
> 
> cd0 at scsibus2 targ 2 lun 0:  removable
> 
> ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 0 int
> 16
> 
> iic0 at ichiic0
> 
> isa0 at pcib0
> 
> isadma0 at isa0
> 
> com0 at isa0 port 0x3f8/8 irq 4: 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
> 
> pms0 at pckbc0 (aux slot)
> 
> wsmouse0 at pms0 mux 0
> 
> pcppi0 at isa0 port 0x61
> 
> spkr0 at pcppi0
> 
> lpt0 at isa0 port 0x378/4 irq 7
> 
> axe0 at uhub0 port 5 configuration 1 interface 0 "ASIX Electronics AX88772"
> rev 2.00/0.01 addr 2
> 
> axe0: AX88772, address 00:50:b6:0b:cf:f0
> 
> ukphy0 at axe0 phy 16: Generic IEEE 802.3u media interface, rev. 1: OUI
> 0x000ec6, model 0x0006
> 
> vscsi0 at root
> 
> scsibus3 at vscsi0: 256 targets
> 
> softraid0 at root
> 
> scsibus4 at softraid0: 256 targets
> 
> root on sd0a (50fd7af99e5255c1.a) swap on sd0b dump on sd0b
> 
> 
> I have been trying to disable features on qemu invocation, changing the
> "-machine" parameter and unloading the Linux msr module, without too much
> success.  Folks in #qemu suggested the workaround I'm using and advised that
> the problem may be a CPU feature that I ought to disable, somehow.
> 
> I know about https://www.openbsd.org/lyrics.html#62 (No QEMU, only DDB) :-)
> However, if anybody has bumped into this and can successfully run OpenBSD as
> a guest on this type of hardware, I would be grateful if they could throw me
> a few ideas for me to try out.
> 
> Thanks!
> 
> 
> Gabriel

Sorry, this is either a QEMU/KVM bug or user config error. The kernel
code was written to run on actual hardware and we avoid additional
complexity caused by buggy VMs.

Absent from this report is what version of KVM/QEMU is being used,
but there are some indications it may be rather ancient..

You haven't said what happens when you don't try to explictly override
the '-cpu' argument, but really it should be very clear to you that
KVM is NOT matching the host CPU behaviour, despite what it claims. You
can easily verify that by booting OpenBSD on the bare metal.

-Bryan.

Re: Switching layout in vmm linux guest on OpenBSD host with english layout only

[Bryan Steele]

On Wed, Sep 30, 2020 at 07:44:46AM +, Martin wrote:
> I'm running headless Debian guest with two keyboard layouts. *.qcow2 qemu 
> image has been imported from Debian host.
> Graphical mode of vmm and qemu with Debian guest access using vncviewer for 
> both hosts. The guest itself has vncserver to share screen using headless 
> setup.
> 
> Layout switching works fine in qemu on Debian host even the host has single 
> english layout.
> 
> But layout switching doesn't work in vmm and can't be changed in any way. 
> OpenBSD host uses single english layout as Debian host.
> 
> Looking any solution on how to fix it. Please suggest.
> 
> Martin

OpenBSD vmm/vmd(8) doesn't emulate a keyboard, so there can be no
keyboard layouts.

This sounds like something you should be configured in the VNC
client or server..

-Bryan.

Re: VMM vulns?

[Bryan Steele]

On Wed, Sep 02, 2020 at 09:36:17PM -0400, Bryan Steele wrote:
> The direct map issue on Intel CPUs hinted at by Maxime was also fixed
> by kettenis@, deraadt@ and millert@.

Sorry.. and mpi@

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

> 
> -Bryan.

Re: VMM vulns?

[Bryan Steele]

On Wed, Sep 02, 2020 at 02:03:35AM -0700, Mike Larkin wrote:
> On Wed, Sep 02, 2020 at 03:35:54AM +0200, f...@disciples.com wrote:
> > https://twitter.com/m00nbsd/status/1291257985734410244
> >
> > I don't want to bump that old thread or start any arguments about this. I'm 
> > just curious if this tweet is accurate or have these issues been addressed? 
> > Were any of Maxime's suggestions implemented?
> >
> 
> I am not sure if anyone picked up the remaining issues after I left active
> vmm development. At that time, I sent out my WIP diff for the TLB flush issue
> Maxime reported; it was not 100% complete. I am not sure if anyone is working
> on that or not, or any other issues he reported.
> 
> -ml

As far as I'm aware all the pvclock(4) issues were addressed by pd@ and
mortimer@.

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

The "assorted bugs and vulns" like the RDMSR passthrough and the XSETBV
CPL check issues were handled by pd@, me and kettenis@ and they have all
been committed.

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

The direct map issue on Intel CPUs hinted at by Maxime was also fixed
by kettenis@, deraadt@ and millert@.

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

-Bryan.

Re: Could somebody please put unveil() in ftp(1)?

[Bryan Steele]

On Fri, May 29, 2020 at 11:41:43AM -0400, Christopher Turkel wrote:
> On Friday, May 29, 2020, Stuart Henderson  wrote:
> 
> > On 2020/05/29 08:30, Luke Small wrote:
> > > You mention a lot of files that need to be read, but a program like
> > pkg_add can make it the
> > > _pkgfetch (57) user which has no directory and I’m guessing not in
> > interactive mode. At the
> > > very least, in noninteractive mode you could unveil(“/“, “rx”); and
> > change the specified output
> > > file discover the name of the file that is to be downloaded and unveil
> > it as “cw” !
> > > --
> > > -Luke
> >
> > What problem are you trying to solve?
> >
> > If you are concerned about writes, use "ftp -o - $URL > somefile", it will
> > run without cpath/wpath, which is functionally similar to unveil("/", "rx")
> > (a bit stronger, because a program trying to write will be killed, rather
> > than just having a file access error).
> >
> > pkg_add(1) already uses "ftp -o -":
> >
> > # ktrace -di pkg_add -u moo
> > quirks-3.339 signed on 2020-05-27T20:05:28Z
> >
> > # kdump | grep promise=
> >  61644 ftp  STRU  promise="stdio rpath dns tty inet proc exec fattr"
> >  41938 signify  STRU  promise="stdio rpath wpath cpath tty"
> >  41938 signify  STRU  promise="stdio rpath"
> >  24897 ftp  STRU  promise="stdio rpath dns tty inet proc exec fattr"
> >  54324 signify  STRU  promise="stdio rpath wpath cpath tty"
> >  54324 signify  STRU  promise="stdio rpath"
> >   9188 ftp  STRU  promise="stdio rpath dns tty inet proc exec fattr"
> 
> 
> 
> If you need a diff written, I'm sure a developer would be willing in return
> for a donation.

No. That's not how any of this works.

Re: dynamic dns updates for clients in my home network?

[Bryan Stenson]

I've thought about this as welland would love to use native
OpenBSD tools for the job.

Just a design idea:

1. Use dhcpd(8) synchronization
(https://man.openbsd.org/dhcpd.8#SYNCHRONISATION) to send details of
dhcp leases to a DNS creator/listener.
2. The dns creator/listener creates/updates the zone file, and
3. Send a SIGHUP to nsd(8) (https://man.openbsd.org/nsd.8#SIGHUP) to
reload the zone details.

Issues to consider:
1. hostname collisions - what happens (what should happen?) when more
than one dhcp client has the same hostname?
2. what should ttl on these A records be?  probably something much
less than the dhcp lease duration (depending on how aggressive clients
are at renewing soon-to-be-expired leases).

I'm sure there are a thousand other things to consider here...thoughts/ideas?

On Sat, Apr 25, 2020 at 3:10 PM Raymond, David  wrote:
>
> I use dnsmasq (an openbsd package) on the gateway for my lab ethernet
> network and it works great with minimal configuration as a local DNS
> server.  At home I have a Synology wireless router which does the same
> as long as you tell it to make DNS reservations.  Your mileage may
> vary with cheaper routers.  One could in principle use dnsmasq even in
> this case, but I haven't tried it.
>
>
> Dave Raymond
>
> On 4/25/20, bofh  wrote:
> > Hi,
> > I searched through the archives and saw a couple of discussions about using
> > Dnsmasq from a long time ago.
> >
> > Is that the best way to let the stuff in my home to have valid dns entries
> > in my home network?
> >
> > How difficult is it to get the OpenBSD provided dhcpd and unbound to do
> > this?
> >
> > Thanks.
> >
>
>
> --
> David J. Raymond
> david.raym...@nmt.edu
> http://physics.nmt.edu/~raymond
>

Re: chattr on OpenBSD???

[Bryan Steele]

On Fri, Apr 17, 2020 at 09:11:15AM -0600, Raymond, David wrote:
> I noticed that chattr exists on OpenBSD.  The man page says it applies
> to Linux file systems (ext* etc).  Two questions:

No. You have e2fsprogs installed.

e2fsprogs-1.42.12p5:sysutils/e2fsprogs:/usr/local/man/man1/chattr.1


..bottom of chattr(1):

E2fsprogs version 1.42.12 August 2014CHATTR(1)

-Bryan.

Re: Openbsd supports pae?

[Bryan Steele]

Why should any of us exert more effort than you're willing to
put into writing an email?

Nikita Stepanov wrote:
> Why?

user-agent spoofing info; working around site "requirements"

[Bryan Stenson]

most of you already know this.

tldr - inferring system requirements from the "user-agent" http header
is useless/dangerous/silly, and your site/page stop (nothing new
here...not sure why certain sites trust the user-provided data).

This is not OpenBSD specific, but hopefully helpful for anyone wanting
their system to "just work" when accessing a site requiring a certain
operating system, or browser.

Here are some details for those who might be suffering from the same
stupid "required operating systems" limitation my bank imposes...

Given:
- the bank has a HTTP interface
- the bank "requires" a specific browser/version
- the bank "requires" a specific set of closed-source operating systems
- OpenBSD ships recent browsers (chromium, firefox, etc)

Problem:
When logging into said financial institution, the page declines to
work correctly because I don't have an operating system on their list.

Solution:
Spoof (add/modify) "user-agent" http header (via browser plugin, for
example), to include a common user-agent used by one of the
aforementioned "required operating systems".  This seems to work, for
me, at my bank:

Mozilla/5.0 (iPhone; CPU iPhone OS 9_2 like Mac OS X)
AppleWebKit/601.1 (KHTML, like Gecko) CriOS/47.0.2526.70 Mobile/13C71
Safari/601.1.46

Why this works:
Your browser sends a user-agent with browser/OS details in the
request.  This means you can modify those details before you send your
request.  Effectively, it's an unverified claim.  So take advantage of
it, and claim what you want/need. :)

Bryan

Re: upgrade i386 kernel to amd64

[Bryan Irvine]

backup your important files, format and re-install.

On Mon, Mar 2, 2020 at 5:16 PM Justin Muir  wrote:

> Hello all,
>
> Running GENERIC i386 kernel on on a 64-bit amd machine. Just wondering
> whether an upgrade amd64 is warranted. Any opinions?
>
> If so, just upgrade system? Re-compile kernel? Other options?
>
>
> tia!
>
> J
>

FDE: converting passphrase to usb key

[Bryan Stenson]

I currently have FDE installed using a passphrase, but would like to
update this to using a usb key.  Is this possible?

Or, should I just wipe/re-install?

Thanks.

Re: strange dmesg

[Bryan Steele]

On Sat, Feb 08, 2020 at 03:27:55PM -0500, Bryan Steele wrote:
> On Sat, Feb 08, 2020 at 11:28:41AM +0100, whistlez...@riseup.net wrote:
> > Hi,
> > I have some strange output from dmesg, what could be ?
> > At the follwoing link I've posted some screenshots:
> > https://postimg.cc/gallery/1o4wsaw74/
> > Thank you
> 
> I thought this was pretty well known, but you're looking at garbage
> from previous boots. Something scribbled over that memory.
> 
>"On some systems the message buffer can survive reboot and be retained
> (in the hope of exposing information from a crash)."
> 
> https://man.openbsd.org/dmesg
> 
> -Bryan.

The dmesg buffer is a circular buffer, where old data is at the start
and new data is appeneded to it untill it is full, then it wraps around
to the start.

There are some "magic number" sanity checks, but those are not entirely
foolpoof. It's all done as a best effort attempt to preverve logging from
across a reboot.

-Bryan.

Re: strange dmesg

[Bryan Steele]

On Sat, Feb 08, 2020 at 11:28:41AM +0100, whistlez...@riseup.net wrote:
> Hi,
> I have some strange output from dmesg, what could be ?
> At the follwoing link I've posted some screenshots:
> https://postimg.cc/gallery/1o4wsaw74/
> Thank you

I thought this was pretty well known, but you're looking at garbage
from previous boots. Something scribbled over that memory.

   "On some systems the message buffer can survive reboot and be retained
(in the hope of exposing information from a crash)."

https://man.openbsd.org/dmesg

-Bryan.

Re: SSIZE_MAX

[Bryan Steele]

> I am confused about SSIZE_MAX and read(2)/write(2).  The POSIX
> SSIZE_MAX is something like 2^15 -1.  This seems to be a real
> limitation when writing to a TCP/IP socket, as I learned from
> experience.  However, much larger reads and writes seem to be possible
> to files and UNIX sockets (pipes).  This makes me uneasy, given the
> warning in the man pages for read(2)/write(2).
>
> Any insight on this topic would be appreciated.
>
> -- 
> David J. Raymond
> david.raym...@nmt.edu
> http://physics.nmt.edu/~raymond

Not in any reasonably modern version of POSIX..

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html

{SSIZE_MAX}
Maximum value for an object of type ssize_t.

$ grep -R "SSIZE_MAX" /usr/include
./amd64/limits.h:#define SSIZE_MAX  LONG_MAX/* max value for
a ssize_t */

/usr/include/sys/limits.h:
#ifdef __LP64__
..
# define LONG_MAX   0x7fffL
...
#else
..
# define LONG_MAX   0x7fffL

-Bryan.

Re: syspatch says 6.5 patch #011 (libexpat) is malformed

[Bryan Steele]

On Mon, Sep 23, 2019 at 12:20:40AM -0400, Bryan Steele wrote:
> On Sun, Sep 22, 2019 at 12:42:25PM -0700, Jonathan Thornburg wrote:
> > I'm trying to use syspatch to update a firewall (a PC Engines Alix)
> > running 6.5-stable/i386, but syspatch dies with an error message saying
> > that the patch file contains inappropriate filenames:
> > 
> > # uname -a
> > OpenBSD sodium.bkis-orchard.net 6.5 GENERIC#3 i386
> > # cat /etc/installurl
> > https://cdn.openbsd.org/pub/OpenBSD
> > # ls -gFlk /bsd*
> > -rwx--  2 root  wheel  13518991 Sep 10 18:23 /bsd*
> > -rwx--  2 root  wheel  13518991 Sep 10 18:23 /bsd.booted*
> > -rw---  1 root  wheel   8843776 May 12 16:43 /bsd.rd
> > # syspatch -l
> > 001_rip6cksum
> > 002_srtp
> > 004_bgpd
> > 005_libssl
> > 006_tcpsack
> > 007_smtpd
> > 010_frag6ecn
> > # syspatch -c
> > 011_expat
> > # syspatch 
> > Get/Verify syspatch65-011_expat.tgz 100% |**|   546 KB00:00 
> >
> > Installing patch 011_expat
> 
> 
> > tar: Pattern matching characters used in file names
> > tar: Use --wildcards to enable pattern matching, or --no-wildcards to 
> > suppress this warning
> > tar: @usr/share/relink/kernel/GENERIC.MP/.*@@g: Not found in archive
> > tar: Exiting with failure status due to previous errors
> > # 
> 
> That message is not from OpenBSD's tar(1) implementation.

There is a very good reason why GNU utilities installed from ports and
packages are prefixed with a 'g', so as to not conflict with utilites
from the base system. You changed the system-wide tar to GNU tar,
so you should expect there to be fallout.

> > Is this a known issue with this patch?  Is there an alternate way
> > (besides updating from source) to track -stable ?

Re: syspatch says 6.5 patch #011 (libexpat) is malformed

[Bryan Steele]

On Sun, Sep 22, 2019 at 12:42:25PM -0700, Jonathan Thornburg wrote:
> I'm trying to use syspatch to update a firewall (a PC Engines Alix)
> running 6.5-stable/i386, but syspatch dies with an error message saying
> that the patch file contains inappropriate filenames:
> 
> # uname -a
> OpenBSD sodium.bkis-orchard.net 6.5 GENERIC#3 i386
> # cat /etc/installurl
> https://cdn.openbsd.org/pub/OpenBSD
> # ls -gFlk /bsd*
> -rwx--  2 root  wheel  13518991 Sep 10 18:23 /bsd*
> -rwx--  2 root  wheel  13518991 Sep 10 18:23 /bsd.booted*
> -rw---  1 root  wheel   8843776 May 12 16:43 /bsd.rd
> # syspatch -l
> 001_rip6cksum
> 002_srtp
> 004_bgpd
> 005_libssl
> 006_tcpsack
> 007_smtpd
> 010_frag6ecn
> # syspatch -c
> 011_expat
> # syspatch 
> Get/Verify syspatch65-011_expat.tgz 100% |**|   546 KB00:00   
>  
> Installing patch 011_expat


> tar: Pattern matching characters used in file names
> tar: Use --wildcards to enable pattern matching, or --no-wildcards to 
> suppress this warning
> tar: @usr/share/relink/kernel/GENERIC.MP/.*@@g: Not found in archive
> tar: Exiting with failure status due to previous errors
> # 

That message is not from OpenBSD's tar(1) implementation.


> Is this a known issue with this patch?  Is there an alternate way
> (besides updating from source) to track -stable ?

Re: recent troubles with iwn(4)

[Bryan Stenson]

sorry about that...here's the most recent one:

Sep 11 06:31:13 e530c /bsd: iwn0: sending probe_req to
80:2a:a8:57:5e:17 on channel 6 mode 11n
Sep 11 06:31:15 e530c ntpd[87584]: DNS lookup tempfail
Sep 11 06:31:16 e530c dhclient[9122]: iwn0: writev(DHCPREQUEST): No
buffer space available
Sep 11 06:31:18 e530c /bsd: iwn0: RUN -> SCAN
Sep 11 06:31:18 e530c /bsd: iwn0: end active scan
Sep 11 06:31:18 e530c /bsd: iwn0: - 00:0d:67:7d:a9:431  +172 54M
ess   no!  rsn! "CableWiFi"!
Sep 11 06:31:18 e530c /bsd: iwn0: - 08:86:3b:b6:2f:801  +182 54M
ess  privacy   rsn  "belkin.f80"!
...

On Wed, Sep 11, 2019 at 7:53 AM Stefan Sperling  wrote:
>
> On Wed, Sep 11, 2019 at 12:16:06AM -0700, Bryan Stenson wrote:
> > doh...I don't know why I didn't think of that...
> >
> > Good news, with 'ifconfig iwn0 debug' set, once the strange behavior
> > starts, I see LOTS of repeated messages, the pattern happens about
> > once every 4 seconds, and dumps the following into /var/log/messages:
> >
> > ...
> > # continuous spamming of /var/log/messages from after the network has
> > been in the troubled/failed state for a while
>
> You snipped the exciting part.
>
> I need to know why it decides to do a transition of the form:
>
> RUN -> something
>
> This should be somewhere at the top of this stream of output.

Re: recent troubles with iwn(4)

[Bryan Stenson]

:6f:eb:24:78   11  +201 54M
ess  privacy   rsn  "Cleveland-Bales Casa"!
Sep 10 09:00:11 e530c /bsd: iwn0: - 90:c7:92:4f:28:801  +175 54M
ess  privacy   rsn  "HOME-2882"!
Sep 10 09:00:11 e530c /bsd: iwn0: - 92:95:51:c7:c9:db   11  +172 54M
ess  privacy   rsn! ""!
Sep 10 09:00:11 e530c /bsd: iwn0: - 96:0f:6f:e7:84:181  +191 54M
ess   no!  rsn! "xfinitywifi"!
Sep 10 09:00:11 e530c /bsd: iwn0: - 96:c7:92:4f:28:801  +172 54M
ess   no!  rsn! "xfinitywifi"!
Sep 10 09:00:11 e530c /bsd: iwn0: - 9a:0f:6f:e7:84:181  +192 54M
ess  privacy   rsn  ""!
Sep 10 09:00:11 e530c /bsd: iwn0: - 9a:0f:6f:eb:24:78   11  +200 54M
ess  privacy   rsn  ""!
Sep 10 09:00:11 e530c /bsd: iwn0: - 9c:3d:cf:43:74:8a8  +172 54M
ess  privacy   rsn  "NETGEAR18"!
Sep 10 09:00:11 e530c /bsd: iwn0: - a2:0f:6f:e7:84:181  +192 54M
ess  privacy   rsn! ""!
Sep 10 09:00:11 e530c /bsd: iwn0: - a2:0f:6f:eb:24:78   11  +199 54M
ess  privacy   rsn! ""!
Sep 10 09:00:11 e530c /bsd: iwn0: - a4:56:cc:cd:e6:891  +174 54M
ess  privacy   rsn  "No ID"!
Sep 10 09:00:11 e530c /bsd: iwn0: - a4:56:cc:cd:e6:8c1  +172 54M
ess  privacy   rsn  ""!
Sep 10 09:00:11 e530c /bsd: iwn0: - a4:56:cc:cd:e6:8d1  +173 54M
ess  privacy   rsn! "OutOfService"!
Sep 10 09:00:11 e530c /bsd: iwn0: - a4:56:cc:cd:e6:8e1  +174 54M
ess  privacy   rsn! ""!
Sep 10 09:00:11 e530c /bsd: iwn0: - aa:93:5b:0c:9b:3d6  +184 54M
ess   no!  rsn! "xfinitywifi"!
Sep 10 09:00:11 e530c /bsd: iwn0: - ae:93:5b:0c:9b:3d6  +193 54M
ess  privacy   rsn  ""!
Sep 10 09:00:11 e530c /bsd: iwn0: - b0:39:56:23:b4:6b8  +172 54M
ess  privacy   rsn  "Meul"!
Sep 10 09:00:11 e530c /bsd: iwn0: - b0:93:5b:0c:9b:3d6  +191 54M
ess  privacy   rsn  "2wernergals"!
Sep 10 09:00:11 e530c /bsd: iwn0: - b2:93:5b:0c:9b:3d6  +191 54M
ess  privacy   rsn! "OutOfService"!
Sep 10 09:00:11 e530c /bsd: iwn0: - b6:93:5b:0c:9b:3d6  +190 54M
ess  privacy   rsn! ""!
Sep 10 09:00:11 e530c /bsd: iwn0: - cc:40:d0:17:22:c31  +182 54M
ess  privacy   rsn  "Cleveland-Bales Casa 5_2GEXT"!
Sep 10 09:00:11 e530c /bsd: iwn0: - d8:97:ba:be:19:706  +170 54M
ess  privacy   rsn! "CUSPNet_2.4"!
Sep 10 09:00:11 e530c /bsd: iwn0: - e8:37:7a:be:c4:a71  +173 54M
ess  privacy   rsn  "CenturyLink3718"!
Sep 10 09:00:11 e530c /bsd: iwn0: SCAN -> AUTH
Sep 10 09:00:11 e530c /bsd: iwn0: sending auth to 80:2a:a8:57:5e:17 on
channel 6 mode 11g
Sep 10 09:00:15 e530c /bsd: iwn0: AUTH -> SCAN
Sep 10 09:00:16 e530c /bsd: iwn0: end active scan
...

This scan repeats about once every 4 seconds.

A few other data points (forgive me if this is obvious...I mostly
wanted to share my general thoughts on what I've look into):
* I wondered if this was triggered by dhcp lease renewal (iwn0 uses
IPv4 dhcp only, bad packet or something), but I have observed the iwn0
driver in the "troubled" state well before my current lease expires.
* timing seems odd : once the iwn0 stops working, it takes a while for
the "scan" log entries (above) to appear in /var/log/messages
(gathering specific data on this now, but it seems to be at least 10s
of minutes).
* I have verified there are no states in the firewall, other than
those marked "SINGLE:NO_TRAFFIC" from my machine attempting to query
DNS.
* During the repeated scans above, `tcpdump` reports no UDP traffic
for this iwn0.

tl;dr -
1.) I still don't know what's triggering this.
2.) When it's triggered, it takes a while to report anything in
/var/log/messages
3.) Once it does, iwn seems to be in a 4-5 second loop, continuously
scanning all APs.
4.) I'm able to reset the driver via "doas ifconfig iwn0 down; doas sh
/etc/netstart iwn0" and it all works again...for a while (see #1).

Thank you for reading this far.  Any other pointers/suggestions?  So
many opportunities to learn. :)

Bryan


On Mon, Sep 9, 2019 at 9:23 AM Stefan Sperling  wrote:
>
> On Sun, Sep 08, 2019 at 08:31:55PM +, Bryan Stenson wrote:
> > Hi all -
> >
> > I'm writing to "misc" rather than "bugs" as I'm not yet sure this is a
> > bug.  I'm hoping to help triage this with assistance from this list.
> >
> > I'm running -CURRENT and the iwn(4) driver for my wireless card.  Over
> > the past year, this has been working great, but recently (within the
> > last month or so), I've had issues where the NIC just stops working
> > after a few hours of usage.  I don't have a solid steps for
> > reproduction.
> >
> > I realize "stops working" is not a very accurate account here...but
> > I'm confused on how to get more descriptive information of the
> > problem.  When it stops, "ifconfig" shows iwn0 with an

recent troubles with iwn(4)

[Bryan Stenson]

Hi all -

I'm writing to "misc" rather than "bugs" as I'm not yet sure this is a
bug.  I'm hoping to help triage this with assistance from this list.

I'm running -CURRENT and the iwn(4) driver for my wireless card.  Over
the past year, this has been working great, but recently (within the
last month or so), I've had issues where the NIC just stops working
after a few hours of usage.  I don't have a solid steps for
reproduction.

I realize "stops working" is not a very accurate account here...but
I'm confused on how to get more descriptive information of the
problem.  When it stops, "ifconfig" shows iwn0 with an IP address, but
I'm unable to ping.  Additionally, I'm not seeing any
warnings/messages in "dmesg" about the device...so I'm confused.

A simple "ifconfig iwn0 down; sh /etc/netstart iwn0" seems to fix the
problem, but I haven't had to do that in the past...it just feels like
a recent change (iwn(4) work?) has put me in this state.

I'm really wanting to help here.  How can I run the iwn(4) in debug
mode, or increase logging verbosity?  And/or, should I try to capture
packets via tcpdump?  And/or, can I run an older bsd.mp (without
having to downgrade packages to older versions) in order to try and
"bisect" where the problem may have been introduced?

The following are my kernel and wireless details:

# uname -a
OpenBSD e530c.siliconvortex.com 6.6 GENERIC.MP#289 amd64

# pcidump -v
...
 3:0:0: Intel Centrino Wireless-N 2230
0x: Vendor ID: 8086, Product ID: 0888
0x0004: Command: 0006, Status: 0010
0x0008: Class: 02 Network, Subclass: 80 Miscellaneous,
Interface: 00, Revision: c4
0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
Cache Line Size: 10
0x0010: BAR mem 64bit addr: 0xf2d0/0x2000
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 8086 Product ID: 4262
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00
0x00c8: Capability 0x01: Power Management
State: D0
0x00d0: Capability 0x05: Message Signalled Interrupts (MSI)
Enabled: yes
0x00e0: Capability 0x10: PCI Express
Link Speed: 2.5 / 2.5 GT/s, Link Width: x1 / x1
0x0100: Enhanced Capability 0x01: Advanced Error Reporting
0x0140: Enhanced Capability 0x03: Device Serial Number
Serial Number: 6036ddffffed4a81

With humility, an open mind, and eagerness to learn/help:

Bryan

Re: Bluetooth support status

[Bryan Wright]

> On Aug 7, 2019, at 10:06, 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.
> 

I’m sorry, Theo.  I’ve read some, but I’m sure I haven’t read all the history.  
I didn’t mean anything by my question, but perhaps I should have done more 
reading before asking.  Apologies.

Re: Bluetooth support status

[Bryan Wright]

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? 

Re: ampd(8) -Z option

[Bryan Wright]

   I’ve also wrestled with this same issue and am eager to hear the responses.
   I did have much better results after adding -t 60  to my flags.  I suspect 
my not exactly new x220’s battery was going from my given percentage to zero in 
less time than the default polling time of 10mins.   I’m not sure mine is 
completely sorted out. I do find a dead laptop from time to time.
~Bryan

Re: hardware assisted ethernet filtering

[Bryan Steele]

On Wed, Jul 31, 2019 at 11:48:24PM +0100, Tom Smyth wrote:
> Hi all,
> I was just wondering is there an ethtool equivalent in OpenBSD
> in particular Im interested in trying to harness some of the features
> in the xl710 and more advanced intel Ethernet chipsets where they
> allow a (limited) number of filter rules to be applied to a given network
> interface,
> example to drop high packet rate udp floods / amplification attacks
> #drop NTP responses (good and bad) inbound on interface  enp134s0f0
> ethtool --config-ntuple  enp134s0f0 flow-type udp4 src-port 123 action -1
> #drop DNS responses (good and bad) inbound on interface  enp134s0f0
> ethtool --config-ntuple  enp134s0f0 flow-type udp4 src-port 53 action -1
> 

Not hardware filter features, no. But you may be interested in the
bpf(4) "filter drop" feature extended recently by dlg@, and added to
tcpdump(8), it can be useful in cases where pf(4) cannot.

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

https://man.openbsd.org/tcpdump#B

> the benefit of using the NICs ability to filter would be to reduce the
> effects
> of a high packet rate attack against the OpenBSD router
> what way would the openBSD devs think this should be done.
> extending ifconfig ?
> or a separate tool ?
> 
> It would be nice that the tools commands would be more like pf and less
> like eth tools (cause the syntax of ethtools sucks a little here)
> some downside risks of the  hardware filtering offload is that is not
> immediately obvious  to someone analysing the firewall rules that there is
> a hardware filter in place... perhaps this could be mitigated by some sort
> of
> 
> so it might be an idea to prepend a line comment to /etc.pf.conf to give
> the sysadmin a hint that there is a hardware filter in play before the
> firewall gets
> to see the packets...
> 
> any interest ? ideas? alternative view points on it ...
> Thanks for your time
> 
> Tom Smyth.
> 

Re: vmd eating lots of memory

[Bryan Linton]

On 2019-07-25 13:01:28, Mike Larkin  wrote:
> On Thu, Jul 25, 2019 at 09:54:22PM +0200, Paul de Weerd wrote:
> > A little more follow-up on this vmd-memory-leak issue.
> > 
> > Comparing the two VMs I have running, I started to stress parts where
> > these two hosts differ.  The testvm hardly does any traffic, while the
> > undeadly vm sees quite a few visitors on a daily basis, so networking
> > may be part of the leak.
> > 
> > Running tcpbench against this machine (averaging at ~250Mbit/s)
> > results in vmd growing by about 80MB to 100MB per minute.  Running
> > tcpbench against the testvm has similar results.
> > 
> > The undeadly VM also has a second disk configured (on slower storage),
> > but putting load on that didn't significantly change the memory
> > consumption (above the 'expected' growth that I've been seeing).
> > 
> > The growth during daily(8) runs still confuses me, as that doesn't do
> > anything network-related...
> > 
> > Paul
> > 
> 
> I'll try to look for leaks in that area then. Thanks for the report.
> 
> -ml
> 

To Paul, is it related to disk activity on the VM?  I.e. Does
doing lots of I/O on the system cause memory usage to increase?
Can you test it with a snapshot/kernel dated May 7th or earlier?

I CCed both of you into a bug report I just submitted to bugs@
because I thought it may possibly be related.

https://marc.info/?l=openbsd-bugs=156412299418191=2

In brief, I'm seeing large amounts of memory being consumed
followed by a system hang when files are copied to a vnd(4)
device.

I don't see it with regular disk I/O, only with vnds.

If the VMs are using/accessing memory in a similar way to the
method that vnd(4) does, it might explain why the daily(8) runs
are causing the memory usage to increase.

If this is an unrelated issue, then I apologize for the noise.  I
figured it better to CC both of you in so you could evaluate it on
your own rather than for me to do nothing.

-- 
Bryan

Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link

[Bryan Wright]

As just a “user” who has been trying to learn the OpenBSD way (which does take 
some effort), I’m very thankful to you and all the devs.  

It’s comedically sad to see the transition from “installing via NOT RECOMMENDED 
WAY” to “I’m your user - FIX IT.”

Sorry you are catching needless abuse, and thank you for doing so.

Bryan

Re: Lenovo V330-14 touchpad is not working at all

[Bryan Steele]

On Thu, Jun 13, 2019 at 11:38:24PM +0200, Tristan wrote:
> 
> 
> > On 13 Jun 2019, at 22:34, Tristan  wrote:
> > 
> > 
> > 
> >> On 13 Jun 2019, at 22:25, Bryan Steele  wrote:
> >> 
> >> On Thu, Jun 13, 2019 at 08:39:48PM +0200, Tristan wrote:
> >>> Hi there,
> >>> 
> >>> I got a new lenovo v330-14 it has an AMD Ryzen 5 2500U and Radeon RX Vega 
> >>> 8
> >>> and so was looking forward to using OpenBSD on this one. I'm currently 
> >>> running a
> >>> snapshot I grabbed today. To get the screen working I had to set 
> >>> machdep.allowaperture=2
> >>> unfortunately, but it works now and great as well. Video seems smooth. 
> >>> Audio works as well
> >> 
> >> You should avoid doing that -- see recent mailing lists post from Mark
> >> Kettenis.
> >> 
> >> https://marc.info/?l=openbsd-misc=156029398905090=2
> >> 
> >> For Vega graphics you need to recompile your kernel with the amdgpu
> >> driver lines uncommented, alternatively reinstall in UEFI mode to get the
> >> efifb(4) driver instead. This is probably better as amdgpu support is
> >> still a WIP.
> >> 
> > 
> > OK yes, I remember seeing something about it. Will give that a try. Much 
> > better then opening up :)
> > 
> > 
> >>> but the touchpad is not working at all. Wireless card does not work 
> >>> either, but using the 
> >>> ethernet port on it for now until I get an USB dongle for it.
> >>> 
> >>> wsconsctl | grep mouse gives me only:
> >>> mouse.type=ps2
> >>> 
> >>> In the dmesg output I can see only:
> >>> wsmouse0 at pms0 mux 0
> >> 
> >> Indeed, there's no pms(4) compatible touchpad on your machine. :-(
> >> 
> >>> "AMDI0010" at acpi0 not configured
> >>> "SYNA2B3F" at acpi0 not configured
> >> 
> >> And instead requires a driver to attach to the I2C HID controler. AMD's
> >> implementation seems to be somewhat compatible with dwiic(4) written by
> >> jcs@, however interrupts are not working-- hangs the machine. It does
> >> work if polling mode is forced.
> >> 
> >> This diff made the touchscreen and touchpad work be detected and mostly
> >> work on my Huawei MateBook D (AMD), however with the touchpad it seems
> >> to be break Tap-To-Drag. I don't know if this is a side effect of the
> >> drivers polling, unlike the pms(4) support-- which is working on that
> >> machine. We have no way to prefer one driver over other, which is why
> >> I haven't sent this diff yet.
> >> 
> >> Let me know if it works at all for you.
> > 
> > Much appreciated, will try this and report the outcome
> 
> Applying this patch gives me the following:
> 
> Hmm...  Looks like a unified diff to me...
> The text leading up to this was:
> --
> |Index: dwiic_acpi.c
> |===
> |RCS file: /cvs/src/sys/dev/acpi/dwiic_acpi.c,v
> |retrieving revision 1.8
> |diff -u -p -u -r1.8 dwiic_acpi.c
> |--- sys/dev/acpi/dwiic_acpi.c1 Jul 2018 11:37:11 -   1.8
> |+++ sys/dev/acpi/dwiic_acpi.c5 Jun 2019 00:25:29 -
> --
> Patching file dwiic_acpi.c using Plan A...
> patch:  malformed patch at line 9: };

Your mail client may have mangled it-- can you try grabbing it
from marc.info? If not, I'll send a direct link.

https://marc.info/?l=openbsd-misc=156045760827816=raw

Re: Lenovo V330-14 touchpad is not working at all

[Bryan Steele]

On Thu, Jun 13, 2019 at 08:39:48PM +0200, Tristan wrote:
> Hi there,
> 
> I got a new lenovo v330-14 it has an AMD Ryzen 5 2500U and Radeon RX Vega 8
> and so was looking forward to using OpenBSD on this one. I'm currently 
> running a
> snapshot I grabbed today. To get the screen working I had to set 
> machdep.allowaperture=2
> unfortunately, but it works now and great as well. Video seems smooth. Audio 
> works as well

You should avoid doing that -- see recent mailing lists post from Mark
Kettenis.

https://marc.info/?l=openbsd-misc=156029398905090=2

For Vega graphics you need to recompile your kernel with the amdgpu
driver lines uncommented, alternatively reinstall in UEFI mode to get the
efifb(4) driver instead. This is probably better as amdgpu support is
still a WIP.

> but the touchpad is not working at all. Wireless card does not work either, 
> but using the 
> ethernet port on it for now until I get an USB dongle for it.
> 
> wsconsctl | grep mouse gives me only:
> mouse.type=ps2
> 
> In the dmesg output I can see only:
> wsmouse0 at pms0 mux 0

Indeed, there's no pms(4) compatible touchpad on your machine. :-(

> "AMDI0010" at acpi0 not configured
> "SYNA2B3F" at acpi0 not configured

And instead requires a driver to attach to the I2C HID controler. AMD's
implementation seems to be somewhat compatible with dwiic(4) written by
jcs@, however interrupts are not working-- hangs the machine. It does
work if polling mode is forced.

This diff made the touchscreen and touchpad work be detected and mostly
work on my Huawei MateBook D (AMD), however with the touchpad it seems
to be break Tap-To-Drag. I don't know if this is a side effect of the
drivers polling, unlike the pms(4) support-- which is working on that
machine. We have no way to prefer one driver over other, which is why
I haven't sent this diff yet.

Let me know if it works at all for you.

-Bryan.

Index: dwiic_acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/dwiic_acpi.c,v
retrieving revision 1.8
diff -u -p -u -r1.8 dwiic_acpi.c
--- sys/dev/acpi/dwiic_acpi.c   1 Jul 2018 11:37:11 -   1.8
+++ sys/dev/acpi/dwiic_acpi.c   5 Jun 2019 00:25:29 -
@@ -66,6 +66,7 @@ struct cfattach dwiic_acpi_ca = {
 };
 
 const char *dwiic_hids[] = {
+   "AMDI0010",
"INT33C2",
"INT33C3",
"INT3432",
@@ -163,8 +164,11 @@ dwiic_acpi_attach(struct device *parent,
dwiic_enable(sc, 0);
dwiic_read(sc, DW_IC_CLR_INTR);
 
-   /* try to register interrupt with apic, but not fatal without it */
-   if (crs.irq_int > 0) {
+   /* XXX: AMD i2c controllers have a problem with interrupts enabled */
+   if (strcmp(sc->sc_hid, "AMDI0010") == 0)
+   sc->sc_poll = 1;
+   else if (crs.irq_int > 0) {
+   /* try to register interrupt with apic, not fatal without it */
printf(" irq %d", crs.irq_int);
 
sc->sc_ih = acpi_intr_establish(crs.irq_int, crs.irq_flags,
@@ -294,6 +298,9 @@ dwiic_acpi_bus_scan(struct device *iic, 
struct dwiic_softc *sc = (struct dwiic_softc *)aux;
 
sc->sc_iic = iic;
+   /* XXX: Workaround broken interrupts on AMD for i2c slave devices. */
+   if (strcmp(sc->sc_hid, "AMDI0010") == 0)
+   sc->sc_poll_ihidev = 1;
aml_find_node(sc->sc_devnode, "_HID", dwiic_acpi_found_hid, sc);
 }
 

Re: mounting an existing softraid/crypto partition for install/update

[Bryan Stenson]

YESS!!  Thank you qwerjkl...

I can confirm, "bioctl -c C -l ... softraid0" seems to have picked up the
existing partition...and after a "cd /dev && sh MAKEDEV sd2", the installer
was picked up the device (sd2), and I was able to get back to a working
system.

Thanks again!

On Mon, Jun 3, 2019 at 7:30 PM Benny  wrote:

> I have done that two days ago. When you use bioctl -c ... -l ... softraid0
> on an existing raid configuration, it will map the raid volume to another
> sd device. You will be prompted for a password if your raid level is
> crypto. This will _not_ create another raid or overwrite your data, unless
> you typed something wrong. Don't forget to MAKEDEV sd1 for the new sd.
>
> qwerjkl
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, June 3, 2019 7:17 PM, Bryan Stenson 
> wrote:
>
> > Hi all -
> >
> > I'm running -CURRENT on a SSD with FDE encryption using softraid/crypto
> > with a passphrase entered via the keyboard at boot. It worked great.
> > Then, I upgraded to a build that had a broken bootloader (reported to be
> > fixed now: "Re: amd64 snapshot very broken (Jun 1 02:24:13)"). Per that
> > thread, I'm trying to boot from temp boot media to update to the fixed
> > image.
> >
> > I've tried booting both snapshots/amd64/install65.fs and
> > snapshots/amd64/miniroot65.fs, and while it appears the bootloader
> > recognizes my softraid crypto device, it's clearly not mounting the
> crypto
> > device (I'm not prompted for a passphrase), and by the time I get to the
> > install script, it shows:
> >
> > Available disks are: .
> > Which disk is the root disk? ('?' for details)
> >
> > Asking for details, both my SSD (sd0) and temp boot media (sd1) are
> shown,
> > but I'm not able to see the encrypted device.
> >
> > I've dropped to a shell, and created the device (it wasn't there) via "cd
> > /dev && sh MAKEDEV sd0", and can see my RAID partition via "disklabel
> sd0".
> >
> > But, now I'm stuck/confused...I'm trying to figure it out by following:
> > https://www.openbsd.org/faq/faq14.html#softraidFDE
> >
> > Do I re-create the softraid/crypto with something like "bioctl -c C sd0a
> > softraid0"? Or, will this will wipe out the existing data and give me a
> > fresh new partition to install to?
> >
> > How can I mount the existing crypto volume for use by the installer?
> > (Also, am I asking the right questions here?)
> >
> > Any suggestions/clarifications would be greatly appreciated. Thank you
> for
> > your time.
> >
> > Bryan
>
>
>

mounting an existing softraid/crypto partition for install/update

[Bryan Stenson]

Hi all -

I'm running -CURRENT on a SSD with FDE encryption using softraid/crypto
with a passphrase entered via the keyboard at boot.  It worked great.
Then, I upgraded to a build that had a broken bootloader (reported to be
fixed now: "Re: amd64 snapshot very broken (Jun 1 02:24:13)").  Per that
thread, I'm trying to boot from temp boot media to update to the fixed
image.

I've tried booting both snapshots/amd64/install65.fs and
snapshots/amd64/miniroot65.fs, and while it appears the bootloader
recognizes my softraid crypto device, it's clearly not mounting the crypto
device (I'm not prompted for a passphrase), and by the time I get to the
install script, it shows:

Available disks are: .
Which disk is the root disk? ('?' for details)

Asking for details, both my SSD (sd0) and temp boot media (sd1) are shown,
but I'm not able to see the encrypted device.

I've dropped to a shell, and created the device (it wasn't there) via "cd
/dev && sh MAKEDEV sd0", and can see my RAID partition via "disklabel sd0".

But, now I'm stuck/confused...I'm trying to figure it out by following:
https://www.openbsd.org/faq/faq14.html#softraidFDE

Do I re-create the softraid/crypto with something like "bioctl -c C sd0a
softraid0"?  Or, will this will wipe out the existing data and give me a
fresh new partition to install to?

How can I mount the existing crypto volume for use by the installer?
(Also, am I asking the right questions here?)

Any suggestions/clarifications would be greatly appreciated.  Thank you for
your time.

Bryan

Re: 6.5 : console font : no spleen?

[Bryan Steele]

On Mon, May 13, 2019 at 09:38:43AM +, Mayuresh Kathe wrote:
> i thought "spleen" was made the new default console
> font under 6.5+, it doesn't look like it's there on
> my fresh install under amd64?

It does if you have an EFI install (w/ efifb(4)), or have a graphics
device supported by inteldrm(4) or radeondrm(4).

(But you didn't send a dmesg, so ...)

Re: ws

[Bryan Steele]

On Sun, Apr 14, 2019 at 11:31:33AM +0900, Jerome Pinot wrote:
> Hi,
> 
> I'm curious to know what is the origin of the "w(s)" prefix we have
> on some OpenBSD specific places, like:
> - wscons
> -wsmoused
> - wskbd
> - wsrc
> - wobj
> etc
> 
> It seems to be a quite old practice and common with other BSDs.
> Anybody has the history for this?
> 
> Thanks!
> 
> -- 
> Jerome Pinot

'workstation console' at least sounds plausible.

https://www.netbsd.org/docs/guide/en/chap-cons.html

Re: Black screen when starting Xorg with Dell XPS 13 9350

[Bryan Avery]

(--) framebuffer bpp 32
[13.410] (==) intel(0): RGB weight 888
[13.410] (==) intel(0): Default visual is TrueColor
[13.411] (**) intel(0): Option "TearFree" "true"

Reinstating machdep.allowaperature=1 to /etc/sysctl.conf and rebooting
(with the above ~/.xsession) yielded the same black screen and
Xorg.0.log as originally. The backlight is on, the screen is just
black. I tried toggling the function keys for keyboard brightness,
backlight, and internal/external monitor but these didn't produce any
change.

On Sat, Mar 2, 2019 at 4:01 PM Fred Crowson  wrote:
>
> do you have an .xsession file in your /home/ directory?
>
> machdep.allowaperture=1 should not be needed for xenodm to work...
>
> I once had a similar issue where the X server would start with a black
> screen until I toggled either the keyboard brightness setting or the
> keyboard shortcut for internal / external monitor.
>
> hth
>
> Fred
>
> On Sat, 2 Mar 2019 at 23:13, Bryan Avery  wrote:
> >
> > I have been unable to start X with a new install of OpenBSD on my
> > laptop. I am a beginner with OpenBSD. This is a Skylake laptop with
> > Intel 520 QHD graphics. During boot, the console shows with underscan,
> > then the resolution increases (but is still less than native), then
> > goes black upon starting Xorg. If I disable xenodm, the console is
> > visible and I am able to login on the laptop. The first time I enabled
> > and started xenodm, the screen went black. I was able to connect
> > through SSH and retrieve the Xorg.0.log which told me to add
> > machdep.allowaperture=1 to /etc/sysctl.conf which I did, but the
> > screen went black again after I rebooted. I am not able to understand
> > what went wrong from looking at the dmesg and Xorg.0.log. I have
> > tested this with and without a config in /etc/X11/xorg.conf.d and get
> > the same result. I am currently using /etc/X11/xorg.conf.d/intel.conf
> > with contents:
> >
> > Section "Device"
> >   Identifier "drm"
> >   Driver "intel"
> >   Option "TearFree" "true"
> > EndSection
> >
> > dmesg:
> >
> > OpenBSD 6.4 (GENERIC.MP) #7: Thu Feb 28 18:56:25 CET 2019
> > 
> > r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 8433565696 (8042MB)
> > avail mem = 8168701952 (7790MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe (94 entries)
> > bios0: vendor Dell Inc. version "1.9.0" date 08/31/2018
> > bios0: Dell Inc. XPS 13 9350
> > acpi0 at bios0: rev 2
> > acpi0: sleep states S0 S3 S4 S5
> > acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT
> > SSDT DBGP DBG2 SSDT BOOT SSDT UEFI SSDT MSDM SSDT SLIC TCPA DMAR BGRT
> > ASF!
> > acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4)
> > PEG2(S4) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4)
> > PXSX(S4) RP12(S4) PXSX(S4) RP13(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) Core(TM) i5-6200U CPU @ 2.30GHz, 2295.40 MHz, 06-4e-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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,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 23MHz
> > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> > cpu1 at mainbus0: apid 2 (application processor)
> > cpu1: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2294.66 MHz, 06-4e-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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> > cpu1: 256KB 64b/line 8-way L2

Black screen when starting Xorg with Dell XPS 13 9350

[Bryan Avery]

I have been unable to start X with a new install of OpenBSD on my
laptop. I am a beginner with OpenBSD. This is a Skylake laptop with
Intel 520 QHD graphics. During boot, the console shows with underscan,
then the resolution increases (but is still less than native), then
goes black upon starting Xorg. If I disable xenodm, the console is
visible and I am able to login on the laptop. The first time I enabled
and started xenodm, the screen went black. I was able to connect
through SSH and retrieve the Xorg.0.log which told me to add
machdep.allowaperture=1 to /etc/sysctl.conf which I did, but the
screen went black again after I rebooted. I am not able to understand
what went wrong from looking at the dmesg and Xorg.0.log. I have
tested this with and without a config in /etc/X11/xorg.conf.d and get
the same result. I am currently using /etc/X11/xorg.conf.d/intel.conf
with contents:

Section "Device"
  Identifier "drm"
  Driver "intel"
  Option "TearFree" "true"
EndSection

dmesg:

OpenBSD 6.4 (GENERIC.MP) #7: Thu Feb 28 18:56:25 CET 2019

r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8433565696 (8042MB)
avail mem = 8168701952 (7790MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe (94 entries)
bios0: vendor Dell Inc. version "1.9.0" date 08/31/2018
bios0: Dell Inc. XPS 13 9350
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT
SSDT DBGP DBG2 SSDT BOOT SSDT UEFI SSDT MSDM SSDT SLIC TCPA DMAR BGRT
ASF!
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4)
PEG2(S4) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4)
PXSX(S4) RP12(S4) PXSX(S4) RP13(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) Core(TM) i5-6200U CPU @ 2.30GHz, 2295.40 MHz, 06-4e-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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,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 23MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2294.66 MHz, 06-4e-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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,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 1 (application processor)
cpu2: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2294.65 MHz, 06-4e-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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2294.65 MHz, 06-4e-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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 2399 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus 

Re: Purpose of primary and secondary user groups

[Bryan Harris]

On 12/30/2018 12:33 AM, Philip Guenther wrote:

On Sat, Dec 29, 2018 at 11:29 AM Ipsen S Ripsbusker <
ip...@ripsbusker.no.eu.org> wrote:


Aside from compatibility, what is the purpose of primary groups,
compared to secondary groups?

Said otherwise, why do we have both primary and secondary groups
rather than only secondary groups?

Yet another phrasing: Why do I need to set a primary group?


Secondary groups can only be set, all at once, when running as root (e.g.,
login, sshd), while the primary group can be altered by setgid binaries and
then switched among using set*gid(2).

For filesystem objects like files and directories, the BSD behavior is for
the object to get its group from the directory in which it was created,
ignoring the groups of the process that created it.  On more SysV-like
systems the default is to take the primary group of the process that
created it.  However, for objects that exist in the kernel but not the
filesystem such as pipes, sockets, and SysV shared memory segments,
semaphores, and message queues, the common behavior is to take the primary
group of the process that created it.  This  doesn't have much effect other
than fstat() for pipes and sockets, but for SysV stuff it affects what
operations processes can perform.


Philip Guenther



Is there also a difference when creating a file in a folder with set GID 
bit on that folder and owned by secondary group? I think in normal 
behavior, if folder allows a user to create a file (sec. group w/ 770 
perm.) then the new file group will not take the group of the folder but 
will take the group of the user's primary group. But if you have set GID 
bit then the new file will take the group of the folder it's in (which 
will be one of the user's secondary groups).



I thought in OpenBSD there is also a flag to mount the filesystem to 
always do this regardless of set GID but I can't remember. I don't see 
it in the man page so maybe with all of this I'm really thinking of 
Linux but I can't remember.



V/r,

Bryan

Re: ubnt unfi stable from ports doesn??t start with rcctl but as root

[Bryan Vyhmeister]

On Tue, Jan 08, 2019 at 03:27:39PM +0100, Thomas Huber wrote:
> just upgrade the Unifi Controller net/unifi/stable (version 5.8.30) from
> ports.
> The controller service doesn??t start wit rcctl(8) but works fine when
> running as root.
> My guess is that _unifi is not allowed to start monogd but don??t have a
> clue how to fix this...
> Does it matter if databases/mongo is install from ports or pkg?
> I installed all dependecies manually with pkg_add(1)
> 
> Any idea where to look?

On my UniFi box (which is running -current and unifi-5.9.32), I also enabled
mongod to start at boot.

rcctl enable mongod
rcctl enable unifi

It has been running fine for me for years that way.

Bryan

OpenIKED traffic question

[Bryan Harris]

Hello,

I have a semi-working vpn from Windows 10 client to OpenBSD 6.4
running iked using machine certificates authentication method.

When I connect to the VPN, I can ping from Win 10 to the ip address of
enc0 on the other side (10.1.0.2). Unbound is listening on that ip
address, and DNS queries from my Windows 10 machine get to the unbound
and work correctly.

Unfortunately, regular web browsing from the Windows 10 PC does not
work. It appears the VPN or else my pf rules are not directing the
traffic back out of the egress interface, but I can't figure out why.
Likewise if I start a ping to a public IP address while the VPN is
running, the ping doesn't work. I do have net.inet.ip.forwarding=1
enabled in /etc/sysctl.conf. If I do the same ping without the VPN,
it works fine.

I have tried a few things as I'm having trouble understanding
basic VPN concepts, and therefore I can't seem to understand what might
be the cause of the problem.

1. Put a line "from 0.0.0.0/0 to 10.2.0.0/24" into the configuration.
2. Remove the "configure address 10.2.0.1/24" line
3. Various incarnations with/without srcid or "local  peer any"
4. Turning off Windows firewall
5. Trying to pass more and more traffic through pf
6. Rearranging the match out...nat-to lines at the bottom of pf.conf

My iked.conf and pf.conf configurations are down below.

Also some info about the vpn ca and certificates--The server cert CN is
the server ip. It's also named the server ip. The Windows 10 cert is
just named desktop- and the CN is the same. The CA cert is on the
machine store Trusted Auth. The desktop- cert is on the machine
store Personal.

Is there anything obviously wrong in the configuration? Can anyone point
me in the direction of the mistake?

Any help would be greatly appreciated. Thanks in advance.

V/r,
Bryan

# $OpenBSD: iked.conf,v 1.1 2014/07/11 21:20:10 deraadt Exp $
#
# See iked.conf(5) for syntax and examples.
ikev2 "win10" passive esp \
   from 10.1.0.0/24 to 10.2.0.0/24 \
   local any peer any \
   srcid ...OMITTED... \
   config address 10.2.0.1/24 \
   config name-server 10.1.0.2 \
   tag "$name-$id"


# $OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42 deraadt Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf

ssh_nets="{ ...OMITTED... }"


set skip on { lo0, enc0 }
set limit table-entries 40

# rules for spamd(8)
table  persist
table  persist file "/etc/mail/common_domains_white"
table  persist file "/etc/mail/nospamd"
table  persist

block drop log all
antispoof for egress
match in all scrub (no-df max-mss 1440)

pass quick inet proto icmp icmp-type { echoreq, unreach }

pass in on egress inet proto tcp from $ssh_nets to egress:0 port 22
pass in on egress inet proto udp from any to egress:0 port 53
pass in on egress inet proto tcp from any to egress:0 \
    port { 53 80 443 }
pass in on egress inet proto tcp from $ssh_nets to egress:0 \
    port { 465 587 993 }

pass in on egress proto { ah, esp } from any to any
pass in on egress proto udp from any to any port { 500, 4500 }

pass in on egress inet proto tcp from any to any port smtp \
    rdr-to lo0 port spamd
pass in on egress inet proto tcp from  to any port smtp \
    rdr-to lo0 port smtp
pass in log on egress inet proto tcp from  to any \
    port smtp rdr-to lo0 port smtp
pass in log on egress inet proto tcp from  to any \
    port smtp rdr-to lo0 port smtp
pass in log quick on egress inet proto tcp from  \
    to any port smtp rdr-to lo0 port smtp

pass on { vether tap }

pass out all

match out on egress inet from vether0:network nat-to (egress)
match out on egress inet from enc0:network nat-to (egress)

Re: amd64.iso KVM guest kernel panic pc=ffffffff811c303c (Opteron_G3 to Opteron_G5)

[Bryan Steele]

On Mon, Oct 22, 2018 at 09:49:54AM -0700, Mike Larkin wrote:
> On Mon, Oct 22, 2018 at 07:09:21AM +0300, snikolov wrote:
> > Dear All,
> > 
> > I have managed to configure and get the output of the serial console on
> > KVM and here is the output (with different CPU type only the name of
> > the CPU changes) :
> > ~~
> > >> OpenBSD/amd64 CDBOOT 3.40
> > boot> 
> > cannot open cd0a:/etc/random.seed: No such file or directory
> > booting cd0a:/6.4/amd64/bsd.rd: 354+1500160+3892040+0+598016
> > [372715+111+441072+293323]=0xa208a0
> > entry point at 0x1000158
> > Copyright (c) 1982, 1986, 1989, 1991, 1993
> > The Regents of the University of California.  All rights
> > reserved.
> > Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.Open
> > BSD.org
> > 
> > OpenBSD 6.4 (RAMDISK_CD) #348: Thu Oct 11 13:36:16 MDT 2018
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_C
> > D
> > real mem = 4278030336 (4079MB)
> > avail mem = 4144590848 (3952MB)
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6110 (11 entries)
> > bios0: vendor SeaBIOS version "1.11.0-2.el7" date 04/01/2014
> > bios0: Red Hat KVM
> > 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: AMD Opteron 63xx class CPU, 3992.09 MHz, 15-02-00
> > cpu0:
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36
> > ,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2A
> > PIC,POPCNT,AES,XSAVE,AVX,F16C,HV,NXE,PAGE1GB,LONG,LAHF,ABM,SSE4A,MASSE,
> > 3DNOWP,XOP,FMA4,TBM
> > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> > 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 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
> > fatal protection fault in supervisor mode
> > trap type 4 code 0 rip 811c303c cs 8 rflags 10202 cr2  0 cpl e
> > rsp 81a06a20
> > gsbase 0x81872ff0  kgsbase 0x0
> > panic: trap type 4, code=0, pc=811c303c
> > 
> > The operating system has halted.
> > Please press any key to reboot.
> > ~~
> > 
> > Should I report this as a bug ?
> > 
> > Best Regards,
> > Strahil Nikolov
> > 
> > 
> > On Sun, 2018-10-21 at 18:07 +0300, snikolov wrote:
> > > Hello All,
> > > 
> > > During install of install64.iso I experience a kernel panic during
> > > boot of the CD (pc=811c303c).
> > > install64.iso sha256sum is
> > > 81833b79e23dc0f961ac5fb34484bca66386deb3181ddb8236870fa4f488cdd2
> > > which
> > > matches https://cdn.openbsd.org/pub/OpenBSD/6.4/amd64/SHA256
> > > 
> > > I have tested with various CPUs on my RHEL 7.5 and it seems that
> > > Opteron_G3/G4/G5 and FX-8350 (host-passthrough) causes the
> > > panic,while
> > > Opteron_G1/G2 is OK. Booting install63.iso on the same VM is OK and I
> > > got the installer prompt.
> > > 
> > > Does anyone observes the same behaviour or it is only me ?
> > > 
> > > Best Regards,
> > > Strahil Nikolov
> > 
> 
> This appears to be related to the LFENCE serializing MSR change that went in
> during the last round of side channel analysis fixes:
> 
> 811c3037:   b9 29 10 01 c0  mov$0xc0011029,%ecx
> 811c303c:   0f 32   rdmsr
> 
> According to the commit, "This MSR is available on all AMD families >= 
> 10h...",
> and since yours is family 15h, it should work. Maybe that assumption was 
> wrong?
> 
> -ml

This appears to be another case of an outdated host kernel / KVM
combination. If you tried to boot OpenBSD on the bare hardware,
it wouldn't panic.

We're following AMD's recommendation here, as far as can tell.

https://marc.info/?l=openbsd-misc=153315801921789=2

-Bryan.

Re: phonetic alphabet on OpenBSD

[Bryan Linton]

On 2018-10-14 20:56:05, Jan Stary  wrote:
> Are there any phoneticians running on OpenBSD?
> How do you type the phonetic alphabet in vim?
> Is there a standard keyboard layout for the English part of IPA?
> 
> I wrote me an ipa.vim ftplugin with shortcuts (such as imap ,ae)
> for the unicode chars, but I am looking for a "standard" way.
> 
>   Thank you
> 

I use ports/inputmethods/uim with both terminal and GUI applications
and it works just fine.

I have it set up to use both anthy (for Japanese input) and IPA
(via X-SAMPA input).  CTRL-Shift gets me Japanese, and then ALT-Space
gets me IPA input.  Japanese input works just fine in the terminal,
and so does IPA input.

Sometimes it's difficult to figure out what key inputs what, in
which case I look through /usr/local/share/uim/ipa-x-sampa.scm

ˌɪntɚˈnæʃənl̻ fʌˈnɛtɪk ˈælfəˌbɪt

I just typed that with my keyboard (no copying or pasting) though
I had to have the above-mentioned ipa-x-sampa.scm file open to
reference some of the diacritics :)

I would imagine that any IME (like UIM or SCIM) would be the 
most "standard" way to do things.  It certainly beats copy/pasting
things (as I've done before on occasion).

-- 
Bryan

Re: Cloud-Storage & OpenBSD

[Bryan Harris]

Tarsnap?

Sent from my iPhone

> On Sep 2, 2018, at 10:43 AM, Kurtis  wrote:
> 
> Hey all,
> 
> I'm just wondering if anyone has any suggestions with any Online File Backup 
> / Synchronization services?
> 
> I used Dropbox for a long time but decided to drop it in favor of pCloud. 
> It's about time to do another annual subscription so I'm looking at options.
> 
> I use the same service for backing up photos from my phone, backing up 
> documents from computers, and syncing files between multiple machines (Mac, 
> Windows, and Linux, Android).
> 
> Specifically, I'm looking for a service that is compatible with the major 
> operating systems but also has a good client for OpenBSD.
> 
> Bonus feature would be the ability to share the service with my family using 
> different accounts.
> 
> The ability to generate credentials that can only access certain folders 
> would be _really_ cool. For example, my machines could generate reports and 
> store them in my sync'd service so I could simplify viewing them from any 
> machine.
> 
> Thanks!
> 
> 
> 

Re: join id cannot be integer

[Bryan Vyhmeister]

On Wed, Aug 08, 2018 at 05:43:08PM +0200, Stefan Sperling wrote:
> join and nwid are mutually exclusive commands.

Apparently I did not read the join info properly. Thanks for the clue
stick and sorry for the noise.

Bryan

join id cannot be integer

[Bryan Vyhmeister]

I have not investigated the full scenario here but using the new join
option for wireless network configuration does not seem to work if I use
an ID of 0, 1, or 2 and probably others. Is this expected? The man page
seems to indicate that this should work fine. From ifconfig(8):

"The id can either be any text string up to 32 characters in length, or
a series of hexadecimal digits up to 64 digits. Any necessary wpakey or
nwkey arguments should be specified on the same line."

Here is the scenario to test.

/etc/hostname.iwm0:
join 0 nwid TEST wpakey 1234567890
dhcp

This will not work and I will end up associated to the AP but status
will always stay as no network.

/etc/hostname.iwm0:
join TEST nwid TEST wpakey 1234567890
dhcp

This will work as expected.

Bryan

Re: NSA encryption algorithms in Linux kernel, OpenBSD too?

[Bryan Harris]

> On Aug 7, 2018, at 7:15 AM, Kevin Chadwick  wrote:
> 
> On Mon, 6 Aug 2018 15:52:11 -0500

> It may be more likely that some zealous chrome devs
> decided https everywhere was utterly important and so misleading
> messages were the order of the day.

For some reason I thought https everywhere was a government initiative. Or 
perhaps they just followed the trend.

Bryan

Re: 014_amdlfence.patch breaks OpenBSD VMs on AMD systems

[Bryan Steele]

On Wed, Aug 01, 2018 at 01:07:33PM -0700, Mike Larkin wrote:
> On Wed, Aug 01, 2018 at 12:14:59PM -0400, Bryan Steele wrote:
> > On Wed, Aug 01, 2018 at 11:27:26AM -0400, Bryan Steele wrote:
> > > On Wed, Aug 01, 2018 at 03:46:25PM +0200, Elmer Skjødt Henriksen wrote:
> > > > After installing the 014_amdlfence patch released yesterday for 6.3, my
> > > > OpenBSD VM crashes on boot. It's running under KVM on a Linux box 
> > > > (Ubuntu
> > > > 18.04 w/ kernel 4.15) on an AMD Ryzen 7 1700 (microcode 0x8001137).
> > > > I suppose this would also happen on vmm(4) and bhyve, however I don't 
> > > > have
> > > > any such AMD hosts available for testing.
> > > 
> > > Hi Elmer,
> > > 
> > > This was tested in vmm(4), which does work, unfortunately there was not
> > > extensive testing by in other virtualization software. The MSR that is
> > > being set here is only mentioned in AMDs whitepaper and I had no reason
> > > to believe any special consideration was needed for guest VMs on AMD
> > > processors.
> > > 
> > > > It occurs both using libvirt's "EPYC" CPU model and using 
> > > > "host-passthrough"
> > > > (i.e. no virtual CPU model), but the "core2duo" CPU model works fine.
> > > > 
> > > > I guess not many people are running OpenBSD as a VM, and even less on 
> > > > AMD
> > > > hardware. But still, a syspatch leaving the system unable to boot is
> > > > probably not a good thing. :)
> > > > 
> > > 
> > > Even so, I would like to apologize. This situation is unfortunate, and
> > > I'll try to work with other developers to find the best way forward.
> > > But, I regret I am only but an amateur magician.
> > > 
> > > -Bryan.
> > 
> > Actually, it looks like this is at least partially a KVM/QEMU bug. In
> > the meantime I guess the solution would be to do as you suggested and
> > set a different CPU model for now until Linux distros include a fix for
> > this.
> > 
> > https://lkml.org/lkml/2018/2/21/1202
> > 
> > Afterwards, on the OpenBSD side, it looks like one small change may be
> > required in addition..
> > 
> > -Bryan.
> > 
> > Index: sys/arch/amd64/amd64/identcpu.c
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
> > retrieving revision 1.95.2.2
> > diff -u -p -u -r1.95.2.2 identcpu.c
> > --- sys/arch/amd64/amd64/identcpu.c 30 Jul 2018 14:45:05 -  1.95.2.2
> > +++ sys/arch/amd64/amd64/identcpu.c 1 Aug 2018 16:09:50 -
> > @@ -650,8 +650,10 @@ identifycpu(struct cpu_info *ci)
> >  
> > msr = rdmsr(MSR_DE_CFG);
> >  #define DE_CFG_SERIALIZE_LFENCE(1 << 1)
> > -   msr |= DE_CFG_SERIALIZE_LFENCE;
> > -   wrmsr(MSR_DE_CFG, msr);
> > +   if ((msr & DE_CFG_SERIALIZE_LFENCE) == 0) {
> > +   msr |= DE_CFG_SERIALIZE_LFENCE;
> > +   wrmsr(MSR_DE_CFG, msr);
> > +   }
> > }
> > }
> >  
> > 
> 
> As expected, -current works properly on real AMD hardware. So my assumption
> about KVM doing something odd seems to be correct.
> 
> The issue should be reported upstream to the KVM folks. But if the diff above
> also fixes the issue (I didn't test because I cannot reproduce it), ok 
> mlarkin.
> 
> -ml

I committed a fix for the potential MSR write #GP bug to -current:

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

Unfortunately, for the MSR read issue on older KVMs, it would require
adding additional code to determine if we're running under KVM, there's
really not much at all we can do here..

I agree these seem like KVM bugs, as this does not happen on real
hardware, and at least also not in OpenBSD vmm(4).

-Bryan.

Re: 014_amdlfence.patch breaks OpenBSD VMs on AMD systems

[Bryan Steele]

On Wed, Aug 01, 2018 at 11:27:26AM -0400, Bryan Steele wrote:
> On Wed, Aug 01, 2018 at 03:46:25PM +0200, Elmer Skjødt Henriksen wrote:
> > After installing the 014_amdlfence patch released yesterday for 6.3, my
> > OpenBSD VM crashes on boot. It's running under KVM on a Linux box (Ubuntu
> > 18.04 w/ kernel 4.15) on an AMD Ryzen 7 1700 (microcode 0x8001137).
> > I suppose this would also happen on vmm(4) and bhyve, however I don't have
> > any such AMD hosts available for testing.
> 
> Hi Elmer,
> 
> This was tested in vmm(4), which does work, unfortunately there was not
> extensive testing by in other virtualization software. The MSR that is
> being set here is only mentioned in AMDs whitepaper and I had no reason
> to believe any special consideration was needed for guest VMs on AMD
> processors.
> 
> > It occurs both using libvirt's "EPYC" CPU model and using "host-passthrough"
> > (i.e. no virtual CPU model), but the "core2duo" CPU model works fine.
> > 
> > I guess not many people are running OpenBSD as a VM, and even less on AMD
> > hardware. But still, a syspatch leaving the system unable to boot is
> > probably not a good thing. :)
> > 
> 
> Even so, I would like to apologize. This situation is unfortunate, and
> I'll try to work with other developers to find the best way forward.
> But, I regret I am only but an amateur magician.
> 
> -Bryan.

Actually, it looks like this is at least partially a KVM/QEMU bug. In
the meantime I guess the solution would be to do as you suggested and
set a different CPU model for now until Linux distros include a fix for
this.

https://lkml.org/lkml/2018/2/21/1202

Afterwards, on the OpenBSD side, it looks like one small change may be
required in addition..

-Bryan.

Index: sys/arch/amd64/amd64/identcpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
retrieving revision 1.95.2.2
diff -u -p -u -r1.95.2.2 identcpu.c
--- sys/arch/amd64/amd64/identcpu.c 30 Jul 2018 14:45:05 -  1.95.2.2
+++ sys/arch/amd64/amd64/identcpu.c 1 Aug 2018 16:09:50 -
@@ -650,8 +650,10 @@ identifycpu(struct cpu_info *ci)
 
msr = rdmsr(MSR_DE_CFG);
 #define DE_CFG_SERIALIZE_LFENCE(1 << 1)
-   msr |= DE_CFG_SERIALIZE_LFENCE;
-   wrmsr(MSR_DE_CFG, msr);
+   if ((msr & DE_CFG_SERIALIZE_LFENCE) == 0) {
+   msr |= DE_CFG_SERIALIZE_LFENCE;
+   wrmsr(MSR_DE_CFG, msr);
+   }
}
}
 

Re: 014_amdlfence.patch breaks OpenBSD VMs on AMD systems

[Bryan Steele]

On Wed, Aug 01, 2018 at 03:46:25PM +0200, Elmer Skjødt Henriksen wrote:
> After installing the 014_amdlfence patch released yesterday for 6.3, my
> OpenBSD VM crashes on boot. It's running under KVM on a Linux box (Ubuntu
> 18.04 w/ kernel 4.15) on an AMD Ryzen 7 1700 (microcode 0x8001137).
> I suppose this would also happen on vmm(4) and bhyve, however I don't have
> any such AMD hosts available for testing.

Hi Elmer,

This was tested in vmm(4), which does work, unfortunately there was not
extensive testing by in other virtualization software. The MSR that is
being set here is only mentioned in AMDs whitepaper and I had no reason
to believe any special consideration was needed for guest VMs on AMD
processors.

> It occurs both using libvirt's "EPYC" CPU model and using "host-passthrough"
> (i.e. no virtual CPU model), but the "core2duo" CPU model works fine.
> 
> I guess not many people are running OpenBSD as a VM, and even less on AMD
> hardware. But still, a syspatch leaving the system unable to boot is
> probably not a good thing. :)
> 

Even so, I would like to apologize. This situation is unfortunate, and
I'll try to work with other developers to find the best way forward.
But, I regret I am only but an amateur magician.

-Bryan.

> Kernel output:
> >> OpenBSD/amd64 BOOT 3.34
> boot>
> booting hd0a:/bsd: 8616075+2454544+262168+0+671744
> [646904+98+712056+493074]=0xd39630
> entry point at 0x1000158
> [ using 1852976 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>   The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2018 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
> 
> OpenBSD 6.3 (GENERIC.MP) #7: Sun Jul 29 11:43:12 CEST 2018
> 
> r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 2130546688 (2031MB)
> avail mem = 2058960896 (1963MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6880 (10 entries)
> bios0: vendor SeaBIOS version "1.10.2-1ubuntu1" date 04/01/2014
> bios0: QEMU Standard PC (i440FX + PIIX, 1996)
> acpi0 at bios0: rev 0
> acpi0: sleep states S5
> acpi0: tables DSDT FACP APIC
> acpi0: wakeup devices
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Ryzen 7 1700 Eight-Core Processor, 2994.73 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 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
> kernel: protection fault trap, code=0
> Stopped at  identifycpu+0x7ad:  rdmsr
> ddb{0}> trace
> identifycpu(81a99ff0,80039400,81d40a58,8000210b9000
> ,81d40a60,12ad28e092a02002) at identifycpu+0x7ad
> cpu_attach(80023100,81d40a58,81a97040,80039400,
> 80039424,12ad28e092a02002) at cpu_attach+0x326
> config_attach(0,8001c744,8001c718,8001c744,81d4
> 0a38,813ce5d0) at config_attach+0x1d8
> acpimadt_attach(80020400,81d40b60,81aa84d0,8003
> 9b80,80039ba4,12ad28e092a02002) at acpimadt_attach+0x3be
> config_attach(81d40b60,80020400,80020470,800204
> 60,8001c700,81683350) at config_attach+0x1d8
> acpi_attach(80023180,81d40c50,81abf0d8,80020400
> ,80020424,12ad28e092a02002) at acpi_attach+0x5c1
> config_attach(8000210b7884,80023180,50,118,8000210b78b0,fff
> f81256180) at config_attach+0x1d8
> bios_attach(80023100,81d40d88,81aa2188,80023180
> ,800231a4,12ad28e092a02002) at bios_attach+0x636
> config_attach(81d40d88,80023100,81ab0bb0,800231
> 00,80023124,81456d90) at config_attach+0x1d8
> mainbus_attach(0,0,12ad28e092a02002,81d40db0,81d40e20,30001
> 0) at mainbus_attach+0x71
> config_attach(0,819a78b4,81ac8fd2,81d40e78,b28,0) at
> co
> nfig_attach+0x1d8
> config_rootfound(0,0,0,0,81d3a008,1

Re: POWER9 hardware donation

[Bryan Steele]

On Tue, Jul 24, 2018 at 08:27:44PM +0200, Pascal de Kloe wrote:
> I'm offering my brand new IBM 9006-22P with two 16-core 2.9GHZ CPUs to
> the OpenBSD project for free. Who can make the hardware port happen?
> Serious attempts only.

Sounds like strings attached.

Re: Stockholm anoncvs rsync mirror not updating

[Bryan Vyhmeister]

This is probably due to the Hackathon from July 8-13 and that at least
some developers are probably still traveling. Snapshots are often not
built for public use during that time from my observation but it is
unusual for cvs changes to not be fanning out to the mirrors. Perhaps
some maintenantce issue or something else is going on. It is not
specific to one mirror as far as I can tell from two other Canadian and
US mirrors using cvsync or rsync for cvs.

Bryan

Re: Installed current on top of FAT32 flash, Recover old filesystem??

[Bryan Linton]

 since its FUSE support doesn't seem to work on
OpenBSD yet, but it has compression and dedup so it saves a lot
more space than rsync does.


I hope some of this advice is useful, and that you can manage to
salvage what you need from the disk.

If you're successful, please consider updating the list with the
steps you took.

-- 
Bryan

Re: Configuration of a umb device

[Bryan Vyhmeister]

On Mon, Jul 09, 2018 at 12:37:42AM +, salan...@ouvaton.org wrote:
> Could someone direct me as to how to set up my computer such that I can
> get internet access through? I installed a this model of US Mobile SIM card.
> https://www.usmobile.com/shop/product/Triple-Cut-GSM-SIM-Card
> 
> Then I ran the commands below. What do I need to do next?
> 
> $ dmesg|grep umb 
> umb0 at uhub0 port 4 configuration 1 interface 6 "Lenovo N5321 gw" rev 
> 2.00/0.00 addr 2
> $ ifconfig apn pwg pin 1234 class 2G roaming up
> $ ifconfig
> umb0: flags=8851 mtu 1500
> index 5 priority 0 llprio 3
> roaming enabled registration home network
> state up cell-class EDGE rssi -77dBm speed 60.4Kps up 242Kps down
> SIM initialized PIN valid (3 attempts left)
> subscriber-id 310260855911295 ICC-id 8901260851159112954 provider US Mobile
> device KRD 131 30/123 - R1A/1 IMEI 004401701565398 firmware R3C11 (Pro), 
> R4A10 (App)
> APN pwg
> dns 10.177.0.34 10.177.0.210
> status: active
> inet 100.144.58.19 --> 100.144.58.18 netmask 0xfff8

The general idea is you need to add a route that points to the
interface rather than the IP address. You still need an IP address for
the route command. I wrote a script that automates bringing up a umb(4)
connection. It is configured by default for AT

https://raw.githubusercontent.com/brycv/openbsd-scripts/master/cell-setup

To add the default route, use the following command.

route add -ifp umb0 default 100.144.58.19

This command would be correct for the information you have above. The
-ifp option allows you to specify the name of the interface you are
using for the default route. Then you also add the IP address you are
assigned since route(8) requires an IP address for the command.

The script also adds the dns entry (AT only provides one where it
looks like you get two on the dns line) to /etc/resolv.conf so
everything works as expected.

Bryan

Re: 4k display on integrated Intel graphics?

[Bryan Vyhmeister]

On Fri, Jun 29, 2018 at 11:04:12PM +0200, Maximilian Pichler wrote:
> Thanks for explaining. Some shaking could be lived with...

I went ahead and bought a Plugable USB-C to DisplayPort cable to confirm
that there are no issues. I unplugged my mDP to DP cable from the
NUC6i7KYK and the HP Z27s 3840x2160 monitor and replaced it with the
USB-C to DP cable and everything works exactly as before. Running xrandr
reports that I am running on DP-2 at 3840x2160 at 60Hz.

> I just realized that some monitors (e.g. LG 27UD88) can connect via
> USB-C directly, whilest serving as a USB hub and power source. Would
> this be expected to work as well?

This type of thing should work fine as the other poster said also. This
charging functionality is not OS-dependent and should work because of
device firmware. USB-C can carry different types of signals that have
been around a while and can be quite convenient as a result.

Bryan

Re: Backup of OpenBSD under VMware

[Bryan Harris]

Last resort shut down VM then backup.

I like the tool called tarsnap. It backs up to a remote service and you keep a 
private key. Everything is encrypted before it “exits” your VM for the remote 
side. Also very cheap. 

I only backup a few files and spent barely a penny.

> Your current account balance is
> $4.990771969348983750.

V/r,
Bryan

Sent from my iPhone

> On Jun 30, 2018, at 8:23 AM, Paolo Aglialoro  wrote:
> 
> Hello,
> 
> the scenario is a cluster of ESXi nodes on which OpenBSD should run as a VM.
> 
> Currently the cluster is being backed up by Veeam, I tried to insert th
> obsd VM inside the backup job but no success, with following "Error: An
> error occurred while saving the snapshot: Failed to quiesce the virtual
> machine.". This looks strange to me because the open-vm-tools implemented
> inside the kernel are usually functional to ESXi hosts.
> 
> Questions:
> 1. has anybody found a way to use Veeam to backup OpenBSD VMs?
> 2. are there any other suggested softwares to perform a similar task?
> 
> Thanks

Re: 4k display on integrated Intel graphics?

[Bryan Vyhmeister]

On Fri, Jun 29, 2018 at 06:01:06PM +0200, Maximilian Pichler wrote:
> Does this mean it's unlikely to work with an USB-C-to-DP adapter or
> just hasn't been tried?

It should work fine because the USB-C ports have DisplayPort signaling
built-in and I would not expect any issues.

https://www.displayport.org/displayport-over-usb-c/

HDMI 1.4 does not support 4k at 60Hz like HDMI 2.0 does but HDMI 2.0 is
not supported as you found out. I have not tested USB-C to DP
specifically with my NUC6i7KYK but it does drive 4k over DisplayPort
which should be the same with USB-C to DP. I do get some weird artifacts
like the screen "shaking" back and forth a bit until I launch Xorg which
then works perfectly.

Bryan

Re: FAQ: dmesg archive

[Bryan Vyhmeister]

Looking at Supermicro's page, it's pretty easy to get some answers.

http://www.supermicro.com/products/system/Mini-ITX/SYS-E300-9A-8CN8.cfm

The 4 gigabit Intel i350-AM4 controllers should work fine since they do
on other systems of the previous C2xxx systems. However, the 4 gigabit
Marvell 88E1543 controllers are unlikely to work as best I can tell.
Doing an apropos search for Marvell does not yield a man page that
mentions this chipset. Not much has happened with msk(4) or sk(4)
recently.

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_msk.c
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_sk.c

So you probably will not have great support at this time. Something like
the E300-8D might be a better choice. I have been looking at the X10SDV
boards (especially the X10SDV-2C-TP4F and X10SDV-2C-TP8F) personally and
will be building some firewalls with them soon.

Bryan

Re: Partitioning recommendations for 6.3?

[Bryan Harris]

The webserver is called httpd (not the apache one). I like this book but
some people don't need the extra help of a book (I do).

https://www.michaelwlucas.com/tools/relayd

On Mon, Jun 25, 2018 at 11:49 AM John Long  wrote:

> On Mon, 2018-06-25 at 10:15 -0500, Vijay Sankar wrote:
> > Here is my df -h output -- Just as an FYI I was testing some
> > workarounds for the samba virusfilter issue and then made some
> > mistakes that screwed up KDE etc. So decided to build it from
> > scratch
> > and have about 5000 packages built right now with the following
> > disk
> > usage.
> >
> > $ df -h
> > Filesystem SizeUsed   Avail Capacity  Mounted on
> > /dev/sd0a 1005M102M852M11%/
> > /dev/sd0l  3.9G1.8G2.0G48%/builds
> > /dev/sd0k  127G1.3G119G 1%/home
> > /dev/sd0d  3.9G7.2M3.7G 0%/tmp
> > /dev/sd0f  5.9G1.9G3.8G33%/usr
> > /dev/sd0g  2.0G185M1.7G10%/usr/X11R6
> > /dev/sd0h 19.7G9.4G9.3G50%/usr/local
> > /dev/sd0j  5.9G3.3G2.3G59%/usr/obj
> > /dev/sd0i  2.0G990M929M52%/usr/src
> > /dev/sd0e 31.5G   57.9M   29.9G 0%/var
> > /dev/sd0m  243G   83.7G147G36%/usr/ports
>
> Thanks, this is good info.
>
> I am trying to find out about /usr/xenocara if it is still needed and
> also whether it's still recommended to build from source and track
> -stable or whether syspatch does away with that.
>
> What is the recommended http server these days? I remember the
> transition from apache to nginx. What's the conventional wisdom?
>
> My plan for this box is sftp, http, and minidlna server.
>
> Thank you,
>
> /jl
>
>

-- 
So the HP guy comes up to me and he says, 'If you say nasty things like
that to vendors you're not going to get anything'. I said 'no, in eight
years of saying nothing, we've got nothing, and I'm going to start saying
nasty things, in the hope that some of these vendors will start giving me
money so I'll shut up'.

 -Theo De Raadt

Re: Ubiquiti Networks EdgeRouter 6P

[Bryan Vyhmeister]

On Fri, May 25, 2018 at 06:43:57PM +, Chris Jones wrote:
> I see that the Ubiquiti EdgeRouter 6P is supported under octeon port.
> Just wondering if anyone on the list is running OpenBSD 6.3 or current
> on the EdgeRouter 6P? I'm mainly interested in the performance of this
> unit as a home firewall but also interested in using it for other SMB
> applications.

Yes, I am running -current on a number of EdgeRouter 4 and 6P units.
They seem to work quite well. Some cursory routing between subnets
performance tested with iperf3 yields a max of around 450 Mbps
throughput. There is a new octcrypto(4) driver which should be
interesting and is on my list to test for ipsec.

http://man.openbsd.org/octcrypto

The caveat I have seen is that the USB 3.0 controller is more finicky
than I would like but it seems to be working better recently with
xhci(4) fixes that have gone in over the last few months. I have had
good success with Samsung Fit USB 3.0 flash drives but had some initial
problems with Samsung T3/T5 USB 3.0 SSD drives erroring out with USB
problems. I use OpenBSD through resflash for the most part but vanilla
OpenBSD works fine although the library reordering is fairly slow (a
minute or two I think) on boot.

> I would generally be running standard network services plus 
> isakmpd/iked, ospfd, unbound. Also, is it fair to assume the PoE ports 
> are just active by default?

I have not done any ipsec but the rest work fine. The PoE ports do not
work at all under OpenBSD. PoE is off unless enabled through the EdgeOS
interface and there is no way to do that through OpenBSD. I would
recommend the EdgeRouter 4 unless you need to run from 24V DC power or
need the extra ports but PoE is useless unfortunately. Also, unlike with
the shared copper/fiber ports on the EdgeRouter Pro and UniFi Security
Gateway Pro, the fiber port on the ER-4/ER-6P works fine as an
additional port (cnmac0 actually).

Bryan

Re: acme-client new cert error

[Bryan Harris]

Ah okay. In my different situation I did

mv /etc/ssl/cert /tmp

Then ran command again.

I will try -D next time instead.

V/r,
Bryan 



> On May 25, 2018, at 5:51 PM, Scott Vanderbilt <li...@datagenic.com> wrote:
> 
>> On 5/25/2018 2:41 PM, Bryan Harris wrote:
>> Did you already have a cert for datagenic.com but which didn’t include the 
>> new name?
>> I think the -A argument only makes a new cert when old one doesn’t exist. 
>> Otherwise tries to use found cert and failed because old cert doesn’t have 
>> new name. At least that’s my understanding.
>> Or maybe I misunderstood the error message.
>> V/r,
>> Bryan
> 
> Thanks for chipping in.
> 
> Regrettably, I get the same error with -D flag only (i.e., no -A).
> 
> 
>>> On May 25, 2018, at 4:10 PM, Scott Vanderbilt <li...@datagenic.com> wrote:
>>> 
>>> I'm having difficulty creating a new SSL cert for a virtual host I'm just 
>>> standing up for the first time. I get the following error on successive 
>>> attempts:
>>> 
>>> urn:acme:error:unauthorized
>>> Error creating new cert :: authorizations for these names not found or 
>>> expired: aeneas.datagenic.com
>>> 
>>> I've verified it's not a web server access issue, as I am able to 
>>> successfully retrieve a static HTML file from the challenge directory
>>> 
>>>aeneas$ curl 
>>> http://aeneas.datagenic.com/.well-known/acme-challenge/test.html
>>>Foo
>>>aeneas$
>>> 
>>> Complete verbose error message, config file, and dmesg follow.
>>> 
>>> Thanks in advance for any assistance you can lend.
>>> 
>>> 
>>> 
>>> aeneas# acme-client -vvAD aeneas.datagenic.com
>>> acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: domain 
>>> key exists (not creating)
>>> acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists (not 
>>> creating)
>>> acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: loaded 
>>> RSA domain key
>>> acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
>>> acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
>>> acme-client: acme-v01.api.letsencrypt.org: DNS: 23.75.196.250
>>> acme-client: transfer buffer: [{ "key-change": 
>>> "https://acme-v01.api.letsencrypt.org/acme/key-change;, "meta": { 
>>> "caaIdentities": [ "letsencrypt.org" ], "terms-of-service": 
>>> "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf;, 
>>> "website": "https://letsencrypt.org; }, "new-authz": 
>>> "https://acme-v01.api.letsencrypt.org/acme/new-authz;, "new-cert": 
>>> "https://acme-v01.api.letsencrypt.org/acme/new-cert;, "new-reg": 
>>> "https://acme-v01.api.letsencrypt.org/acme/new-reg;, "revoke-cert": 
>>> "https://acme-v01.api.letsencrypt.org/acme/revoke-cert;, "sw0ePngTU-0": 
>>> "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417;
>>>  }] (658 bytes)
>>> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: req-auth: 
>>> aeneas.datagenic.com
>>> acme-client: acme-v01.api.letsencrypt.org: cached
>>> acme-client: acme-v01.api.letsencrypt.org: cached
>>> acme-client: transfer buffer: [{ "identifier": { "type": "dns", "value": 
>>> "aeneas.datagenic.com" }, "status": "pending", "expires": 
>>> "2018-06-01T19:22:23Z", "challenges": [ { "type": "tls-sni-01", "status": 
>>> "pending", "uri": 
>>> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114624;,
>>>  "token": "TpW1KNEcns3ebXVxbBwYToVOjsMEzR78MWySuyKvdhI" }, { "type": 
>>> "dns-01", "status": "pending", "uri": 
>>> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114625;,
>>>  "token": "Iq66R_OgKJ2VURMLyVxLD8hjnWtLqrjqSYb0L3YRqNU" }, { "type": 
>>> "http-01", "status": "pending", "uri": 
>>> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIci

Re: acme-client new cert error

[Bryan Harris]

Did you already have a cert for datagenic.com but which didn’t include the new 
name?

I think the -A argument only makes a new cert when old one doesn’t exist. 
Otherwise tries to use found cert and failed because old cert doesn’t have new 
name. At least that’s my understanding. 

Or maybe I misunderstood the error message.

V/r,
Bryan

> On May 25, 2018, at 4:10 PM, Scott Vanderbilt <li...@datagenic.com> wrote:
> 
> I'm having difficulty creating a new SSL cert for a virtual host I'm just 
> standing up for the first time. I get the following error on successive 
> attempts:
> 
> urn:acme:error:unauthorized
> Error creating new cert :: authorizations for these names not found or 
> expired: aeneas.datagenic.com
> 
> I've verified it's not a web server access issue, as I am able to 
> successfully retrieve a static HTML file from the challenge directory
> 
>aeneas$ curl 
> http://aeneas.datagenic.com/.well-known/acme-challenge/test.html
>Foo
>aeneas$
> 
> Complete verbose error message, config file, and dmesg follow.
> 
> Thanks in advance for any assistance you can lend.
> 
> 
> 
> aeneas# acme-client -vvAD aeneas.datagenic.com
> acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: domain 
> key exists (not creating)
> acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists (not 
> creating)
> acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: loaded 
> RSA domain key
> acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
> acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
> acme-client: acme-v01.api.letsencrypt.org: DNS: 23.75.196.250
> acme-client: transfer buffer: [{ "key-change": 
> "https://acme-v01.api.letsencrypt.org/acme/key-change;, "meta": { 
> "caaIdentities": [ "letsencrypt.org" ], "terms-of-service": 
> "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf;, 
> "website": "https://letsencrypt.org; }, "new-authz": 
> "https://acme-v01.api.letsencrypt.org/acme/new-authz;, "new-cert": 
> "https://acme-v01.api.letsencrypt.org/acme/new-cert;, "new-reg": 
> "https://acme-v01.api.letsencrypt.org/acme/new-reg;, "revoke-cert": 
> "https://acme-v01.api.letsencrypt.org/acme/revoke-cert;, "sw0ePngTU-0": 
> "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417;
>  }] (658 bytes)
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: req-auth: 
> aeneas.datagenic.com
> acme-client: acme-v01.api.letsencrypt.org: cached
> acme-client: acme-v01.api.letsencrypt.org: cached
> acme-client: transfer buffer: [{ "identifier": { "type": "dns", "value": 
> "aeneas.datagenic.com" }, "status": "pending", "expires": 
> "2018-06-01T19:22:23Z", "challenges": [ { "type": "tls-sni-01", "status": 
> "pending", "uri": 
> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114624;,
>  "token": "TpW1KNEcns3ebXVxbBwYToVOjsMEzR78MWySuyKvdhI" }, { "type": 
> "dns-01", "status": "pending", "uri": 
> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114625;,
>  "token": "Iq66R_OgKJ2VURMLyVxLD8hjnWtLqrjqSYb0L3YRqNU" }, { "type": 
> "http-01", "status": "pending", "uri": 
> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;,
>  "token": "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co" } ], "combinations": 
> [ [ 1 ], [ 0 ], [ 2 ] ] }] (998 bytes)
> acme-client: 
> /var/www/htdocs/default/acme/iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co: 
> created
> acme-client: 
> https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626:
>  challenge
> acme-client: acme-v01.api.letsencrypt.org: cached
> acme-client: acme-v01.api.letsencrypt.org: cached
> acme-client: transfer buffer: [{ "type": "http-01", "status": "pending", 
> "uri": 
> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;,
>  "token": "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co", "keyAuthorization": 
> 

Re: Viewport for man.openbsd.org -- readability on phones

[Bryan Steele]

On Fri, May 18, 2018 at 02:47:29AM +0200, Ingo Schwarze wrote:
> Hi Aner,
> 
> Aner Perez wrote on Thu, May 17, 2018 at 06:32:44PM -0400:
> > On 05/17/2018 05:22 PM, x...@dr.com wrote:
> >> "Ingo Schwarze" <schwa...@usta.de> wrote:
> 
> >>> Absolutely not.
> >>> Mandoc output is not optimized for any device.
> >>>
> >>> Which elements or rules in the current HTML or CSS code
> >>> make you think it is optimized or it discriminates against
> >>> any device?
> 
> >> I don't know which element or rule is the problem, however
> >> if I delete mandoc.css the text does fill the screen.
> >> 
> >> I understand that what I am trying to do is not supported,
> >> so I'll do something else instead.
> 
> > First non-comment line of mandoc.css says:
> > 
> > html {  max-width: 100ex; }
> > 
> > Removing this line allows the use of the full browser width.
> 
> That is a very useful bit of information.
> Thanks for investigating and reporting it.
> 
> For testing purposes, i removed that line from
>   https://man.openbsd.org/mandoc.css
> 
> xcv@, could you check with your phone whether this solves
> your original issue?
> 
> > I'm sure that it was put there for a reason
> > (maybe to approximate the width of a terminal?).
> 
> Correct.  The original reason was that for -T ascii and -T utf8
> output, the default is -O width=78.  The reason for that is that
> it's conventional wisom in typography that readability of text
> suffers with excessive column width - even though some recent
> research raises doubts whether that is really true.  Either way,
> people tend to feel strongly about it.
> 
> I must say i never particularly liked that line in the CSS file.
> It always felt like fiddling with details that it might be better
> not to touch, given that display devices running browsers differ
> more than terminal emulators.  And here we are with a suspicion
> that it actually causes accessibility issues, even if the suspicion
> is still unconfirmed...
> 
> Depending on the feedback i get here with respect to how
>   https://man.openbsd.org/
> now looks, i shall consider deleting the offending line for good.
> 
> In general, i like the idea of making things better by *removing*
> harmful tweaks rather than adding new goo...
> 
> Yours,
>   Ingo

I needed to shift-refresh in chromium to see the changes reflected.

IMHO this looks far worse on desktop, stretching out the text to very
long lines.

Would rather not see this change become permanent.

-Bryan.

Re: httpd - serving index.html & index.php at the same time

[Bryan Harris]

I'll ask a dumb question. Why do you need extra root directives? Can't you
do this?

location "^/phpapp/*" {
  directory index "index.php"
}
location "*.php" {
  fastcgi socket "/run/php-fmp.sock
}

Bryan

On Wed, Apr 11, 2018 at 10:32 AM, Mischa <obs...@high5.nl> wrote:

> > On 11 Apr 2018, at 12:14, Gregory Edigarov <ediga...@qarea.com> wrote:
> >
> > On 11.04.18 11:40, Mischa wrote
> >> Ok, good to know. It doesn't work as written. The only thing I see in
> the error.log is the fact that the PHP script is not found.
> >>
> >> Access to the script '/htdocs/s/' has been denied (see
> security.limit_extensions)
> >>
> >> Which tells me index.php is not requested.
> >>
> >> Browser tells me: File not found
> >>
> >> Running in debug mode it shows the following
> >>
> >> default 46.xx.xx.xx - - [11/Apr/2018:10:24:26 +0200] "GET /s/ HTTP/1.1"
> 404 0 "" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0)
> Gecko/20100101 Firefox/58.0"
> >> default 46.xx.xx.xx - - [11/Apr/2018:10:24:27 +0200] " " 408 0
> "" ""
> >> server default, client 1 (1 active), 46.xx.xx.xx:4824 -> xx.xx.xx.xx,
> timeout (408 Request Timeout)
> >> Primary script unknown
> >> default 46.xx.xx.xx - - [11/Apr/2018:10:24:27 +0200] "GET /s/ HTTP/1.1"
> 404 0 "" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0)
> Gecko/20100101 Firefox/58.0"
> >>
> >> Not sure what else to look at. :((
> > Did some tests.
> > here's how it works:
> >
> > location "/test" {
> > block return 301 "/test/"
> > }
> > location "/test/" {
> > root strip 1
> > root "/htdocs/phpapp"
> > directory index "test.php"
> > }
> >
> > note "root strip 1" directive.
>
> I had tried with strip 1 as well, it seems problem is with: fastcgi socket
> "/run/php-fpm.sock"
> The working end result is something like:
>
> server "default" {
> listen on $ext_addr port 80
> root "/htdocs/default"
> location "^/phpapp/*" {
> root { "/htdocs/phpapp", strip 1 }
> directory index "index.php"
> }
> location match "^/phpapp/[%l%u%d]+$" {
> root "/htdocs/phpapp/index.php"
> fastcgi socket "/run/php-fpm.sock"
> }
> location "/*.php*" {
> fastcgi socket "/run/php-fpm.sock"
> }
> }
>
> Thank you very much for your response and testing. Really appreciate it.
>
> Mischa
>
>


-- 
So the HP guy comes up to me and he says, 'If you say nasty things like
that to vendors you're not going to get anything'. I said 'no, in eight
years of saying nothing, we've got nothing, and I'm going to start saying
nasty things, in the hope that some of these vendors will start giving me
money so I'll shut up'.

 -Theo De Raadt

Re: httpd howto redirect port 80 to 443 in vm

[Bryan Harris]

Alternate?: go back to original config and change

server "default"

to

server "example.com"

And maybe an alias for "www.example.com."

Just a thought.

V/r,
Bryan

Re: gcc-4.9.4 package build signal 11 [Segmentation fault] on Ubiquiti Unifi Security Gateway

[Bryan Vyhmeister]

I have had a few discussions with visa@ about builds on OpenBSD/octeon.
For ports builds, 1GB of memory like in the EdgeRouter 4 and 6 is too
little to build big things like gcc which is required for quite a few
things. The EdgeRouter Lite, EdgeRouter PoE, and USG are even worse with
512MB of memory. Also, the EdgeRouter 4 and 6 have some issues with the
USB 3.0 controller that visa@ has not been able to work out yet. It's
pretty difficult to get any insight into what is happening with the USB
3.0 controller. The ER4 and ER6 work reasonably well with Samsung USB
Fit USB 3.0 flash drive but occasionally weird errors happen and the
system freezes up or panics. I was not able to get a Samsung T3 or T5
USB SSD to work with the ER4 or ER6.

The best route for a readily available machine for OpenBSD/octeon builds
is either the USG Pro 4 or the EdgeRouter Pro. They both come with 2GB
of memory but can be upgraded with up to 8GB of memory. Unlike the USB
flash drives in the USG and EdgeRouter Lite/PoE, the internal storage is
soldered on as was said in this thread already. The best route for
storage I have found thus far is a USB SSD like the Samsung T3 or T5. I
have not tested any others at this point but others probably work as
well.

For the EdgeRouter Pro, I have it running from a 250GB Samsung T3 USB
SSD and have upgraded it with an 8GB SODIMM of DDR3 1333MHz memory. The
part number that worked for the EdgeRouter Pro is Patriot PSD38G13332S.
I found this information from the UBNT forums.

For the USG Pro 4, I bought the same Patriot memory but had all sorts of
crashes and problems. I'm not sure if the memory chip is bad or if it is
just expecting different memory (have not had time to test) but I looked
at the factory memory in the USG Pro 4 and bought similar memory which
works fine. The factory chip is Kingston KVR16S11S6/2. I bought a set of
Kingston KVR16S11K2/16 which is two 8GB chips. They work perfectly and I
plan to get another USG Pro 4 for a second build machine to utilize the
second 8GB chip I have.

With 8GB of memory, most ports builds work fine including gcc but
occasionally I see some weird error that usually disappears with
restarting the dpb(1) build.

Bryan

Re: Wondering if any of my hardware is working on -current

[Bryan Steele]

On Wed, Feb 07, 2018 at 09:03:09PM -0800, Chris Bennett wrote:
> Does any of my hardware work in -current?
> 
> OpenBSD 6.2 (GENERIC.MP) #2: Sun Dec 10 21:14:42 CET 2017
> 
> r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay0

The keyboard probably qwertz.

-Bryan.

Re: AMD Pro A10/A12 Radeon R7 Support

[Bryan Vyhmeister]

On Tue, Jan 23, 2018 at 02:51:37PM +1100, Jonathan Gray wrote:
> The GCN parts like the 7750 (Cape VERDE) 7870 (PITCAIRN) will use
> the radeon xorg driver but will not have acceleration until the userland
> parts are sorted out which involves changing how LLVM is built, adding
> additional dependencies like libelf to base or xenocara and changing
> how Mesa is built.
> 
> I am looking into a radeondrm update that would add modesetting support
> for second generation GCN/sea islands parts and some more first
> generation southern islands parts.
> 
> ie, OLAND/HAINAN/BONAIRE/KABINI/MULLINS/KAVERI/HAWAII.

Thanks for the clarification. I will stick with Intel integrated
graphics for now until that gets sorted out somewhere down the line.
Thank you!

Bryan

Re: AMD Pro A10/A12 Radeon R7 Support

[Bryan Vyhmeister]

On Tue, Jan 23, 2018 at 11:57:35AM +1100, Jonathan Gray wrote:
> On Mon, Jan 22, 2018 at 10:43:03AM -0800, Bryan Vyhmeister wrote:
> > I have been looking at the new Lenovo ThinkPad A275 which is much like
> > the X260/X270 but with AMD Pro A10 or A12 chip and graphics. I am
> > interested in looking at something other than Intel for the first time
> > in more than a decade. I am interested in radeondrm(4) support for any
> > of the options available which are the AMD Pro A10-8730B, AMD Pro
> > A10-9700B, or AMD Pro A12-9800B. I am personally most interested in
> > ordering the AMD Pro A12-9800B. Any possilibity that radeondrm(4) might
> > work for these chips in some fashion?
> 
> CARRIZO parts like that would require a new amdgpu drm driver.

Understood. I will not get an A275 then. As far as radeondrm(4) support
goes, is my understanding from previous discussions correct that Radeon
HD 7750 or 7870 cards have kernel support but would have to be used
through the modesetting(4) driver in Xorg? I am still looking at those
cards for 4k monitor support for multiple monitors on a system that does
not have integrated graphics (Xeon E5 for example). In particular the
four mDP or six mDP cards are interesting to me. Thanks again.

Bryan

AMD Pro A10/A12 Radeon R7 Support

[Bryan Vyhmeister]

I have been looking at the new Lenovo ThinkPad A275 which is much like
the X260/X270 but with AMD Pro A10 or A12 chip and graphics. I am
interested in looking at something other than Intel for the first time
in more than a decade. I am interested in radeondrm(4) support for any
of the options available which are the AMD Pro A10-8730B, AMD Pro
A10-9700B, or AMD Pro A12-9800B. I am personally most interested in
ordering the AMD Pro A12-9800B. Any possilibity that radeondrm(4) might
work for these chips in some fashion?

Bryan

Re: Flatbed scanner that works well with OpenBSD?

[Bryan Linton]

On 2018-01-19 21:59:09, Bryan Linton <b...@shoshoni.info> wrote:
> Hello misc@
> 
> I'm currently looking to purchase a scanner that works well with OpenBSD.
> 

I want to thank all the people who replied in this thread.

I tried searching for some of the models several posters recommended,
but unfortunately they seem to be too old to be found at the places I
looked.

I think my best bet is to find a cheap all-in-one device that can scan
directly to USB and just make use of that.

Thanks again to all who replied!

-- 
Bryan

Flatbed scanner that works well with OpenBSD?

[Bryan Linton]

Hello misc@

I'm currently looking to purchase a scanner that works well with OpenBSD.

I'm aware of the list provided at: 

http://www.sane-project.org/sane-mfgs.html

but I recently purchased (and returned) a scanner that was listed as being
fully supported on that list because no matter what I did, I couldn't
get it to work right with xsane or scanimage.  Though I purchased it used,
so it's possible it may have simply been broken from the get-go.

Does anyone happen to know of a scanner that is *known* to work well
with OpenBSD?

I don't really have any hard requirements other than it should be able
to scan in color as well as black and white, and should be able to scan
up to a minimum of 600 dpi (1200 dpi or more would be nice, but is not
required).

I have a feeling that the majority of scanners currently on the market
meet or exceed that, so hopefully anything will work well so long as it's
compatible with OpenBSD.

Many thanks for any assistance anyone can provide.

--
Bryan

Re: Strange message from syspatch

[Bryan Harris]

I once had incorrect VM time causing OCSP response like it was out of date,
and syspatch refused in a similar way. But different than your situation I
think.

V/r,
Bryan

On Fri, Jan 12, 2018 at 7:19 AM, Stuart Henderson <s...@spacehopper.org>
wrote:

> On 2018-01-12, dmitry.sensei <dmitry.sen...@gmail.com> wrote:
> > Strange message from syspatch:
> > # syspatch
> > ftp: SSL write error: no OCSP URLs in peer certificate
> > #
>
> Simplest workaround is to download the files yourself and use a local
> url in /etc/installurl, e.g. file:///tmp/syspatch.
>
> > what does this message mean and what to check?
> >
> > OpenBSD 6.2-stable GENERIC.MP#2 amd64
> >
> > we have a fortinet in the middle. Previously, it did not interfere with
> the
> > utility, since I added its certificate
>
> Most likely the fortinet doesn't include any OCSP URL in its MITM
> certificate, but just to be sure, which mirror? (cat /etc/installurl),
> and what's in the cert?
>
> $ openssl s_client -connect $hostname:443 -servername $hostname
>
> then copy the server cert and paste into "openssl x509 -text -noout".
>
> CA/B Forum requires an OCSP URL in certs unless stapling is used. But I
> don't see how a CA is going to know whether stapling is used so I would
> expect certs from the cabal to always have this set so we're unlikely to
> run into this with normal servers. So, although we're unlikely to bump
> into problems with this code without MITM, I think libtls may be going
> a little beyond usual requirements in needing this.
>
>

Video-conferencing tool a la Skype or Facetime for OpenBSD?

[Bryan Linton]

Hello misc@

I have a friend who runs Windows who has asked me if there is any
way we can occasionally communicate with each other via some kind 
of video-conferencing application similar to what programs like
Skype and Facetime provide.

Does such a thing already exist for OpenBSD?

My requirements are fairly simple:
1) Must be usable between OpenBSD and Windows.
2) Must transmit/receive audio and video from a webcam.
3) Should be as point-and-click (on the Windows side) as possible.
4) Bonus points if it contains a text-based chatting feature.

For number 3, I can drive over to my friend's house and do a one-time
setup of anything highly technical, but after that, it should be as
simple for them as possible.  They're moderately technically inclined,
so entering a server/port/etc. is well within their means, but configuring
port-forwarding in their firewall and the like is something I'd have to
do myself.

Looking through the ports tree, I see a few programs that look promising,
like telephony/baresip but I don't see anything like Ekiga or Empathy.

Before I put the effort in to trying to get something working, I thought
it'd be prudent to ask the list if such a thing is even feasable first.

Any pointers (even a, "No, this isn't possible yet with OpenBSD <-> Windows")
would be appreciated.

Thank you!

-- 
Bryan

Re: Community-driven OpenBSD tutorials wiki?

[Bryan Harris]

My preference is to purchase a book. I have had a good experience with
Absolute OpenBSD, Httpd & Relayd, the tarsnap book, and the Book of PF.

I would buy a book about OpenSMTPD and also ikev2 but I didn't see any.

Just my $0.02, I like books better than online tutorials.

V/r,
Bryan

On Thu, Jan 4, 2018 at 10:38 AM, Marko Cupać <marko.cu...@mimar.rs> wrote:

> Feel free to contribute to [!WARNING - BLATANT SELF PROMOTION BELOW!]
>
> [https://www.mimar.rs/blog/tag:openbsd]
>
> As a side note, setting up apache and grav [https://getgrav.org/] took
> me an hour or so. Writing simple article takes whole day, sometimes
> much more.
> --
> Before enlightenment - chop wood, draw water.
> After  enlightenment - chop wood, draw water.
>
> Marko Cupać
> https://www.mimar.rs/
>
>

Re: pcengines apu boards

[Bryan Everly]

I'm running my primary firewall at home on an apu2...

On Thu, 2017-11-30 at 15:08 -0700, Base Pr1me wrote:
> I run 5 apu2 devices with no problems. I don't have any apu3 devices
> ... yet.
> 
> On 11/30/17 3:00 PM, Paul B. Henson wrote:
> > I was wondering if anybody is successfully running openbsd on
> > pcengines apu
> > boards? I have one of their APU3 series, specifically a apu3b4 with
> > OpenBSD
> > 6.2 on it but I can't get the USB2 EHCI ports functioning correctly
> > (for one
> > thing, they don't detect a hot plugged device), I'm not sure if
> > it's an
> > issue with the ehci driver and the amd ehci chipset or possibly
> > something in
> > the bios acpi tables. But just as a data point, it would be
> > interesting to
> > know if the problem is specific to my board or endemic to the
> > design, so if
> > anyone has an APU series board with fully functional USB2 ports on
> > the ehci
> > controller, I would much appreciate hearing which board it is,
> > which
> > specific AMD chipset is driving the controller, and what bios
> > version you
> > are running (and what OpenBSD version too).
> > 
> > Thanks much.
> > 
> 
> 

Re: The "like" factor

[Bryan Harris]

Re: question:

> How did you solve the "like" factor?

I don't know how true, but I like these passages.

"My mother had a favorite saying (origin unknown): "You can get used to
anything if you do it long enough. Even hanging." She trotted out that
saying whenever my siblings or I complained about something that wasn't
going to change."

And later:

"Persuasion Tip #22: People automatically get used to minor annoyances over
time."

"My mom’s point of view captures an important rule in persuasion. People
can get past minor annoyances if you give them enough time. Humans quickly
adapt to just about anything that doesn't kill them."

From Win Bigly by Scott Adams

V/r,
Bryan

On Sun, Nov 19, 2017 at 8:25 PM, Rupert Gallagher <r...@protonmail.com>
wrote:

> Yes, this may well be the problem: easier to understand if we speak of
> teddy bear, much harder if we speak
> of software upgrades! And yet, here we are...
>
> Sent from ProtonMail Mobile
>
> On Mon, Nov 20, 2017 at 02:17, <leo_...@volny.cz> wrote:
>
> > I wrote: > > In that case, I'd interpret the beancounter's reponse as
> 'have to make > sacrifices, don't we? *sigh*'. I amend that. Isn't it just
> loss? We experienced techies try not to allow ourselves to get too attached
> to an environment, don't we? But hasn't there been a 'first time' this has
> happened, for us all? And were *we* that prepared for it? It's like a
> replacement teddy bear, isn't it? The old one might be in pieces and still
> the new one won't ever feel as real. Or one's first love. It never quite
> feels the same again, does it? Perhaps a shared drink to mark the
> transition will help the grieving process along a little. I could still be
> all wrong, so I'll just shut up for now and see what others have to say.
> --schaafuit.
>

Re: iwm0 can't load firmware AC-3168

[Bryan Vyhmeister]

On Mon, Nov 13, 2017 at 08:55:36PM +, Stuart Henderson wrote:
> On 2017-11-13, Bryan Vyhmeister <br...@bsdjournal.net> wrote:
> > On Mon, Nov 13, 2017 at 11:08:32AM -0800, Sha'ul wrote:
> >> Running 6.2-release, after install rebooted and got iwm0 firmware from
> >> re0. Now can not load firmware. If this makes a difference, Intel graphics
> >> 620 only gives me a black screen, no kernel panic, and system seems to
> >> hang when I manually do startx.
> >
> > You have a Coffee Lake CPU which is not yet supported by inteldrm(4).
> > Up to Kaby Lake is supported by 6.2. You should be able to use wsfb(4)
> > for Xorg until inteldrm(4) support arrives. As for the iwm(4) firmware,
> > see:
> >
> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_iwmreg.h
> >
> > At the point of version 1.25, 3168 firmware had to be installed by hand.
> > The iwm-firmware package has not yet been updated to include those files
> > as far as I can tell. Someone else can point you to where the firmware
> > might be available from.
> >
> 3168 firmware was added in April, it is included in the version that
> will be installed if you run fw_update on 6.2.

Sorry for the misinformation. I should have checked /etc/firmware first.
The iwm-3168-22 file is right there from fw_update as you said.

Bryan