Re: How Do I Get The OpenBSD Install Procedure To Stop Trashing My Bootloader?

[Ashlen]

On Fri, 14 Jul 2023 19:46 +0200, Florian Obser wrote:
> On 2023-07-13 13:53 -05, "Jay F. Shachter"  wrote:
> > (Parenthetically, when is OpenBSD going to support ZFS, and join the
> > category of operating systems in which I can do serious work, i.e.,
> 
> What makes you think that's a goal for the people working on OpenBSD?
> 
> An actual, professional clown, who happens to use OpenBSD on their
> laptop suggested: "So simple, even a clown can do it."
> 
> Now that's a goal I can get behind.
> 
> -- 
> In my defence, I have been left unsupervised.
> 

That has to be one of the better slogans I've seen for OpenBSD.

Related to OP's mails:
https://unixsheikh.com/articles/when-you-use-open-source-software-you-are-not-entitled-to-anything.html

Re: Weird pf NAT failure on apu2

[Ashlen]

On Sat, 24 Jun 2023 07:33 -0600, Zack Newman wrote:
> On 6/2l/23 9:01, Stephan Neuhaus wrote:
> > I'm not sure about the Configuring NAT section being
> > correct. I still maintain that the documentation and
> > observed behaviour are different.
> 
> I was lazy when I said that. I meant the example I quoted from that
> section in the original reply is correct. Everything else that says
> otherwise (including the two people that said that part was wrong) is
> incorrect. Explicitly the following rule _is_ correct:
> 
> match out on interface [af] \
> from src_addr to dst_addr \
> nat-to ext_addr [pool_type] [static-port]
> [...]
> pass out [log] on interface [af] [proto protocol] \
> from ext_addr [port src_port] \
> to dst_addr [port dst_port]
> 
> There is only so many ways that this can be shown. If the pass out rule
> had "src_addr" instead of "ext_addr", it would be wrong. The diff that
> "fixes" that example needs to be rejected. It is the _other_ example
> that is wrong.
> 
> If you tried using the above example to get NAT to work, you will find
> that it will work. The last e-mail I sent clearly follows the above
> example except I chose to use stateless rules to help show more
> thoroughly all the rules that are necessary. Additionally, I prefer
> "quick" rules; but the conclusion is very clear: the match out rule
> applies and "sticks" which in turn means "src_addr" is replaced with
> "ext_addr" which in turn means the pass out rule must have "ext_addr".
> 

I forgot about that diff until I read your mail today. You're right,
I just tested that and your logic is sound. This is a good reminder
to me to test before sending diffs. I'm glad it wasn't committed.
Thank you for investigating that.

Re: Hibernation on Thinkpad Carbon X1 gen 7 - unhibernate failed

[Ashlen]

On Sat, 17 Jun 2023 19:00 +0100, Chris Narkiewicz wrote:
> On Sat, 2023-06-17 at 09:21 -0600, Ashlen wrote:
> > I have a 7th gen X1 Carbon and am not sure that the hardware is the
> > issue here. I've only experienced this very rarely.
> > 
> 
> I can confirm that I managed to unhibernate successfully and the error
> is no longer occuring, confirming your observation.
> 
> However, image unhibernation took about 5 minutes.
> 
> unhibernating @ block 50329532 length 750MB <- this takes ~5 minutes
> Unpacking image... <- this few seconds and I'm back in X11
> 
> I was so confused that I thought it just hangs.
> 
> How long does it take to ZZZ and unhibernate?
> 
> Cheers,
> Chris
> 

I'd assume that varies depending on the exact hardware in your machine
and the amount of memory saved to disk. Sometimes I've noticed that
unhibernating takes a couple of minutes if I had a lot of tabs open in a
browser or something, but it doesn't bother me that much.

Otherwise, I don't have the expertise in C to continue a meaningful
discussion about this. All I really did was search misc@ and grep the
source code.

Re: Hibernation on Thinkpad Carbon X1 gen 7 - unhibernate failed

[Ashlen]

On Fri, 16 Jun 2023 19:23 -0400, Dave Voutila wrote:
> 
> Chris Narkiewicz  writes:
> 
> > Hi,
> >
> > I got Thinkpad Carbon X1 gen7 and I tried to test hibernation (ZZZ).
> 
> Do you have a dmesg?
> 
> >
> > When system is resumed, it took several minutes to load image.
> > dmesg shows:
> >
> > unhibernate failed: original kernel changed
> >
> > and my iwm0 wifi card is not visible anymore.
> >
> > Is there someobdy with 7th gen X1 that could confirm?
> > According to https://jcs.org/2019/08/14/x1c7 it should work.
> >
> > Thanks for any suggestions,
> > Chris
> 

I have a 7th gen X1 Carbon and am not sure that the hardware is the
issue here. I've only experienced this very rarely.

That error is from a function named hibernate_compare_signature in
sys/kern/subr_hibernate.c. It's a safety check that makes sure the
machine matches the memory configuration and kernel of the one that
wrote the signature.

Did you syspatch(8) and then hibernate or something, particularly after
syspatch says to reboot? That'd probably cause that to happen.

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

P.S. Even though I'm not OP, here's my dmesg if it helps in some way.
OpenBSD 7.3-current (GENERIC.MP) #1240: Wed Jun 14 23:02:31 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16959836160 (16174MB)
avail mem = 16426180608 (15665MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xc7d49000 (64 entries)
bios0: vendor LENOVO version "N2HET71W (1.54 )" date 08/03/2022
bios0: LENOVO 20QDUS
efi0 at bios0: UEFI 2.6
efi0: Lenovo rev 0x1540
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT TPM2 UEFI SSDT HPET APIC MCFG 
ECDT SSDT SSDT SSDT BOOT SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB NHLT DMAR FPDT 
BGRT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) 
RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1727.61 MHz, 06-8e-0c
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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
4-way L2 cache, 8MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1450.28 MHz, 06-8e-0c
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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
4-way L2 cache, 8MB 64b/line 16-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1215.61 MHz, 06-8e-0c
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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
4-way L2 cache, 8MB 64b/line 16-way L3 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1054.83 MHz, 06-8e-0c
cpu3: 

Re: Generating xorg.conf

[Ashlen]

On Fri, 16 Jun 2023 18:57 +0100, Chris Narkiewicz wrote:
> Hi,
> 
> I'm trying to customize my touchpad input handling in X11.
> Normally I'd call X -configure to generate the config file
> and tune it to my needs.
> 
> X -h lists -configure as available options. However, when calling
> X -configure, it says option is not recognized:
> 
> # X -configure
> ...
> (EE)
> Fatal server error:
> (EE) Unrecognized option: -configure
> (EE)
> (EE)
> Please consult the The X.Org Foundation support
> ...
> 
> I'm puzzled. Is it supported? Can I generate xorg config?
> 
> Cheers,
> Chris
> 

Unsure why this fails, but in general it's better to place override
files in /etc/X11/xorg.conf.d/. You might also have some luck with
tweaking your touchpad using xinput(1), then sticking the commands in
~/.xsession.

wsconsctl(8) is also something to look at.

Re: happy birthday theo de raadt

[Ashlen]

On Fri, 19 May 2023 02:57 -0600, Mayuresh Kathe wrote:
> hey theo,
> wish you a very happy birthday.
> hope you have an interesting year ahead.
> and hope everybody out here "only" wish theo instead of
> also going off at a tangent and creating a mess.
> -mayuresh

Happy Birthday, Theo. ^-^

Re: Problem with WireGuard on OpenBSD 7.3

[Ashlen]

On 2023-05-08 23:15, Tor Houghton wrote:
> On Sat, May 06, 2023 at 04:40:21PM -, Stuart Henderson wrote:
> > 
> > [snip]
> >
> > wgport port-number wgkey my-private-key
> > inet 10.0.98.1/24
> > 
> > [snip]
> 
> Here's[*] a super hacky way to convert a pivpn wireguard config file to output
> that can be placed in a /etc/hostname.wg0 file, if this helps anyone at all.
> 
> $ cat client.conf | ./wgconv.sh
> 
> Tor
> 
> * https://www.bogus.net/~torh/files/wgconv.sh
> 

Huh, neat. :) It made me smile to see this because I wrote my own
pledged + unveiled tool in Perl for this exact same task some time ago.
Though mine does some basic validation on the IPs, base64 keys, etc.

Tool: https://github.com/3uryd1ce/sysadm/blob/master/translate_wg_conf
Man page: 
https://github.com/3uryd1ce/sysadm/blob/master/man/man1/translate_wg_conf.1

One thing to note is that it depends on p5-Config-Std and p5-Net-IP to
handle parsing and validation, so this would be needed first:

# pkg_add p5-Config-Std p5-Net-IP

Anyway, my self-plug is over. Hope it helps someone.

Re: autossh fails after upgrade to 7.3

[Ashlen]

On 2023-04-25 14:20, rea...@catastrophe.net wrote:
> On Tue, Apr 25, 2023 at 01:06:35PM -0600, Ashlen wrote:
> >On 2023-04-25 10:45, rea...@catastrophe.net wrote:
> >> After upgrading to 7.3 autossh is failing using the following rc script
> >> in /etc/rc.d/autossh.  It looks like maybe switching to $daemon_user is
> >> not happening to find the correct ssh config stanzas? Thanks in advance
> >> for any help.
> >> 
> >> 
> >> ## Startup configuration
> >> 
> >> #!/bin/ksh
> >> # start autossh tunnel
> >> # requires remoteuser user with $HOME/.ssh/config and keys
> >> 
> >> daemon="/usr/local/bin/autossh"
> >> daemon_flags_1="-M 0 -f -N tun-remoteA"
> >> daemon_flags_1="-M 0 -f -N tun-remoteB"
> >> daemon_user="remoteuser"
> >> 
> >> . /etc/rc.d/rc.subr
> >> 
> >> rc_reload=NO
> >> 
> >> pexp="autossh:.*"
> >> 
> >> # Child will not return a config parsing error to the parent.
> >> rc_start() {
> >> # use rcexec here since daemon_flags may contain arguments with 
> >> spaces
> >> ${rcexec} "${daemon} ${daemon_flags_1}" && \
> >> ${rcexec} "${daemon} ${daemon_flags_1}"
> >> }
> >> 
> >> rc_cmd $1
> >
> >${rcexec} was deprecated in 7.2 and dropped in 7.3. You have to use
> >rc_exec now.
> >
> ># sed -i 's/\${rcexec}/rc_exec/' /etc/rc.d/autossh
> >
> >https://www.openbsd.org/faq/upgrade72.html#ConfigChanges
> >https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/rc.d/rc.subr.diff?r1=1.159=1.160=h
> 
> Thanks for that. 
> 
> Even after I modified to use rc_exec I'm still getting the same problem of
> not switching to daemon_user . Comments added inline:
> 
> # rcctl -d start autossh
> doing _rc_parse_conf
> autossh_flags empty, using default ><
> doing rc_check
> autossh
> doing rc_start
> remoteuser
> ^^ daemon_user is correctly set to "remoteuser"
> doing _rc_wait_for_start
> doing rc_check
> root
>  here is where we should see "remoteuser" and not root when
> ^ running "whoami"
> /etc/rc.d/autossh: /usr/local/bin/autossh -M 0 -f -N tun-remoteA: not found
> doing _rc_rm_runfile
> (failed)
> 
> 
> The modified rc script that yields this output is:
> 
> #!/bin/ksh
> # start autossh tunnel
> # requires remoteuser user with $HOME/.ssh/config and keys
> 
> daemon="/usr/local/bin/autossh"
> daemon_flags_1="-M 0 -f -N rev-tun-lax"
> daemon_flags_2="-M 0 -f -N rev-tun-ord"
> daemon_user="as2h"
> 
> . /etc/rc.d/rc.subr
> 
> rc_reload=NO
> 
> pexp="autossh:.*"
> 
> # Child will not return a config parsing error to the parent.
> rc_start() {
> # use rc_exec here since daemon_flags may contain arguments with 
> spaces
>   echo ${daemon_user} # prove the variable is 
> set here
>   ${rc_exec} "/usr/bin/whoami"# show who we are running commands as
> ${rc_exec} "${daemon} ${daemon_flags_1}" && \
> ${rc_exec} "${daemon} ${daemon_flags_2}"
> }
> 
> rc_cmd $1

rc_exec is a function, not a variable. rc.subr(8) demonstrates how to
use it. This is what I meant for you to do:

rc_start() {
rc_exec "${daemon} ${daemon_flags_1}" && \
rc_exec "${daemon} ${daemon_flags_2}"
}

Though, I agree with Stuart. It doesn't make much sense to start two
daemons from one rc.d(8) script.

Re: autossh fails after upgrade to 7.3

[Ashlen]

On 2023-04-25 10:45, rea...@catastrophe.net wrote:
> After upgrading to 7.3 autossh is failing using the following rc script
> in /etc/rc.d/autossh.  It looks like maybe switching to $daemon_user is
> not happening to find the correct ssh config stanzas? Thanks in advance
> for any help.
> 
> 
> ## Startup configuration
> 
> #!/bin/ksh
> # start autossh tunnel
> # requires remoteuser user with $HOME/.ssh/config and keys
> 
> daemon="/usr/local/bin/autossh"
> daemon_flags_1="-M 0 -f -N tun-remoteA"
> daemon_flags_1="-M 0 -f -N tun-remoteB"
> daemon_user="remoteuser"
> 
> . /etc/rc.d/rc.subr
> 
> rc_reload=NO
> 
> pexp="autossh:.*"
> 
> # Child will not return a config parsing error to the parent.
> rc_start() {
> # use rcexec here since daemon_flags may contain arguments with spaces
> ${rcexec} "${daemon} ${daemon_flags_1}" && \
> ${rcexec} "${daemon} ${daemon_flags_1}"
> }
> 
> rc_cmd $1

${rcexec} was deprecated in 7.2 and dropped in 7.3. You have to use
rc_exec now.

# sed -i 's/\${rcexec}/rc_exec/' /etc/rc.d/autossh

https://www.openbsd.org/faq/upgrade72.html#ConfigChanges
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/rc.d/rc.subr.diff?r1=1.159=1.160=h

Re: How to produce statically linked sshd binary

[Ashlen]

On 23/02/28 16:17, Erling Westenvik wrote:
> Thanks. And I "know"..
>
> Use case: sshd in single user on quasi FDE-encrypted servers on co-location 
> not
> accessible via KVM/AMT. I've done this on many machines since 2014.
>
> I acknowledge that it isn't recommended practice (and definitely not
> supported!) but if anyone should want to help out, feel free to contact me
> off-list!
>
> Best regards
>
> Erling

(Keeping this on-list for the archives so anyone with a similar idea is aware of
the consequences before attempting it. I hope you understand)

I mean this in the kindest way: this sounds a lot like the "XY Problem." From
what I can tell, you're presupposing that X (a statically linked and more
vulnerable sshd) is the most appropriate way to handle Y (accessing single-user
mode on those servers). It tends to be much more helpful to ask directly about
Y. So it's OK, and even preferable, to focus on asking about Y, providing X as
an explanation of what you've tried when prompted for it or if it seems
appropriate to include.

In any case, I can't speak much to how to do X here because I've never dealt
with opening up single-user to remote login. In fact, I'd actually do whatever I
could to find a different way of handling this. I'll explain why briefly.

As you probably already know, single-user gives an exceptional level of control
over system internals that are normally unavailable for security reasons---even
root in multi-user is prohibited from doing these things. Its use is therefore
best reserved for exceptional circumstances.

It also follows that you should log in to single-user mode over a physical
connection rather than a remote one if at all feasible, as an unauthorized party
gaining this level of access is "game over" (this sort of thing is an attacker's
fantasy, to say the least...).

To sum it all up, what you're trying to do is hazardous and likely to end
poorly. That's why it's unsupported.

Re: Suggestion for improving FAQ14: UUIDs

[Ashlen]

On 23/02/06 09:35, Thomas Dettbarn wrote:
> Hello!
>
> tl;dr: I would like to suggest adding a line about the virtues of UUID to the
> FAQ14. Something along the lines of "Remember to set up the UUID in your
> /etc/fstab afterwards." or something.

It does outline this problem here.
https://www.openbsd.org/faq/faq14.html#DUID

OpenBSD creates an fstab(5) using DUIDs during installation if I'm not mistaken.
So in order for this to happen, a user would likely open /etc/fstab in an editor
and see those entries post-install, and then after they notice them they would
have to ignore whatever doubts cropped up and add in a /dev/* entry anyway.

Re: Cannot use Intel Tearfree on Lenovo V15 G2 laptop

[Ashlen]

On 23/02/07 19:57, Digua Dong wrote:
> On Tue, Feb 07, 2023 at 07:09:48PM +1100, Jonathan Gray wrote:
> > 
> > You should be using the default modesetting driver with this hardware.
> > Not opting into an old driver that hasn't had a release in years.
> > 
> I looked at the log with my configure disabled,
> uhh, it is actually not using intel driver.
> 
> (II) modesetting: Driver for Modesetting Kernel Drivers: kms
> (II) modeset(0): [DRI2]   DRI driver: iris
Right, OpenBSD defaults to modesetting(4) unless you specifically tell it to do
otherwise. As jsg said, the modesetting driver is what you should use.

> So the intel driver is no longer developed?
You should avoid intel(4), yes.

> And can I do something to reduce scroll tearing?
If it was anything like my issue, it could be a vsync problem. Desktop
environments will typically take care of this for you (and usually also expose a
setting for it somewhere). Window managers usually don't. I'm guessing that
since you're talking about st that you're using a window manager, but correct me
if I'm wrong.

Anyway, OpenBSD does have a compositor in the base system, xcompmgr(1), but it
doesn't handle vsync. I use spectrwm and I dealt with screen tearing by
installing and configuring picom.

# pkg_add picom

There's a lot you can do with picom, but this is all that should be needed for
now.

$ cat ~/.config/picom/picom.conf
# Resolve screen tearing.
vsync = true;

Go ahead and test picom with that config file interactively first. If it
addresses your issue, you can add `picom -b` to your ~/.xsession. 

Here's a video to test screen tearing.
https://www.youtube.com/watch?v=MfL_JkcEFbE

P.S. When you'd like to learn more about picom, here's how you can do so. I
found the sample config file with `pkg_info -L picom`.
$ man picom
$ less /usr/local/share/examples/picom/picom.sample.conf

Re: Take it easy..

[Ashlen]

On 23/02/06 19:32, Daniele B. wrote:
> Remaning on the simplicity to do stuff.. did you ever try:
> 
> cd /home
> mkdir 5mode-com
> mv * 5mode-com/
> 
> I get:
> 
> rename 5mode-com to 5mode-com/5mode-com: invalid argument

That has to do with sh(1) globbing rules. The shell did exactly what you told it
to and expanded _everything_ in the present working directory. Then it attempted
to move all of that inside "5mode-com". But moving a directory inside of itself
is invalid, so it errored.

This happens on Linux too (demonstrated using termux on Android in this case,
but I guarantee you can reproduce this elsewhere).

~ $ cd $(mktemp -d)
.../tmp/tmp.7WQbdeMg3C $ pwd
/data/data/com.termux/files/usr/tmp/tmp.7WQbdeMg3C
.../tmp/tmp.7WQbdeMg3C $ touch file{1,2,3}
.../tmp/tmp.7WQbdeMg3C $ mkdir dir1
.../tmp/tmp.7WQbdeMg3C $ echo *
dir1 file1 file2 file3
.../tmp/tmp.7WQbdeMg3C $ mv * dir1/
mv: cannot move 'dir1' to a subdirectory of itself, 'dir1/dir1'
.../tmp/tmp.7WQbdeMg3C $ uname
Linux
.../tmp/tmp.7WQbdeMg3C $ echo $SHELL
/data/data/com.termux/files/usr/bin/bash

Re: [patch]: SSL_OP_NO_RENEGOTIATION vs SSL_OP_NO_CLIENT_RENEGOTIATION inconsistency

[Ashlen]

On 23/02/06 02:24, Theo Buehler wrote:
> On Sun, Feb 05, 2023 at 03:59:38PM -0700, Ashlen wrote:
> > (Can CC to tech@ or elsewhere if needed, I didn't know if it belonged here 
> > or
> > there so I'm starting here)
>
> Please do not send patches to misc. Many of us don't have the time and
> nerves to dig through all the noise to see if there's anything worth
> looking at.

Hi Theo. Sorry about that (though thank you for making it clear). Would
libressl@ have been the right place?

> The two options don't do the same thing, so renaming
> SSL_OP_NO_CLIENT_RENEGOTIATION into SSL_OP_NO_RENEGOTIATION or vice
> versa isn't correct.
>
> > I don't know for sure which direction others would prefer to patch in, but 
> > I get
> > the feeling it makes more sense to choose the approach that involves less 
> > future
> > patching (renaming SSL_OP_NO_CLIENT_RENEGOTIATION to 
> > SSL_OP_NO_RENEGOTIATION).
>
> If the two options were equivalent, another option would have been to
> add one compat define to ssl.h:
>
> #define SSL_OP_NO_RENEGOTIATION SSL_OP_NO_CLIENT_RENEGOTIATION
>
> This way no other patching would be needed.

I see. Thank you for all of the other information before this as well. Reading
through it helped me orient a little. I realize now that what I sent was a very
naive patch, and that I really misunderstood what was going on. I underestimated
how much I'd need to know to patch this.

On that note, I should mention that I didn't know any C until after your mail
(and from what I can tell, I still don't know nearly enough). I'm really only
competent in Perl and shell. So in hindsight, I had no business offering a patch
for this and I honestly feel quite embarrassed about it. Everyone makes
mistakes, I guess, but still.

> There are a few things to consider.
>
> 1. Should we add SSL_OP_NO_RENEGOTIATION?
>
> In my opinion your findings suggest that it should be done. It should
> not be hard if you want to take a stab at it.

If I felt confident in my ability to write safe, good quality C in a timely
manner, I'd readily accept this. But my gut instinct tells me that it'll be a
better use of everyone's time for me to properly learn C first and for someone
else to take on this problem.

Sorry, I really wish I could speak of this situation differently. Even if it
turns out to be a trivial fix, I just don't know the fundamentals of C well
enough yet to identify what that would look like. While I know that I'm capable
of learning them, it'll take me a while to work through the rest of K
large part due to other life events that are really vying for my attention.

In any case, I do want to contribute to OpenBSD as it's my favorite OS and I use
it pretty much wherever I can. Once I have a better grasp of C, I'll find a
different way to help.

Re: [patch]: SSL_OP_NO_RENEGOTIATION vs SSL_OP_NO_CLIENT_RENEGOTIATION inconsistency

[Ashlen]

Here's the other way of patching it. I don't like this way as much because it
requires more work in the future (when updating unbound/nsd and ports).

Index: usr.sbin/nsd/nsd-control.c
===
RCS file: /cvs/src/usr.sbin/nsd/nsd-control.c,v
retrieving revision 1.17
diff -u -p -u -p -r1.17 nsd-control.c
--- usr.sbin/nsd/nsd-control.c  30 Jun 2022 10:49:39 -  1.17
+++ usr.sbin/nsd/nsd-control.c  5 Feb 2023 21:55:14 -
@@ -184,11 +184,11 @@ setup_ctx(struct nsd_options* cfg)
 if((SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3) & SSL_OP_NO_SSLv3)
!= SSL_OP_NO_SSLv3)
ssl_err("could not set SSL_OP_NO_SSLv3");
-#if defined(SSL_OP_NO_RENEGOTIATION)
+#if defined(SSL_OP_NO_CLIENT_RENEGOTIATION)
/* disable client renegotiation */
-   if((SSL_CTX_set_options(ctx, SSL_OP_NO_RENEGOTIATION) &
-   SSL_OP_NO_RENEGOTIATION) != SSL_OP_NO_RENEGOTIATION)
-   ssl_err("could not set SSL_OP_NO_RENEGOTIATION");
+   if((SSL_CTX_set_options(ctx, SSL_OP_NO_CLIENT_RENEGOTIATION) &
+   SSL_OP_NO_CLIENT_RENEGOTIATION) != 
SSL_OP_NO_CLIENT_RENEGOTIATION)
+   ssl_err("could not set SSL_OP_NO_CLIENT_RENEGOTIATION");
 #endif
if(!SSL_CTX_use_certificate_file(ctx,c_cert,SSL_FILETYPE_PEM))
ssl_path_err("Error setting up SSL_CTX client cert", c_cert);
Index: usr.sbin/nsd/server.c
===
RCS file: /cvs/src/usr.sbin/nsd/server.c,v
retrieving revision 1.49
diff -u -p -u -p -r1.49 server.c
--- usr.sbin/nsd/server.c   14 Nov 2022 21:09:32 -  1.49
+++ usr.sbin/nsd/server.c   5 Feb 2023 21:55:15 -
@@ -2003,11 +2003,11 @@ server_tls_ctx_setup(char* key, char* pe
return 0;
}
 #endif
-#if defined(SSL_OP_NO_RENEGOTIATION)
+#if defined(SSL_OP_NO_CLIENT_RENEGOTIATION)
/* disable client renegotiation */
-   if((SSL_CTX_set_options(ctx, SSL_OP_NO_RENEGOTIATION) &
-   SSL_OP_NO_RENEGOTIATION) != SSL_OP_NO_RENEGOTIATION) {
-   log_crypto_err("could not set SSL_OP_NO_RENEGOTIATION");
+   if((SSL_CTX_set_options(ctx, SSL_OP_NO_CLIENT_RENEGOTIATION) &
+   SSL_OP_NO_CLIENT_RENEGOTIATION) != 
SSL_OP_NO_CLIENT_RENEGOTIATION) {
+   log_crypto_err("could not set SSL_OP_NO_CLIENT_RENEGOTIATION");
SSL_CTX_free(ctx);
return 0;
}
Index: usr.sbin/unbound/smallapp/unbound-control.c
===
RCS file: /cvs/src/usr.sbin/unbound/smallapp/unbound-control.c,v
retrieving revision 1.25
diff -u -p -u -p -r1.25 unbound-control.c
--- usr.sbin/unbound/smallapp/unbound-control.c 20 Oct 2022 08:26:14 -  
1.25
+++ usr.sbin/unbound/smallapp/unbound-control.c 5 Feb 2023 21:55:15 -
@@ -538,11 +538,11 @@ setup_ctx(struct config_file* cfg)
if((SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3) & SSL_OP_NO_SSLv3)
!= SSL_OP_NO_SSLv3)
ssl_err("could not set SSL_OP_NO_SSLv3");
-#if defined(SSL_OP_NO_RENEGOTIATION)
+#if defined(SSL_OP_NO_CLIENT_RENEGOTIATION)
/* disable client renegotiation */
-   if((SSL_CTX_set_options(ctx, SSL_OP_NO_RENEGOTIATION) &
-   SSL_OP_NO_RENEGOTIATION) != SSL_OP_NO_RENEGOTIATION)
-   ssl_err("could not set SSL_OP_NO_RENEGOTIATION");
+   if((SSL_CTX_set_options(ctx, SSL_OP_NO_CLIENT_RENEGOTIATION) &
+   SSL_OP_NO_CLIENT_RENEGOTIATION) != 
SSL_OP_NO_CLIENT_RENEGOTIATION)
+   ssl_err("could not set SSL_OP_NO_CLIENT_RENEGOTIATION");
 #endif
if(!SSL_CTX_use_certificate_chain_file(ctx,c_cert))
ssl_path_err("Error setting up SSL_CTX client cert", c_cert);
Index: usr.sbin/unbound/util/net_help.c
===
RCS file: /cvs/src/usr.sbin/unbound/util/net_help.c,v
retrieving revision 1.28
diff -u -p -u -p -r1.28 net_help.c
--- usr.sbin/unbound/util/net_help.c20 Oct 2022 08:26:14 -  1.28
+++ usr.sbin/unbound/util/net_help.c5 Feb 2023 21:55:15 -
@@ -989,11 +989,11 @@ listen_sslctx_setup(void* ctxt)
return 0;
}
 #endif
-#if defined(SSL_OP_NO_RENEGOTIATION)
+#if defined(SSL_OP_NO_CLIENT_RENEGOTIATION)
/* disable client renegotiation */
-   if((SSL_CTX_set_options(ctx, SSL_OP_NO_RENEGOTIATION) &
-   SSL_OP_NO_RENEGOTIATION) != SSL_OP_NO_RENEGOTIATION) {
-   log_crypto_err("could not set SSL_OP_NO_RENEGOTIATION");
+   if((SSL_CTX_set_options(ctx, SSL_OP_NO_CLIENT_RENEGOTIATION) &
+   SSL_OP_NO_CLIENT_RENEGOTIATION) != 
SSL_OP_NO_CLIENT_RENEGOTIATION) {
+   log_crypto_err("could not set SSL_OP_NO_CLIENT_RENEGOTIATION");
return 0;
}
 #endif
@@ -1225,11 +1225,11 @@ void* connect_sslctx_create(char* key, c

[patch]: SSL_OP_NO_RENEGOTIATION vs SSL_OP_NO_CLIENT_RENEGOTIATION inconsistency

[Ashlen]

(Can CC to tech@ or elsewhere if needed, I didn't know if it belonged here or
there so I'm starting here)

These files in the source tree are expecting SSL_OP_NO_RENEGOTIATION when only
SSL_OP_NO_CLIENT_RENEGOTIATION is defined in lib/libssl/ssl.h. 

$ grep -Rl 'SSL_OP_NO_RENEGOTIATION'
usr.sbin/unbound/util/net_help.c
usr.sbin/unbound/smallapp/unbound-control.c
usr.sbin/nsd/server.c
usr.sbin/nsd/nsd-control.c
sbin/unwind/libunbound/util/net_help.c

$ grep -Rl 'SSL_OP_NO_CLIENT_RENEGOTIATION'
lib/libssl/ssl_pkt.c
lib/libssl/ssl.h
lib/libssl/d1_pkt.c
lib/libtls/tls_server.c

Is this intentional? 

I should note that OpenSSL uses SSL_OP_NO_RENEGOTIATION. At least two ports I've
seen expect this and fail to disable client renegotiation as a result. 

I don't know for sure which direction others would prefer to patch in, but I get
the feeling it makes more sense to choose the approach that involves less future
patching (renaming SSL_OP_NO_CLIENT_RENEGOTIATION to SSL_OP_NO_RENEGOTIATION). 

I'll include both methods of patching, one in this mail and one in my reply to
it.

(Also, should lib/libssl/man/SSL_CTX_set_options.3 also get patched? Unsure what
to write there if so, as it depends on which solution makes more sense)

Index: lib/libssl/ssl_pkt.c
===
RCS file: /cvs/src/lib/libssl/ssl_pkt.c,v
retrieving revision 1.65
diff -u -p -u -p -r1.65 ssl_pkt.c
--- lib/libssl/ssl_pkt.c26 Nov 2022 16:08:56 -  1.65
+++ lib/libssl/ssl_pkt.c5 Feb 2023 22:49:15 -
@@ -958,7 +958,7 @@ ssl3_read_handshake_unexpected(SSL *s)
return -1;
}
 
-   if ((s->options & SSL_OP_NO_CLIENT_RENEGOTIATION) != 0) {
+   if ((s->options & SSL_OP_NO_RENEGOTIATION) != 0) {
ssl3_send_alert(s, SSL3_AL_FATAL,
SSL_AD_NO_RENEGOTIATION);
return -1;
Index: lib/libssl/ssl.h
===
RCS file: /cvs/src/lib/libssl/ssl.h,v
retrieving revision 1.230
diff -u -p -u -p -r1.230 ssl.h
--- lib/libssl/ssl.h26 Dec 2022 07:31:44 -  1.230
+++ lib/libssl/ssl.h5 Feb 2023 22:49:16 -
@@ -402,7 +402,7 @@ typedef int (*tls_session_secret_cb_fn)(
 /* As server, disallow session resumption on renegotiation */
 #define SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION  0x0001L
 /* Disallow client initiated renegotiation. */
-#define SSL_OP_NO_CLIENT_RENEGOTIATION 0x0002L
+#define SSL_OP_NO_RENEGOTIATION0x0002L
 /* If set, always create a new key when using tmp_dh parameters */
 #define SSL_OP_SINGLE_DH_USE   0x0010L
 /* Set on servers to choose the cipher according to the server's
Index: lib/libssl/d1_pkt.c
===
RCS file: /cvs/src/lib/libssl/d1_pkt.c,v
retrieving revision 1.127
diff -u -p -u -p -r1.127 d1_pkt.c
--- lib/libssl/d1_pkt.c 26 Nov 2022 16:08:55 -  1.127
+++ lib/libssl/d1_pkt.c 5 Feb 2023 22:49:16 -
@@ -644,7 +644,7 @@ dtls1_read_handshake_unexpected(SSL *s)
return -1;
}
 
-   if ((s->options & SSL_OP_NO_CLIENT_RENEGOTIATION) != 0) {
+   if ((s->options & SSL_OP_NO_RENEGOTIATION) != 0) {
ssl3_send_alert(s, SSL3_AL_FATAL,
SSL_AD_NO_RENEGOTIATION);
return -1;
Index: lib/libtls/tls_server.c
===
RCS file: /cvs/src/lib/libtls/tls_server.c,v
retrieving revision 1.48
diff -u -p -u -p -r1.48 tls_server.c
--- lib/libtls/tls_server.c 19 Jan 2022 11:10:55 -  1.48
+++ lib/libtls/tls_server.c 5 Feb 2023 22:49:16 -
@@ -231,7 +231,7 @@ tls_configure_server_ssl(struct tls *ctx
goto err;
}
 
-   SSL_CTX_set_options(*ssl_ctx, SSL_OP_NO_CLIENT_RENEGOTIATION);
+   SSL_CTX_set_options(*ssl_ctx, SSL_OP_NO_RENEGOTIATION);
 
if (SSL_CTX_set_tlsext_servername_callback(*ssl_ctx,
tls_servername_cb) != 1) {

Re: httpd(8) request rewrite - 500 internal server error

[Ashlen]

Oh. I should add that if all you want is a static redirect, this is a simpler
way of making that work. The first example I gave is in case you want to
redirect the contents of "/from/" as well.

server "localhost" {
listen on 127.0.0.1 port 80
location "/from/" {
block return 302 "$REQUEST_SCHEME://$HTTP_HOST/to/"
}
}

-- 
https://www.anthes.is/

Re: httpd(8) request rewrite - 500 internal server error

[Ashlen]

On 23/01/25 11:20, Lévai, Dániel wrote:
> Hi all,
> 
> I was trying to do a basic path rewrite in httpd(8) on 7.2-stable, and I just 
> can't see what I'm missing:
> 
> httpd.conf:
> server "host" {
> listen on egress port 12345
> 
> root "/htdocs"
> 
> location "/" {
> request rewrite "/to/"
> }
> location "/*" {
> directory auto index
> }
> }
> 
> 
> Using http://host:12345/ slaps me with 500:
> 
> server_response: rewrote /? -> /to/?
> "GET / HTTP/1.1" 500 0
> , /to/ (500 Internal Server Error)
> 
> 
> Accessing http://host:12345/to/ directly works, however:
> 
> "GET /to/ HTTP/1.1" 200 538
> "GET /favicon.ico HTTP/1.1" 404 0
> , /favicon.ico (404 Not Found)
> 
> 
> I though maybe it was iffy because of the location containing only a slash 
> (/), but using anything else like...:
> location "/from/" {
> request rewrite "/to/"
> }
> 
> ... gives 500 too when accessing http://host:12345/from/
> Tried playing around with (adding/removing) the trailing '/' from the paths, 
> but still no luck. I even tried the example at the end of httpd.conf(5) with 
> "location match" and pattern/captures, but still the same.
> 
> But "request rewrite" must be clearly working somehow, I just can't see 
> what's missing.
> 
> Any tips would be greatly appreciated!
> 
> 
> Daniel
> 

If you're curious about the lower level details behind my explanation,
/usr/src/usr.sbin/httpd/server_file.c and /usr/src/usr.sbin/httpd/server_http.c
are enlightening here (though I might add that I don't actually know C; I pieced
this together by reading httpd(8) and httpd.conf(5), and using my more general
programming knowledge to infer some things).

The first thing I have to say is this: what reason is there for using "request
rewrite" over "block return"? httpd has distinct behavior for both, and that
means certain things may work differently from how you expect them to.

When using "request rewrite", that path is exact, and a final authority in a
sense. httpd is trusting that you know precisely where you're sending the
client. That means it's going to interpret what you tell it very literally,
since modifying a rewritten request carries more risk, and perform a file access
test. If httpd doesn't like the results of that test because the place you
pointed it to is actually a directory, it'll throw a 500 Internal Server Error.
This is one rewritten request, followed by one response.

When using "block return" with a destination URI, httpd does more than this. It
will immediately close the connection and send an error page along with an HTTP
Location header. This is the first request, followed by the first response. Then
the client may honor the Location header in the response and follow the
redirection. This is the second request, soon followed by a second response. 

Due to differences in the way that "block return" operates, one thing httpd can
do is append the "directory index file" to the location or path if there's a
trailing slash ("index.html" is the default, so "/to/" would result in
"/to/index.html" for instance). It can also do directory auto indexing.

All of this is to say that if you don't have a specific reason to use "request
rewrite" instead of "block return", let a redirection handle it by using "block
return" with either a 301 Moved Permanently or a 302 Found. If you don't know
the difference, use a 302 Found for now.

Something like this could work depending on what you want to do (change the
server and listen statements to reflect your setup. If you need auto-indexing,
add it back in).

server "localhost" {
listen on 127.0.0.1 port 80
location match "/from/(.*)" {
block return 302 "$REQUEST_SCHEME://$HTTP_HOST/to/%1"
}
}

Note that the default root is "/htdocs", so if that's where you want your stuff
to be, you can leave that out. I prefer to create a separate directory since
/var/www/htdocs/bgplg exists by default, but that's just me.

-- 
https://www.anthes.is/

Re: Question about pf.conf queues

[Ashlen]

> > It occurs to me that in my originally proposed configuration, I am not
> > limiting the traffic with the two priorities to TCP traffic.  This is
> > necessary as this optimization applies only to TCP traffic and I should note
> > that in Peter Hansteen's book he also does this.
> 
> Good that you noticed that, but it's unnecessary. pf is smart enough to know
> what traffic to apply it to. It's good to compare the output of pfctl(8) to 
> know
> exactly what's changing and how things are getting parsed (`pfctl -s rules`,
> `pfctl -nvf /etc/pf.conf`).

I should clarify: without changing it to `proto tcp` like you did, it may indeed
make a (small) difference because it could match UDP packets with a TOS of
lowdelay as well. For me this is fine, as I'm comfortable with those UDP packets
getting prioritized in addition to the TCP packets that match the rule. 

I didn't like the way I wrote it because it almost implies that they do the same
thing and there's a difference.

-- 
https://www.anthes.is/

Re: Question about pf.conf queues

[Ashlen]

Forgive me for the long mail. I went out of my way to be thorough because I see
mails like this on misc@ fairly often. I had the same kinds of questions when I
set up my OpenBSD router years ago so I can empathize.

> My question are:
> 
> 1. For better utilization of TCP traffic I have two priorities assigned to
> the queue.  Do I require more than one sub queue for this to work ? I
> don't intend to subdivide my traffic up (i.e. a SSH queue, and HTTP/S
> queue, etc.), I just want all my TCP traffic to benefit from better
> utilization with the two priorities.

No, and actually I'm pretty sure you can go without the sub queues entirely.
Just one queue is enough and will work the way you want it to.

> 2. If this configuration is currently correct, are they any other changes
> I should make for better queuing (ie: better bandwidth utilization) ?

I'll talk more about your queueing rule in a moment. 

> 3. Given the importance of time keeping, would it be a good idea to have
> another queue for NTP traffic and use the highest priority of 7 for it ?

I doubt it would harm anything, but it's probably unnecessary. In general,
OpenBSD does the sensible thing. Sometimes improvements can be made through
configuration, but it's usually best to clearly define and lay out the problem
before deciding on a solution. When tweaking something, have a good
understanding of what you're changing and why.

Now I'll get more into your configuration.

> queue rootq on $ext_if bandwidth 55M max 55M
> queue dataq parent rootq bandwidth 55M max 55M flows 1024 \
> qlimit 1024 default

As I understand it, that queue statement should be based on upload speed, not
download speed. You can shape the traffic others send to you by controlling what
you send to them. The nature of TCP congestion control (TCP slow start and
friends) is why this approach works.

It's like a telephone conversation---if the other person is talking (sending
data) and you're silent for a long time (no acknowledgements/ACKs), the other
person will ask if you're still there and wait for a response. So upload speed
is the relevant metric because it's your response that you have control over. 

I can't take credit for the telephone analogy, it's from Solene's blog post on
the subject[1]. Though I view her configuration itself as a bit of a special
case. I've experimented with configurations that complex, and these days I
mostly stick to the simple one rule configuration mentioned in pf.conf(5) under
QUEUEING.

> match out on $ext_if inet proto tcp set queue dataq set prio (5, 6) \
> tag INTERNET

I'm aware of the priorities trick you're using[2] and I'd guess that the effect
on top of FQ-CoDel + HFSC isn't a lot. But without proper testing, I don't know.
Anyway, assigning to a queue and tagging are unnecessary here. The default queue
will apply if the packets aren't assigned elsewhere. If the tagging is to make
the rule's function clearer to you, then I'd just comment it instead. 

Also, it's perhaps a bit paranoid but I'd change two things. I'd add 'prio 3' to
guard against accidentally overriding nondefault priority values, and I'd change
the priority values to '(3, 4)'. The first change is so that it only matches
normal priority packets and leaves everything else alone. The second change is
so that outbound traffic remains at the default priority and therefore still
shares an equal priority with inbound traffic (except for the dataless ACKs and
packets with a TOS of lowdelay).

As for mixing priorities and bandwidth shaping, I've felt unsure about how
exactly they interact for quite a while now. I decided to put that doubt of mine
to rest once and for all today, and this is what I could find. It seems that it
used to be the case that they couldn't be used together, back in the days of
ALTQ[3]. But there's evidence to suggest that they can be used together
now[4][5]. I tested it and confirmed as much.

> It occurs to me that in my originally proposed configuration, I am not
> limiting the traffic with the two priorities to TCP traffic.  This is
> necessary as this optimization applies only to TCP traffic and I should note
> that in Peter Hansteen's book he also does this.

Good that you noticed that, but it's unnecessary. pf is smart enough to know
what traffic to apply it to. It's good to compare the output of pfctl(8) to know
exactly what's changing and how things are getting parsed (`pfctl -s rules`,
`pfctl -nvf /etc/pf.conf`).

> Does anyone have any feedback or pointers on this updated configuration ?

My main suggestion is to test the modifications you're making to get objective
results. This is both to build confidence and to make sure that you aren't
accidentally screwing up your connection somehow. Usually the reason you'd
change things like this is to avoid bufferbloat[6]. I like to use Flent[7] to
test bufferbloat, but you're welcome to use web tools as well[8]. Run the test
without the queues/priorities first to figure out what the 

Re: sndio and bit perfect playback

[Ashlen]

On 23/01/13 12:42, Jan Stary wrote:
> On Jan 09 13:10:09, euryd...@riseup.net wrote:
> > I was able to distinguish between samples created by
> > audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 
> > Carbon
> > with HiFiMan Sundara headphones plugged in. To describe the circumstances +
> > outcome briefly: 9 out of 10 correct in 10 trials
> 
> http://stare.cz/.tmp/resample/
> Which is which?

That's not how AB/X tests work, but it also doesn't matter because they're all
the same file.

$ for num in $(seq -w 1 10); do ftp http://stare.cz/.tmp/resample/$num.wav > 
/dev/null 2>&1; done

$ for num in $(seq -w 1 10); do sha256 ./$num.wav; done
SHA256 (./01.wav) = 
772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099
SHA256 (./02.wav) = 
772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099
SHA256 (./03.wav) = 
772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099
SHA256 (./04.wav) = 
772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099
SHA256 (./05.wav) = 
772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099
SHA256 (./06.wav) = 
772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099
SHA256 (./07.wav) = 
772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099
SHA256 (./08.wav) = 
772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099
SHA256 (./09.wav) = 
772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099
SHA256 (./10.wav) = 
772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099

https://en.wikipedia.org/wiki/ABX_test

Re: sndio and bit perfect playback

[Ashlen]

On 23/01/10 09:36, Alexandre Ratchov wrote:
> On Mon, Jan 09, 2023 at 01:10:09PM -0700, Ashlen wrote:
> > 
> > Although I need to finalize the Perl script I was using to do this (life 
> > gets
> > busy), in practice I was able to distinguish between samples created by
> > audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 
> > Carbon
> > with HiFiMan Sundara headphones plugged in. To describe the circumstances +
> > outcome briefly: 9 out of 10 correct in 10 trials; randomly sampling from an
> > array containing the givens A and B to get an unknown X; comparing 15 
> > seconds of
> > audio; audio/sox as the playback software. In the future, I would do >=16
> > trials, and perhaps conduct the tests from my desktop instead since it has a
> > discrete amp and DAC.
> > 
> > In offline resampling from 48kHz to 44.1kHz, the highs were most affected 
> > and
> > that's what I was able to use to distinguish between samples. The 
> > percussion,
> > especially the cymbals, sounded different in particular because the clip
> > resampled by aucat had cymbal crashes that seemed to 'shimmer' much less 
> > (the
> > decay was more rapid). The spectrograms seemed to confirm that the highs 
> > were
> > most affected. 
> > 
> > Whether that means "low quality resampling" or merely that the results of 
> > the
> > two commands can be differentiated is something I'm uncertain of. Either 
> > way, I
> > don't know enough about C or sndio internals to be useful in that domain 
> > yet. As
> > an aside, I did find this to be a useful resource for learning about digital
> > audio resampling, and they recommend audio/sox there.
> > 
> > https://ccrma.stanford.edu/~jos/resample/
> > 
> > I hadn't said anything about this earlier because I wanted to take the time 
> > to
> > finish + document the script, reproduce my results with a royalty free 
> > sample at
> > a greater trial count, and then post. Given that I haven't done so yet, I 
> > can at
> > least post the commands used to resample the audio for those that are
> > interested.
> > 
> > 
> > # This was originally an opus file downloaded with www/yt-dlp.
> > # Converting to WAV so both SoX and aucat can work with it.
> > $ opusdec input.{opus,wav}
> > 
> > # Resample 16-bit 48kHz WAV file to 44.1kHz using both SoX and aucat(1).
> > #
> > # If I recall correctly, I converted to FLAC here because the WAV headers
> > # generated by aucat and SoX differed, and so SoX would refuse to play WAV 
> > files
> > # created by aucat.
> > $ sox -G input.wav -t wav - rate -v 44100 | flac - -o output-sox.flac
> > $ aucat -i input.wav -h wav -r 44100 -e s16 -o - | flac - -o 
> > output-aucat.flac
> > 
> > # Generate spectrograms for later inspection/comparison.
> > $ sox output-sox.flac -n spectrogram -o spectrogram-sox.png
> > $ sox output-aucat.flac -n spectrogram -o spectrogram-aucat.png
> > 
> 
> Thank you for all the details. Do you mind sharing the youtube link
> (or the input.wav file) so I can experiment with the same file and
> examine the data

I don't mind. :) I provided the way I downloaded it in the last reply, although
I'll add the link here as well for convenience.

https://www.youtube.com/watch?v=ei8hPkyJ0bU

> > I'd certainly be interested in the ability to play audio in a way that 
> > avoids
> > resampling altogether, similar to what a user can do on FreeBSD with the
> > following sysctl tweaks:
> > 
> > # sysctl hw.snd.maxautovchans=0 dev.pcm.0.bitperfect=1
> > 
> 
> This is equivalent to bypassing sndiod. The OpenBSD equivalent is as
> follows:
> 
> chown  /dev/audio*
> rcctl stop sndiod

Interesting, I'll try that later to see how it works. I suppose this does give
up the advantage of a privilege separated audio daemon, however, and the
ownership modification means that a regular user can change things they
otherwise couldn't [ mixerctl(8), audioctl(8) ]. Hard to have that cake and eat
it too. Though it does leave me feeling impressed with the way OpenBSD's sound
infrastructure is designed. Lots of other systems would ship with a regular user
having raw access to the device itself, and it's a plus in my book that OpenBSD
doesn't (instead it's _sndiop).

> Note that bit-perfect audio and avoiding resampling are not the same
> thing. The latter is more complicated but it would keep current
> features working (mixing, routing, device switching) by making sndiod
> dynamically set device sample rates to match the sample rate of a
> particular client (for instance an audi

Re: sndio and bit perfect playback

[Ashlen]

On 23/01/09 22:16, Jan Stary wrote:
> On Jan 09 13:10:09, euryd...@riseup.net wrote:
> > 
> > Although I need to finalize the Perl script I was using to do this (life 
> > gets
> > busy), in practice I was able to distinguish between samples created by
> > audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 
> > Carbon
> > with HiFiMan Sundara headphones plugged in. To describe the circumstances +
> > outcome briefly: 9 out of 10 correct in 10 trials; randomly sampling from an
> > array containing the givens A and B to get an unknown X; comparing 15 
> > seconds of
> > audio; audio/sox as the playback software. In the future, I would do >=16
> > trials, and perhaps conduct the tests from my desktop instead since it has a
> > discrete amp and DAC.
> > 
> > In offline resampling from 48kHz to 44.1kHz, the highs were most affected 
> > and
> > that's what I was able to use to distinguish between samples. The 
> > percussion,
> > especially the cymbals, sounded different in particular because the clip
> > resampled by aucat had cymbal crashes that seemed to 'shimmer' much less 
> > (the
> > decay was more rapid). The spectrograms seemed to confirm that the highs 
> > were
> > most affected. 
> > 
> > Whether that means "low quality resampling" or merely that the results of 
> > the
> > two commands can be differentiated is something I'm uncertain of. Either 
> > way, I
> > don't know enough about C or sndio internals to be useful in that domain 
> > yet. As
> > an aside, I did find this to be a useful resource for learning about digital
> > audio resampling, and they recommend audio/sox there.
> > 
> > https://ccrma.stanford.edu/~jos/resample/
> > 
> > I hadn't said anything about this earlier because I wanted to take the time 
> > to
> > finish + document the script, reproduce my results with a royalty free 
> > sample at
> > a greater trial count, and then post. Given that I haven't done so yet, I 
> > can at
> > least post the commands used to resample the audio for those that are
> > interested.
> > 
> > 
> > # This was originally an opus file downloaded with www/yt-dlp.
> > # Converting to WAV so both SoX and aucat can work with it.
> > $ opusdec input.{opus,wav}
> 
> Can you please point to the specific opus file,
> so that I can reproduce exactly what you have done?

Sure. It was the first fifteen seconds in particular I compared against. The
song is a guilty pleasure from my adolescent years that I felt like indulging
that day, though, so please don't judge too much. :p Anyway, I used '--simulate'
here, but of course you'd remove it to actually download the file. Note the
format number if it feels important to check what exactly is being downloaded.

$ yt-dlp -xf bestaudio/best --simulate 
'https://www.youtube.com/watch?v=ei8hPkyJ0bU'
[youtube] ei8hPkyJ0bU: Downloading webpage
[youtube] ei8hPkyJ0bU: Downloading android player API JSON
[SponsorBlock] Fetching SponsorBlock segments
[SponsorBlock] Found 1 segments in the SponsorBlock database
[info] ei8hPkyJ0bU: Downloading 1 format(s): 251

In case you're interested in my ~/.config/yt-dlp/config contents as well:

$ cat ~/.config/yt-dlp/config
--audio-quality 0
--embed-metadata
--embed-subs
--embed-thumbnail
--format 'bestvideo*[height<=?1080][width<=?1920]+bestaudio/best'
--output "${HOME}/Downloads/%(uploader)s/%(title)s.%(ext)s"
--sponsorblock-mark default
--sub-langs en,en-orig,-live_chat
--write-description
--write-info-json

> > # Resample 16-bit 48kHz WAV file to 44.1kHz using both SoX and aucat(1).
> > #
> > # If I recall correctly, I converted to FLAC here because the WAV headers
> > # generated by aucat and SoX differed, and so SoX would refuse to play WAV 
> > files
> > # created by aucat.
> 
> That would be a bug in itself.
> How exactly does SoX refuse to play the WAVs created by aucat?

Unsure what the error itself means, but I'll share it. Also, I forgot to add
`-n` to aucat(1) in my previous mail, which is necessary to resample the file
without playback. Oops.

$ aucat -n -i input.wav -h wav -r 44100 -e s16 -o output.wav
$ play output.wav
play FAIL formats: can't open input file `output.wav': WAVE header error: 
cbSize inconsistent with fmt size

> > $ sox -G input.wav -t wav - rate -v 44100 | flac - -o output-sox.flac
> > $ aucat -i input.wav -h wav -r 44100 -e s16 -o - | flac - -o 
> > output-aucat.flac
> 
> sox dithers by default; can you try with sox -D
> to see of the results are more similar?

I'll add testing against a sample with `sox -D` to my TODOs. Life's been getting
pretty busy, sadly. :( But I'd be happy to test when I get the time. Would be
good to drop `-G` from the sox invocation now that I think about it. I do
usually use it when resampling things offline, but it's an unneeded additional
variable that could make isolating things in testing more difficult.

> > # Generate spectrograms for later inspection/comparison.
> > $ sox output-sox.flac -n spectrogram -o spectrogram-sox.png
> > $ sox 

Re: sndio and bit perfect playback

[Ashlen]

On 23/01/09 06:22, Alexandre Ratchov wrote:
> On Sun, Jan 08, 2023 at 10:56:31PM +0100, Jan Stary wrote:
> > On Oct 16 08:18:17, a...@caoua.org wrote:
> > > On Sat, Oct 15, 2022 at 10:03:52PM +0200, Åke Nordin wrote:
> > > > On 10/14/22 11:21, Alexandre Ratchov wrote:
> > > > > Here are the measures of the aliasing noise using sine sweeps. Check
> > > > > the figure for the 44.1kHz to 48kH conversion, the sndiod column:
> > > > > 
> > > > > https://arverb.com/pub/src/
> > 
> > 
> > aucat(1) currently says
> > 
> > BUGS
> >  Resampling is low quality.
> > 
> > Is this still considered to be the case?
> > 
> 
> IMO, it doesn't deserve the BUGS section anymore, I'll remove this
> sentence. Objections?

Not necessarily an objection, but I've been watching this thread silently since
it started and wanted to voice some of my thoughts. 

Although I need to finalize the Perl script I was using to do this (life gets
busy), in practice I was able to distinguish between samples created by
audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 Carbon
with HiFiMan Sundara headphones plugged in. To describe the circumstances +
outcome briefly: 9 out of 10 correct in 10 trials; randomly sampling from an
array containing the givens A and B to get an unknown X; comparing 15 seconds of
audio; audio/sox as the playback software. In the future, I would do >=16
trials, and perhaps conduct the tests from my desktop instead since it has a
discrete amp and DAC.

In offline resampling from 48kHz to 44.1kHz, the highs were most affected and
that's what I was able to use to distinguish between samples. The percussion,
especially the cymbals, sounded different in particular because the clip
resampled by aucat had cymbal crashes that seemed to 'shimmer' much less (the
decay was more rapid). The spectrograms seemed to confirm that the highs were
most affected. 

Whether that means "low quality resampling" or merely that the results of the
two commands can be differentiated is something I'm uncertain of. Either way, I
don't know enough about C or sndio internals to be useful in that domain yet. As
an aside, I did find this to be a useful resource for learning about digital
audio resampling, and they recommend audio/sox there.

https://ccrma.stanford.edu/~jos/resample/

I hadn't said anything about this earlier because I wanted to take the time to
finish + document the script, reproduce my results with a royalty free sample at
a greater trial count, and then post. Given that I haven't done so yet, I can at
least post the commands used to resample the audio for those that are
interested.


# This was originally an opus file downloaded with www/yt-dlp.
# Converting to WAV so both SoX and aucat can work with it.
$ opusdec input.{opus,wav}

# Resample 16-bit 48kHz WAV file to 44.1kHz using both SoX and aucat(1).
#
# If I recall correctly, I converted to FLAC here because the WAV headers
# generated by aucat and SoX differed, and so SoX would refuse to play WAV files
# created by aucat.
$ sox -G input.wav -t wav - rate -v 44100 | flac - -o output-sox.flac
$ aucat -i input.wav -h wav -r 44100 -e s16 -o - | flac - -o output-aucat.flac

# Generate spectrograms for later inspection/comparison.
$ sox output-sox.flac -n spectrogram -o spectrogram-sox.png
$ sox output-aucat.flac -n spectrogram -o spectrogram-aucat.png


I'd certainly be interested in the ability to play audio in a way that avoids
resampling altogether, similar to what a user can do on FreeBSD with the
following sysctl tweaks:

# sysctl hw.snd.maxautovchans=0 dev.pcm.0.bitperfect=1

https://www.freebsd.org/cgi/man.cgi?query=sound=FreeBSD+13.1-RELEASE=html

That said, I understand that someone would have to write the code for that, and
right now I lack the know-how so my expectations are nil. 

To end this mail, here are some relevant command outputs (note that these
weren't gathered at the time of testing, they're to show what the system
generally looks like):

# mixerctl -av
inputs.dac-2:3=94,94
inputs.dac-0:1=94,94
record.adc-0:1_mute=off  [ off on ]
record.adc-0:1=124,124
record.adc-2:3_mute=off  [ off on ]
record.adc-2:3=124,124
outputs.spkr_source=dac-2:3  [ dac-2:3 ]
outputs.spkr_mute=off  [ off on ]
outputs.spkr_eapd=on  [ off on ]
outputs.spkr2_source=dac-0:1  [ dac-2:3 dac-0:1 ]
outputs.spkr2_mute=off  [ off on ]
outputs.spkr2_boost=off  [ off on ]
inputs.mic=85,85
outputs.mic_dir=input-vr80  [ none input input-vr0 input-vr50 input-vr80 
input-vr100 ]
outputs.hp_source=dac-0:1  [ dac-2:3 dac-0:1 ]
outputs.hp_mute=off  [ off on ]
outputs.hp_boost=off  [ off on ]
outputs.hp_eapd=on  [ off on ]
record.adc-2:3_source=mic  { mic }
record.adc-0:1_source=mic  { mic }
outputs.mic_sense=unplugged  [ unplugged plugged ]
outputs.hp_sense=unplugged  [ unplugged plugged ]
outputs.spkr_muters=hp  { hp }
outputs.master=95,95
outputs.master.mute=off  [ off on ]
outputs.master.slaves=dac-2:3,dac-0:1,spkr,spkr2,hp  { dac-2:3 dac-0:1 spkr 
spkr2 hp }

Question about RFC9235 and TLS_CIPHERS_DEFAULT in tls_internal.h

[Ashlen]

Hi misc. I was reading RFC9325[1] (released November of 2022), and noticed this
under section 4.1 (General Guidelines, under Recommendations: Cipher Suites):

   *  Implementations MUST support and prefer to negotiate cipher suites
  offering forward secrecy.  However, TLS 1.2 implementations SHOULD
  NOT negotiate cipher suites based on ephemeral finite-field
  Diffie-Hellman key agreement (i.e., "TLS_DHE_*" suites).  This is
  justified by the known fragility of the construction (see
  [RACCOON]) and the limitation around negotiation, including using
  [RFC7919], which has seen very limited uptake.

Yet in lib/libtls/tls_internal.h, I see this section. 

#define TLS_CIPHERS_DEFAULT "TLSv1.3:TLSv1.2+AEAD+ECDHE:TLSv1.2+AEAD+DHE"
#define TLS_CIPHERS_COMPAT  "HIGH:!aNULL"
#define TLS_CIPHERS_LEGACY  "HIGH:MEDIUM:!aNULL"
#define TLS_CIPHERS_ALL "ALL:!aNULL:!eNULL"

I forget what exactly led me to find it. I think I might've been trying to
figure out what the relationship between SSL_CTX_set_cipher_list(3) and
tls_config_set_ciphers(3) was, because I didn't know what setting ciphers to
"default" or "secure" in httpd.conf(5) or relayd.conf(5) actually did. Finding
this made that a lot more clear.

Anyway, I'm mailing because I wanted to ask this: why does OpenBSD includes DHE
cipher suites in TLS_CIPHERS_DEFAULT? Is it at all related to
tls_config_set_dheparams(3) being set to none by default? 

I'm not the most educated about TLS and cryptography, so I felt I should ask
before jumping to any conclusions. There may be a valid reason for all I
know---it's a question based on an observation rather than a criticism.

[1]: https://www.rfc-editor.org/info/rfc9325

Re: Securely managing TLS certificates on growing server (website, XMPP, soon email)?

[Ashlen]

Thank you, this resolves that concern of mine (and in fact, it was an elegant
enough solution that I felt silly for not doing it that way before). :) It makes
a lot more sense to have acme-client(1) place the exceptional certificates in a
different spot, rather than modify `/etc/ssl/private` to make everything work in
one location.

On 22/12/16 11:16, Omar Polo wrote:
> Can only speak for prosody as it's the only non-base daemon I'm
> getting TLS certificates for; my strategy with it has been to generate
> a different certificate and to deliver it in a place where only
> prosody can read it.  Luckily, the prosody package installs
> /etc/prosody/certs owned by _prosody alone.
>
>   # /etc/acme-client.conf
>   domain xmpp {
>   domain name example.com
>   alternative names { room.example.com upload.example.com }
>   domain key "/etc/prosody/certs/example.com.key"
>   domain full chain certificate 
> "/etc/prosody/certs/example.net.crt"
>   sign with letsencrypt
>   }
>
> note the `domain' name is "xmpp" because I have another `domain' block
> for the same domain (but different alt names) for httpd:
>
>   # only for httpd
>   domain example.com {
>   alternative names { www.example.com }
>   ...
>   }
>
> all handled by cron as usual:
>
>   ~ * * * * acme-client example.com && rcctl reload httpd
>   ~ * * * * acme-client xmpp && rcctl restart prosody
>
> in prosody.conf.lua i have
>
>   certificates = "certs"
>
> I also have some symlinks in /etc/prosody/certs in the form:
>
>   {room,upload}.example.com.crt -> example.com.crt
>   {room,upload}.example.com.key -> example.com.key
>
> so that prosody can look up the certs by itself without extra
> configuration.  Can probably do it without the symlinks, but I was
> lazy and this worked for me.
>
> HTH

Securely managing TLS certificates on growing server (website, XMPP, soon email)?

[Ashlen]

Hi all, so I'm wondering how to securely deal with TLS certificates on a server
that's grown to host multiple services (website, XMPP, soon email as well).
Specifically how to handle permissions and to what degree certificates should be
separated.

(I recognize this is a long email. I'm unsure how to break down my thoughts
further)

I know that I could add a load of Subject Alternative Names to one big
certificate, but I have a couple of concerns with this.

1) If I understand it right, if there's a security issue with one program and an
attacker gains arbitrary read, and the effective user id can read the private
key, the exposure is greater than it has to be (that is to say, domains that are
completely unrelated to the insecure program are exposed). Daemons outside of
base unfortunately often lack privilege separation to the extent that it exists
in base, so there may not be a separate user to handle private keys, and then
the whole thing has the potential to blow up later.

2) A long list of Subject Alternative Names means that anyone connecting to the
web server can see all of the additional subdomains that are unrelated to the
web server being hosted. This is really a nitpick compared to the first point,
as even without this being the case there are other methods of enumeration and
discovery (nmap and friends), and relying on DNS entries being hidden seems like
a bad idea.

The best way I can think of how to handle this so far, and "best" is used very
loosely since I don't think it's a perfect solution, is to split the keys up,
add a separate group, and modify `/etc/ssl/private`.

```
# groupadd tls
# usermod -G tls _prosody
# chown root:tls /etc/ssl/private
# chmod 750 /etc/ssl/private
```

Then the private keys within would all have 0400 permissions, user and group
being the same (so _prosody:_prosody for XMPP-related TLS). I noted that the
default is 700 permissions on `/etc/ssl/private` with root:wheel ownership. Is
the approach I've just outlined with adding a group and modifying permissions a
bad idea?

Even if it makes sense to do it this way, I still have a separate issue in that
when two or more services need the certificate for the root domain, they'll end
up sharing it, and I'm unclear what the right way to fix that problem is. If
it's only services in the base system, that's one thing. But Prosody also has
this issue with the way I set it up. Currently it's configured so that usernames
can be in the form "u...@example.com" rather than "u...@xmpp.example.com"
(similar to how email usernames use the root domain). This means it needs the
certificate for the root domain so that authentication can take place over TLS,
and that breaks the separation.

For some services, it can make sense to use relayd(8) and let that handle TLS
instead, which simplifies things since relayd has proper privilege separation
and can even use SNI. But I'm unsure how this could be done with something like
Prosody since XMPP uses STARTTLS (outside of exceptions to that rule like
XEP-0368).

What can I do to manage this better? Any ideas/suggestions are very welcome.
Thank you for reading all of this if you made it here.

Re: horizontal screen tearing with mpv, modesetting(4), and compositor

[Ashlen]

On 22/04/06 15:39, Ashlen wrote:
> There are open issues about things that appear to be similar, and in
> those others corroborate that it seems to be something with the
> modesetting driver:
>
> https://github.com/mpv-player/mpv/issues/7106
> https://gitlab.freedesktop.org/xorg/xserver/-/issues/928

On a second review of these issues, these are not dealing with the same
problem. Somehow I overlooked this, sorry about that.

Considering my email again, it may be more appropriate to try bringing
it up in the relevant issue tracker, rather than an email to misc@. But
hopefully the workaround helps for anyone that encounters the same
issue.

--
https://amissing.link/

horizontal screen tearing with mpv, modesetting(4), and compositor

[Ashlen]

Hey all, I'm encountering an issue where when I play videos with mpv
while a compositor is running under modesetting(4), horizontal screen
tearing will occur during playback. I've tested this on xmonad, cwm,
and fvwm.

As for why I'm using a compositor, it's for semi-transparency in the
terminal emulator I'm using (urxvt). I like being able to see the
wallpaper in the background while writing programs or using the shell.

I played with some of the flags mentioned in xcompmgr(1) including `-a`,
`-c`, `-s`, and `-S`, but none make a difference. I should note that
picom with default settings has the same problem, as well as with the
different backends such as `--backend=glx`.

Using `mpv --no-config` doesn't help, and messing around with
`--x11-bypass-compositor` as mentioned in mpv(1) doesn't seem to affect
the issue.

Using an override in `/etc/X11/xorg.conf.d/intel.conf` to force intel(4)
instead of the default modesetting(4) with TearFree enabled and
`machdep.allowaperture=1` *does* help and gets rid of the tearing. I
would really prefer to use modesetting(4) if at all possible however.

Interestingly, killing xcompmgr before playback removes the screen
tearing entirely. So currently the only real workaround I know of that
doesn't involve using intel(4) is a wrapper script I run to turn off
xcompmgr before playback, and enable it after playback is finished. I'll
include it below along with some other relevant information.

The FAQ mentions some stuff about tearing but none of it worked for me.

https://github.com/mpv-player/mpv/wiki/FAQ

There are open issues about things that appear to be similar, and in
those others corroborate that it seems to be something with the
modesetting driver:

https://github.com/mpv-player/mpv/issues/7106
https://gitlab.freedesktop.org/xorg/xserver/-/issues/928

If there's any more info I can provide on my end for debugging purposes,
let me know. Otherwise, here's what I have.


$ cat /var/log/Xorg.0.log # modesetting(4)
[ 11307.284] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem
(Operation not permitted)
Check that you have set 'machdep.allowaperture=1'
in /etc/sysctl.conf and reboot your machine
refer to xf86(4) for details
[ 11307.285]linear framebuffer access unavailable
[ 11307.290] (--) Using wscons driver on /dev/ttyC4
[ 11307.293]
X.Org X Server 1.21.1.3
X Protocol Version 11, Revision 0
[ 11307.293] Current Operating System: OpenBSD lain.home.arpa 7.1 
GENERIC.MP#458 amd64
[ 11307.293]
[ 11307.293] Current version of pixman: 0.40.0
[ 11307.293]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 11307.293] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 11307.293] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Apr  6 13:36:31 
2022
[ 11307.293] (==) Using system config directory 
"/usr/X11R6/share/X11/xorg.conf.d"
[ 11307.293] (==) No Layout section.  Using the first Screen section.
[ 11307.293] (==) No screen section available. Using defaults.
[ 11307.293] (**) |-->Screen "Default Screen Section" (0)
[ 11307.293] (**) |   |-->Monitor ""
[ 11307.293] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 11307.293] (==) Automatically adding devices
[ 11307.293] (==) Automatically enabling devices
[ 11307.293] (==) Not automatically adding GPU devices
[ 11307.293] (==) Automatically binding GPU devices
[ 11307.294] (==) Max clients allowed: 256, resource mask: 0x1f
[ 11307.294] (==) FontPath set to:
/usr/X11R6/lib/X11/fonts/misc/,
/usr/X11R6/lib/X11/fonts/TTF/,
/usr/X11R6/lib/X11/fonts/OTF/,
/usr/X11R6/lib/X11/fonts/Type1/,
/usr/X11R6/lib/X11/fonts/100dpi/,
/usr/X11R6/lib/X11/fonts/75dpi/
[ 11307.294] (==) ModulePath set to "/usr/X11R6/lib/modules"
[ 11307.294] (II) The server relies on wscons to provide the list of input 
devices.
If no devices become available, reconfigure wscons or disable 
AutoAddDevices.
[ 11307.294] (II) Loader magic: 0x724f63b87c0
[ 11307.294] (II) Module ABI versions:
[ 11307.294]X.Org ANSI C Emulation: 0.4
[ 11307.294]X.Org Video Driver: 25.2
[ 11307.294]X.Org XInput driver : 24.4
[ 11307.294]X.Org Server Extension : 10.0
[ 11307.294] (--) PCI:*(0@0:2:0) 8086:3ea0:17aa:2292 rev 2, Mem @ 
0xe000/16777216, 0xd000/268435456, I/O @ 0x2000/64
[ 11307.294] (II) LoadModule: "glx"
[ 11307.294] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
[ 11307.296] (II) Module glx: vendor="X.Org Foundation"
[ 11307.296]compiled for 1.21.1.3, module version = 1.0.0
[ 11307.296]ABI class: X.Org Server Extension, version 10.0
[ 11307.296] (==) Matched modesetting as autoconfigured driver 0
[ 11307.296] (==) Assigned the driver to the xf86ConfigLayout

Re: removing libutil.so.15.1 and libX11.so.17.1 per sysclean(8) breaks xmonad(1)

[Ashlen]

With the previous emails in mind, I have a diff for the build script in
the ports tree if it would help. My xmonad.hs hardly changes these days.
If the build script actually recompiled xmonad every time instead of
quitting if xmonad.hs hasn't changed, I don't think this issue would
come up in the future.


Index: files/build
===
RCS file: /cvs/ports/x11/xmonad/files/build,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 build
--- files/build 1 Mar 2021 04:16:34 -   1.1
+++ files/build 3 Apr 2022 17:02:34 -
@@ -2,11 +2,6 @@

 output_file="${1}"

-if [ "${output_file}" -nt xmonad.hs ]; then
-echo "${output_file}" is newer than xmonad.hs
-exit 0
-fi
-
 cabal v2-install exe:xmonad-config --overwrite-policy=always 
--install-method=copy

 [ -e "${output_file}" ] && mv -f "${output_file}" "${output_file}.old"


--
https://amissing.link/

Re: removing libutil.so.15.1 and libX11.so.17.1 per sysclean(8) breaks xmonad(1)

[Ashlen]

On 22/04/02 08:46, Sebastien Marie wrote:
> On Sat, Apr 02, 2022 at 07:11:42AM +0200, Sebastien Marie wrote:
> > On Fri, Apr 01, 2022 at 12:16:58PM -0600, Ashlen wrote:
> > >
> > > XMonad is recompiling and replacing itself with another XMonad process
> > > because the current process is called "xmonad" but the compiled
> > > configuration should be called "xmonad-x86_64-openbsd" XMonad will use 
> > > build
> > > script at "/home/ashlen/.config/xmonad/build" to recompile. XMonad
> > > recompiling because a custom build script is being used.
> > > [2022-04-01|12:07:54]: /home/ashlen/.cache/xmonad/xmonad-x86_64-openbsd is
> > > newer than xmonad.hs. XMonad recompilation process exited with success!
> > > ld.so: xmonad-x86_64-openbsd: can't load library 'libX11.so.17.1' Killed
> > >
> >
> > now, going back to the problem. the port doesn't need these libraries, but 
> > you
> > have a *locally build* binary (~/.cache/xmonad/xmonad-x86_64-openbsd) which
> > need them.
> >
> > I am unsure how xmonad itself work. if I recall well, the configuration is
> > done at compile time. so I assume it needs recompilation at some point,
> > specially after updating xmonad package (and potentially before removing
> > unused libraries).
> >
> > how do you recompile it ? your mail mentions ~/.config/xmonad/build. it is a
> > binary ? a script ? do you made it or it is a 'part' of xmonad ?
> >
>
> After reading https://xmonad.org/INSTALL.html#custom-build-script , some
> additional questions:
>
> could you show use your .xsession or .xinitrc (the part starting xmonad
> specially) ?
>
> if you use `~/.cache/xmonad/xmonad-x86_64-openbsd` directly to start xmonad, 
> you
> would need recompile it (with `xmonad --recompile`) after updating (base 
> and/or
> packages) to keep your local binary in sync with installed libraries.
>
> if you use `xmonad`, it should recompile itself (at every startup), and you 
> have
> nothing special to do (xmonad-x86_64-openbsd will be always up-to-date 
> regarding
> library dependances). (I am not 100% sure about that, I didn't take time to 
> read
> and understand xmonad source code).
>
>
> Please note that https://xmonad.org/TUTORIAL.html explicitly mentions this
> problem:
>
>   One more word of warning: if you are on a distribution that installs
>   every Haskell package dynamically linked—thus essentially breaking
>   Haskell—(Arch Linux being a prominent example) then we would highly
>   recommend installing via stack or cabal as instructed in INSTALL.md. If
>   you still want to install xmonad via your system’s package manager, you
>   will need to xmonad --recompile every time a Haskell dependency is
>   updated—else xmonad may fail to start when you want to log in!
>
> Thanks.
> --
> Sebastien Marie
>

Hey, thanks for the response. I can see that my initial message was
missing some important information, so sorry for the inconvenience
there.

It appears you're right about the old binary using old libs. Using a
newly compiled binary, I can't reproduce the problem I was running into.

It's recommended to use a build script upon installation via a package
message:


Information for inst:xmonad-0.17.0p0

Install notice:
XMonad is now compiled using `cabal v2-build`. If you rely on a custom
xmonad.hs configuration file, you should switch to using
~/.xmonad/build script. An example is included in
/usr/local/share/examples/xmonad-0.17.0

See https://github.com/xmonad/xmonad-testing/ for more information.


I think the problem is in the build script. ~/.config/xmonad/build is
essentially the same as /usr/local/share/examples/xmonad-0.17.0/build
but I'll post it inline anyway.


#!/bin/ksh
set -eu

output_file="$1"

if [ "${output_file}" -nt 'xmonad.hs' ]; then
echo "[$(date '+%Y-%m-%d|%H:%M:%S')]: ${output_file} is newer than 
xmonad.hs."
exit 0
fi

cabal v2-install exe:xmonad-config --overwrite-policy=always 
--install-method=copy

[ -f "${output_file}" ] && mv -f -- "${output_file}" "${output_file}.old"
install -- "${HOME}/.cabal/bin/xmonad-config" "${output_file}"


The problem seems to be with the if statement, which is also in
/usr/local/share/examples/xmonad-0.17.0/build. The build script checks
against xmonad.hs (the configuration file) and if the old binary is
newer, it aborts the build process suddenly and successfully. I'm
guessing it's to not recompile if no changes were made to the config,
which is convenient in the short term but would lead to breakages like
this in the long term.

I'm a bit surprised I didn't run into a 

removing libutil.so.15.1 and libX11.so.17.1 per sysclean(8) breaks xmonad(1)

[Ashlen]

Hi, I'm on this snapshot with updated packages:


$ sysctl -n kern.version
OpenBSD 7.1 (GENERIC.MP) #454: Thu Mar 31 09:28:09 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


sysclean(8) from ports recommends to delete
/usr/X11R6/lib/libX11.so.17.1 and /usr/lib/libutil.so.15.1 but if these
files are removed, xmonad(1) will fail to start and it quits back to
xenodm(1) login. These are the relevant messages in ~/.xsession-errors
(I've seen both cause this).


XMonad is recompiling and replacing itself with another XMonad process because 
the current process is called "xmonad" but the compiled configuration should be 
called "xmonad-x86_64-openbsd"
XMonad will use build script at "/home/ashlen/.config/xmonad/build" to 
recompile.
XMonad recompiling because a custom build script is being used.
[2022-04-01|12:07:54]: /home/ashlen/.cache/xmonad/xmonad-x86_64-openbsd is 
newer than xmonad.hs.
XMonad recompilation process exited with success!
ld.so: xmonad-x86_64-openbsd: can't load library 'libX11.so.17.1'
Killed


I should mention that sysclean -p does not report that xmonad(1) needs
these files, and that sysclean was used without flags here.

If this should be in ports@ feel free to forward this there, wasn't too
sure where to send this.


OpenBSD 7.1 (GENERIC.MP) #454: Thu Mar 31 09:28:09 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16959832064 (16174MB)
avail mem = 16428556288 (15667MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xc7d49000 (64 entries)
bios0: vendor LENOVO version "N2HET66W (1.49 )" date 11/10/2021
bios0: LENOVO 20QDUS
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT UEFI SSDT HPET APIC MCFG ECDT SSDT 
SSDT SSDT BOOT SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB NHLT DMAR FPDT BGRT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) 
RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1724.02 MHz, 06-8e-0c
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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1696.05 MHz, 06-8e-0c
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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
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) i7-8565U CPU @ 1.80GHz, 1696.05 MHz, 06-8e-0c
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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
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) i7-8565U CPU @ 1.80GHz, 1696.05 MHz, 06-8e-0c
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,TSC_ADJUST,SGX,BMI1,AVX2,SM

Re: Exoscale VPS panic on boot, 10-25 snapshot

[Ashlen]

On 21/10/26 08:28, Hrvoje Popovski wrote:
>
> could you try lastes snapshot with sysupgrade? i had same problem on
> Dell r620 and latest snapshot fix that panic ..

Thank you for the prompt response. Now I'm having no issue with that
kernel panic, perhaps I was just unlucky in when I chose to upgrade.
What a relief. :)

--
https://amissing.link

Exoscale VPS panic on boot, 10-25 snapshot

[Ashlen]

Here is as much information as I could get. After upgrading to a
snapshot earlier today (October 25th), the Exoscale VPS panics on boot.
I use this VPS to self-host synapse (a Matrix homeserver, for
messaging).

I can't copy and paste from the web console that Exoscale provides so I
had to transcribe all of it by hand, I hope it's all accurate. In
particular, the correct number of spaces between fields in `ps` output
is unknown to me, but everything else should be OK I think. I tried to
get a traceback for cpu1 as well, but the console hangs when I issue
`machine ddbcpu 1` so only the traceback for cpu0 was available to me.

Booting /bsd.sp instead of /bsd.mp or scaling the VPS down to one core
appears to make no difference, the panic happens regardless.

Any suggestions to get my VPS back up and running would be much
appreciated, I feel pretty lost with what to do next. Thanks.


OpenBSD 7.0-current (GENERIC.MP) #52: Mon Oct 25 10:15:58 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2130554880 (2031MB)
avail mem = 2050072576 (1955MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5ab0 (10 entries)
bios0: vendor SeaBIOS version "1.13.0-1ubuntu1.1" date 04/01/2014
bios0: Exoscale Exoscale Compute Platform
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP APIC HPET
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: Intel Xeon Processor (Skylake) 2500.34 MHz, 06-55-04
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,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SWAP,CLFLUSHOPT,CLWB,AVX512CD,AVX512BW,AVX512VL,PKU,IBRS,IBPB,SSBD,ARAT,XSAVEOPT,XSAVEC,XGETBV1,MELTDOWN
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: 1TLB 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
mttr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel Xeon Processor (Skylake), 2500.09 MHz, 06-55-04
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,AVX2,SMEP,BM12,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,AVX512CD,AVX512BW,AVX512VL,PKU,IBRS,IBPB,SSBD,ARAT,XSAVEOPT,XSAVEC,XGETBV1,MELTDOWN
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu1: 1TLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu1: disabling user TSC (skew=120)
cpu1: smt 0, core 0, package 1
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
"ACPI0006" at acpi0 not configured
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"QEMU0002" at acpi0 not configured
"ACPI0010" at acpi0 not configured
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
cpu0: using Skylake AVX MDS workaround
pvbus0 at mainbus0: KVM
pvclock0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA channel 0 
wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int 9
iic0 at piixmp0
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio0: address 06:b4:0e:00:09:73
virtio0: msix per-VQ
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: 102400MB, 512 bytes/sector, 209715200 sectors
virtio1: misx shared
virtio2 at pci0 dev 5 function 0 "Qumranet Virtio RNG" rev 0x00
viornd0 at virtio2
virtio2: apic 0 int 10
isa0 at pcib0

Question regarding queueing in pf.conf(5) and WireGuard

[Ashlen]

Hello. I have an APU4D4 running OpenBSD and acting as a router for my
home network. It connects to the Internet via pppoe(4), which uses em(4)
as the physical interface.

The router has a /etc/hostname.wg0 file that connects it as a client to
my VPN provider on boot. Then, /etc/pf.conf has a nat-to rule for
WireGuard, for IP masquerading. Here's said rule:

match out on wg inet from !(wg:network) to any nat-to (wg:0)

In pf.conf(5), there's mention of this simple configuration
for bandwidth control:

queue outq on em0 bandwidth 9M max 9M flows 1024 qlimit 1024 \
   default

I want to employ this rule. My question is, which interface is
appropriate to choose for queueing? pppoe0, em0, or wg0? I'd think wg0,
as I'm unsure how pf(4) would classify traffic otherwise. However, I'm
not confident in that conclusion, so I decided to ask.

If additional details are needed, I'm happy to provide them.

--
https://amissing.link

mpv dumps core and segfaults when exiting on any video file

[Ashlen]

Usually goes something like the following after the file finishes
playing/the user exits:

$ mpv --no-config example.mkv

[ ... ]
Exiting... (End of file)
pthread_mutex_destroy on mutex with waiters!
Segmentation fault (core dumped)


Here's the backtrace.

# gdb -quiet mpv mpv.core
(no debugging symbols found)
Core was generated by `mpv'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.26.1...done.
Loaded symbols for /usr/lib/libpthread.so.26.1
Loaded symbols for /usr/local/bin/mpv
Reading symbols from /usr/local/lib/liblua5.1.so.5.1...done.
Loaded symbols for /usr/local/lib/liblua5.1.so.5.1
Reading symbols from /usr/lib/libm.so.10.1...done.
Loaded symbols for /usr/lib/libm.so.10.1
Reading symbols from /usr/local/lib/libcdio_paranoia.so.1.0...done.
Loaded symbols for /usr/local/lib/libcdio_paranoia.so.1.0
Reading symbols from /usr/local/lib/libcdio_cdda.so.1.0...done.
Loaded symbols for /usr/local/lib/libcdio_cdda.so.1.0
Reading symbols from /usr/local/lib/libcdio.so.1.0...done.
Loaded symbols for /usr/local/lib/libcdio.so.1.0
Reading symbols from /usr/local/lib/libiconv.so.7.0...done.
Loaded symbols for /usr/local/lib/libiconv.so.7.0
Reading symbols from /usr/local/lib/libdvdnav.so.7.2...done.
Loaded symbols for /usr/local/lib/libdvdnav.so.7.2
Reading symbols from /usr/local/lib/libdvdread.so.9.0...done.
Loaded symbols for /usr/local/lib/libdvdread.so.9.0
Reading symbols from /usr/X11R6/lib/libEGL.so.1.1...done.
Loaded symbols for /usr/X11R6/lib/libEGL.so.1.1
Reading symbols from /usr/X11R6/lib/libXdamage.so.4.0...done.
Loaded symbols for /usr/X11R6/lib/libXdamage.so.4.0
Reading symbols from /usr/X11R6/lib/libXfixes.so.6.0...done.
Loaded symbols for /usr/X11R6/lib/libXfixes.so.6.0
Reading symbols from /usr/X11R6/lib/libX11-xcb.so.2.0...done.
Loaded symbols for /usr/X11R6/lib/libX11-xcb.so.2.0
Reading symbols from /usr/X11R6/lib/libxcb-glx.so.1.1...done.
Loaded symbols for /usr/X11R6/lib/libxcb-glx.so.1.1
Reading symbols from /usr/X11R6/lib/libxcb-dri2.so.1.1...done.
Loaded symbols for /usr/X11R6/lib/libxcb-dri2.so.1.1
Reading symbols from /usr/X11R6/lib/libXxf86vm.so.6.0...done.
Loaded symbols for /usr/X11R6/lib/libXxf86vm.so.6.0
Reading symbols from /usr/X11R6/lib/libXext.so.13.0...done.
Loaded symbols for /usr/X11R6/lib/libXext.so.13.0
Reading symbols from /usr/X11R6/lib/libX11.so.17.1...done.
Loaded symbols for /usr/X11R6/lib/libX11.so.17.1
Reading symbols from /usr/X11R6/lib/libxcb.so.4.1...done.
Loaded symbols for /usr/X11R6/lib/libxcb.so.4.1
Reading symbols from /usr/X11R6/lib/libXau.so.10.0...done.
Loaded symbols for /usr/X11R6/lib/libXau.so.10.0
Reading symbols from /usr/X11R6/lib/libXdmcp.so.11.0...done.
Loaded symbols for /usr/X11R6/lib/libXdmcp.so.11.0
Reading symbols from /usr/X11R6/lib/libdrm.so.7.9...done.
Loaded symbols for /usr/X11R6/lib/libdrm.so.7.9
Reading symbols from /usr/local/lib/libavfilter.so.9.0...done.
Loaded symbols for /usr/local/lib/libavfilter.so.9.0
Reading symbols from /usr/local/lib/libswscale.so.7.0...done.
Loaded symbols for /usr/local/lib/libswscale.so.7.0
Reading symbols from /usr/local/lib/libpostproc.so.18.0...done.
Loaded symbols for /usr/local/lib/libpostproc.so.18.0
Reading symbols from /usr/local/lib/libavformat.so.21.0...done.
Loaded symbols for /usr/local/lib/libavformat.so.21.0
Reading symbols from /usr/local/lib/libavcodec.so.24.0...done.
Loaded symbols for /usr/local/lib/libavcodec.so.24.0
Reading symbols from /usr/local/lib/libavresample.so.2.0...done.
Loaded symbols for /usr/local/lib/libavresample.so.2.0
Reading symbols from /usr/local/lib/libswresample.so.3.0...done.
Loaded symbols for /usr/local/lib/libswresample.so.3.0
Reading symbols from /usr/local/lib/libavutil.so.14.0...done.
Loaded symbols for /usr/local/lib/libavutil.so.14.0
Reading symbols from /usr/X11R6/lib/libgbm.so.0.4...done.
Loaded symbols for /usr/X11R6/lib/libgbm.so.0.4
Reading symbols from /usr/local/lib/libjpeg.so.70.0...done.
Loaded symbols for /usr/local/lib/libjpeg.so.70.0
Reading symbols from /usr/local/lib/liblcms2.so.1.4...done.
Loaded symbols for /usr/local/lib/liblcms2.so.1.4
Reading symbols from /usr/local/lib/libarchive.so.11.2...done.
Loaded symbols for /usr/local/lib/libarchive.so.11.2
Reading symbols from /usr/local/lib/libass.so.3.1...done.
Loaded symbols for /usr/local/lib/libass.so.3.1
Reading symbols from /usr/X11R6/lib/libfontconfig.so.13.0...done.
Loaded symbols for /usr/X11R6/lib/libfontconfig.so.13.0
Reading symbols from /usr/lib/libexpat.so.12.0...done.
Loaded symbols for /usr/lib/libexpat.so.12.0
Reading symbols from /usr/local/lib/libharfbuzz.so.15.5...done.
Loaded symbols for /usr/local/lib/libharfbuzz.so.15.5
Reading symbols from /usr/local/lib/libgraphite2.so.2.0...done.
Loaded symbols for /usr/local/lib/libgraphite2.so.2.0
Reading symbols from /usr/local/lib/libglib-2.0.so.4201.5...done.
Loaded symbols for /usr/local/lib/libglib-2.0.so.4201.5
Reading symbols from /usr/local/lib/libintl.so.7.0...done.

fzf fails if bash isn't present or FZF_DEFAULT_COMMAND isn't set

[Ashlen]

Executing fzf without bash installed or FZF_DEFAULT_COMMAND set fails
with this output:

Command failed: set -o pipefail; command find -L . -mindepth 1 \( -path '*/\.*' 
-o -fstype 'sysfs' -o -fstype 'devfs' -o..

(the output cuts off there for some reason, even when I pipe STDERR to a file).



I know of two workarounds for this problem:

1) Install bash (it isn't pulled in as a dependency).

# pkg_add bash

2) Force the FZF_DEFAULT_COMMAND variable to the value of 'defaultCommand'
in constants.go:

$ FZF_DEFAULT_COMMAND="set -o pipefail; command find -L . -mindepth 1 \\
\( -path '*/\.*' -o -fstype 'sysfs' -o -fstype 'devfs' \\
-o -fstype 'devtmpfs' -o -fstype 'proc' \) \\
-prune -o -type f -print -o -type l -print 2> /dev/null | cut -b3-" fzf



I found the defaultCommand value here:
https://github.com/junegunn/fzf/blob/764316a53d0eb60b315f0bbcd513de58ed57a876/src/constants.go#L61



$ uname -a
OpenBSD lain.lan 6.9 GENERIC.MP#473 amd64

$ dmesg
OpenBSD 6.9 (GENERIC.MP) #473: Mon Apr 19 10:40:28 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16959827968 (16174MB)
avail mem = 16430444544 (15669MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xc7d49000 (64 entries)
bios0: vendor LENOVO version "N2HET55W (1.38 )" date 08/24/2020
bios0: LENOVO 20QDUS
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT UEFI SSDT HPET APIC MCFG ECDT SSDT 
SSDT SSDT BOOT SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB NHLT DMAR FPDT BGRT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) 
RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 7432.58 MHz, 06-8e-0c
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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1425.80 MHz, 06-8e-0c
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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
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) i7-8565U CPU @ 1.80GHz, 1212.50 MHz, 06-8e-0c
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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
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) i7-8565U CPU @ 1.80GHz, 1086.90 MHz, 06-8e-0c
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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-127
acpiec0 at acpi0
acpiprt0 at acpi0: bus 

Re: periodic network access failure when accessing nextcloud via relayd

[Ashlen]

On 21/03/31 23:50, Joel Carnat wrote:
> Hello,
>
> I have Nextcloud 21 running with php-7.4, httpd(8) and relayd(8).
> On my laptop, a script regularly runs nextcloudcmd to synchonize the files
> with the nextcloud instance. And quite often, nextcloudcmd returns such error:
>   03-31 23:28:56:089 [ info nextcloud.sync.networkjob.lscol ]:LSCOL of
>   
> QUrl("https://nextcloud.tumfatig.net/remote.php/dav/files/user85419/Uploads;) 
> FINISHED
>   WITH STATUS "UnknownNetworkError Network access is disabled."

I did some reading on the issue.[1][2][3] It appears to affect some
users on other platforms if the 'Use system proxy' setting on the desktop
client is enabled (though some reported that the presence/absence of the
option didn't seem to affect anything).

As an experiment, you could temporarily disable keep-alive in relayd.conf(5).
It probably won't fix anything (in which case you can revert it), but it's 
worth trying imo.
https://marc.info/?l=openbsd-misc=150287292709311=2

[1]: https://github.com/nextcloud/desktop/issues/482
[2]: https://github.com/nextcloud/desktop/issues/865
[3]: https://github.com/nextcloud/desktop/issues/2628

--
https://amissing.link

Re: Enhancing Privacy in 2020 attached screenshot

[Ashlen]

On 20/12/16 22:55, pipus wrote:
> haha Stuart.
> Always there to make a low IQ entrance :)
Ever hear of Dunning-Kruger, pipus?

https://lsa.umich.edu/psych/news-events/all-news/faculty-news/the-dunning-kruger-effect-shows-why-some-people-think-they-re-gr.html

I hope you can look inward and find peace. Meditate and aim to be better
than you were yesterday. With some practice and dedication, who
knows...maybe you can become a valuable asset. In other words, a little
more like Stuart. ;)

--
https://amissing.link

Re: E-mail problem

[Ashlen]

On 20/11/13 11:26, Berkay Tuncel wrote:
> Hi all,
>
>
>
> We need an advice for our e-mail traffic with openbsd.org
>
>
> When I sent an e-mail to openbsd.org which is rhs, from 160.75.0.0/16, I
> got a TLS handshake error. On the other hand, when I tried from another
> subnet, there was no problem.
>
>
> Nevertheless, our mta has not a problem like this with any other mta.
> That's why, I think it can be a network related issue but still we need
> some help :)
>
>
> Thanks.
>
> Berkay

I'm no expert on smtpd(8); that said, it's essential to post an
appropriate amount of information to troubleshoot the problem. In your
case, that means including what's inside smtpd.conf(5) and pf.conf(5)
(as it could be related to packet filtering), as well as output from
/var/log/maillog and dmesg(8).

I might be forgetting something, in which case someone else can chime in
with additions, but these are the obvious inclusions in my mind.

--
https://amissing.link

Re: Are relayd and httpd my future buddy?

[Ashlen]

On 20/10/30 23:29, Lars Bonnesen wrote:
> If I can use relayd for this, could someone please share a relayd.conf
> example for me?
>
> Regards, Lars.

In addition to what others have said, remember to check /etc/examples,
as there are entries for both httpd.conf(5) and relayd.conf(5).

--
https://amissing.link

Re: possible relayd.conf(5) documentation mistake regarding session tickets

[Ashlen]

On 20/10/21 09:26PM, Sebastian Benoit wrote:
> * i'm not sure we wanted session resumption to be enabled by default
> because of the security implications regarding perferct forward
> secrecy. Indeed the option is off by default at the moment.

Hey, thanks for explaining a bit. :) I read about session resumption
after your mail and can see why the default is off.

Originally I noticed the disparity between what the man page states and
what Qualys reports because I was comparing the results of default
ciphers and `tls { ciphers secure }`, as `openssl ciphers -v secure`
returns an error and SSL_CTX_set_cipher_list(3) doesn't list secure as
a control string.

--
https://amissing.link

possible relayd.conf(5) documentation mistake regarding session tickets

[Ashlen]

In relayd.conf(5), the tls section under PROTOCOLS states the following:

no session tickets
 Disable TLS session tickets.  relayd(8) supports stateless TLS
 session tickets (RFC 5077) to implement TLS session resumption.
 The default is to enable session tickets.

However, an SSL Labs test[1] without `tls { session tickets }` specified
shows no session tickets.

$ uname -a
OpenBSD lain.lan 6.8 GENERIC.MP#98 amd64

[1]: https://www.ssllabs.com/ssltest/

--
https://amissing.link

Re: tmux rc script not stopping

[Ashlen]

In retrospect, command -v seems to be more portable than which[1]. So
a better version would be:

if command -v tmux >/dev/null 2>&1; then
  # if not inside a tmux session, and if no session is started, start
  # a new session
  test -z "$TMUX" && (tmux attach || tmux new-session)
fi

Though I suppose this is likely academic in nature.

[1]: 
https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then

--
https://amissing.link

Re: tmux rc script not stopping

[Ashlen]

On 20/10/07 02:34PM, ben wrote:
> Hello, Misc;
>
> I'm attempting to write an rc script to start a tmux session:

What problem are you trying to solve by using an rc script?

I have this in my .kshrc for automatic tmux sessions:

if which tmux >/dev/null 2>&1; then
  # if not inside a tmux session, and if no session is started, start
  # a new session
  test -z "$TMUX" && (tmux attach || tmux new-session)
fi

Of course, in the end the solution depends on what you want to do.

--
https://amissing.link

Re: How do you get different $PS1 for /bin/sh and /bin/ksh?

[Ashlen]

On 20/09/15 05:49PM, Ottavio Caruso wrote:
> Maybe it's just because OpenBSD sh is just ksh in disguise or there
> might be other reasons that I obviously don't know.

Yep, you're right. They share the same inode.

ls -li /bin/{,k}sh

77862 -r-xr-xr-x  3 root  bin  613656 Sep 15 12:10 /bin/ksh
77862 -r-xr-xr-x  3 root  bin  613656 Sep 15 12:10 /bin/sh

sh(1) also attests to this.

--
https://amissing.link

Re: ncmpcpp dumps core when fetching lyrics

[Ashlen]

Ah, my bad. I had wrap=72 and reflow_wrap=72 in neomuttrc and forgot it
would affect output like that. Hopefully this one is better.

GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.8".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ncmpcpp...done.
[New process 190872]
Core was generated by `ncmpcpp'.
Program terminated with signal SIGBUS, Bus error.
#0  _libc_pthread_mutex_unlock (mutexp=) at 
/usr/src/lib/libc/thread/rthread_mutex.c:246
246 /usr/src/lib/libc/thread/rthread_mutex.c: No such file or directory.
(gdb) bt
#0  _libc_pthread_mutex_unlock (mutexp=) at 
/usr/src/lib/libc/thread/rthread_mutex.c:246
#1  0x05595695fb27 in std::__1::__libcpp_mutex_unlock (__m=0x55a00cce818)
at /usr/src/lib/libcxx/include/__threading_support:266
#2  std::__1::mutex::unlock (this=0x55a00cce818) at 
/usr/src/lib/libcxx/src/mutex.cpp:45
#3  0x05572d3b623d in std::__1::unique_lock::~unique_lock 
(this=)
at /usr/include/c++/v1/__mutex_base:153
#4  Shared >::Resource::~Resource (this=) 
at ./utility/shared_resource.h:29
#5  Lyrics::update (this=0x559775d4400) at screens/lyrics.cpp:236
#6  0x05572d4137d5 in std::__1::__function::__value_func::operator()(BaseScreen*&&) const (
this=0x7f7eef80, __args=) at 
/usr/include/c++/v1/functional:1799
#7  std::__1::function::operator()(BaseScreen*) const 
(this=0x7f7eef80, __arg=0x559775d4400)
at /usr/include/c++/v1/functional:2347
#8  applyToVisibleWindows(std::__1::function) (f=...) at 
screens/screen.cpp:135
#9  0x05572d4f9848 in Status::trace (update_timer=, 
update_window_timeout=)
at status.cpp:233
#10 0x05572d46ae33 in Actions::UpdateEnvironment::run (this=0x7f7ef348, 
update_timer=24,
refresh_window=, mpd_sync=) at actions.cpp:338
#11 0x05572d4cf110 in main (argc=, argv=) at 
ncmpcpp.cpp:217
(gdb) quit

--
https://amissing.link

Re: ncmpcpp dumps core when fetching lyrics

[Ashlen]

Sorry Stuart, I think I accidentally replied to you directly the first
time I sent this. I'm still getting used to neomutt.

On 20/09/11 09:09AM, Stuart Henderson wrote:
> First thing to look for when there's a core dump is to see if you can
> get a useful backtrace. How does the output look from this?
>
> pkg_add gdb
> egdb ncmpcpp ncmpcpp.core
> bt
>
> If the lines output from "bt" don't have function names in,
> rebuild ncmpcpp with "make clean; DEBUG=-g make repackage reinstall"
> and try again.

Hey, thanks for the prompt reply and for explaining what I needed to
do. Out of curiosity, why did you want me to install gdb as opposed to
using the version included in the base system? I did so, yet am unaware
of the difference between them.

Here's the output from egdb after recompiling:

GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.8".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ncmpcpp...done.
[New process 190872]
Core was generated by `ncmpcpp'.
Program terminated with signal SIGBUS, Bus error.
#0  _libc_pthread_mutex_unlock (mutexp=) at 
/usr/src/lib/libc/thread/rthread_mutex.c:246
246 /usr/src/lib/libc/thread/rthread_mutex.c: No such file or directory.
(gdb) bt
#0  _libc_pthread_mutex_unlock (mutexp=) at 
/usr/src/lib/libc/thread/rthread_mutex.c:246
#1  0x05595695fb27 in std::__1::__libcpp_mutex_unlock (__m=0x55a00cce818)
at /usr/src/lib/libcxx/include/__threading_support:266
#2  std::__1::mutex::unlock (this=0x55a00cce818) at 
/usr/src/lib/libcxx/src/mutex.cpp:45
#3  0x05572d3b623d in std::__1::unique_lock::~unique_lock 
(this=)
at /usr/include/c++/v1/__mutex_base:153
#4  Shared >::Resource::~Resource (this=) 
at ./utility/shared_resource.h:29
#5  Lyrics::update (this=0x559775d4400) at screens/lyrics.cpp:236
#6  0x05572d4137d5 in std::__1::__function::__value_func::operator()(BaseScreen*&&) const (
this=0x7f7eef80, __args=) at 
/usr/include/c++/v1/functional:1799
#7  std::__1::function::operator()(BaseScreen*) const 
(this=0x7f7eef80, __arg=0x559775d4400)
at /usr/include/c++/v1/functional:2347
#8  applyToVisibleWindows(std::__1::function) (f=...) at 
screens/screen.cpp:135
#9  0x05572d4f9848 in Status::trace (update_timer=, 
update_window_timeout=)
at status.cpp:233
#10 0x05572d46ae33 in Actions::UpdateEnvironment::run (this=0x7f7ef348, 
update_timer=24,
refresh_window=, mpd_sync=) at actions.cpp:338
#11 0x05572d4cf110 in main (argc=, argv=) at 
ncmpcpp.cpp:217

--
https://amissing.link

ncmpcpp dumps core when fetching lyrics

[Ashlen]

ktrace(1) suggests to me that it's a pathname issue based on this line:

33399 ncmpcpp  NAMI  "/home/ashlen/.config/ncmpcpp/lyrics//Porcupine
Tree - Arriving Somewhere But Not Here.txt"


Issuing

$ mv ~/.config/ncmpcpp{,.bak}

doesn't do anything to fix the issue, so it doesn't seem to be
a problem caused by my configs.


ktrace.out can be made available upon request. I didn't include it
because it's quite long.


$ uname -a
OpenBSD lain.lan 6.8 GENERIC.MP#64 amd64

$ dmesg
OpenBSD 6.8-beta (GENERIC.MP) #64: Sun Sep  6 18:19:41 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16959840256 (16174MB)
avail mem = 16430784512 (15669MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.1 @ 0x77d49000 (64 entries)
bios0: vendor LENOVO version "N2HET54W (1.37 )" date 08/03/2020
bios0: LENOVO 20QDUS
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT UEFI SSDT HPET APIC MCFG ECDT SSDT 
SSDT BOOT SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB DMAR NHLT FPDT BGRT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) 
RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 7468.09 MHz, 06-8e-0c
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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1696.79 MHz, 06-8e-0c
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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
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) i7-8565U CPU @ 1.80GHz, 1696.05 MHz, 06-8e-0c
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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
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) i7-8565U CPU @ 1.80GHz, 1696.05 MHz, 06-8e-0c
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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-127
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus -1 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiprt5 at acpi0: bus -1 (RP05)
acpiprt6 at acpi0: bus -1 (RP06)
acpiprt7 at acpi0: bus -1 (RP07)
acpiprt8 at acpi0: bus -1 (RP08)
acpiprt9 at acpi0: bus 3 (RP09)
acpiprt10 at acpi0: bus -1 (RP10)
acpiprt11 at acpi0: bus -1 (RP11)
acpiprt12 at acpi0: bus -1 (RP12)
acpiprt13 at acpi0: bus 5 (RP13)
acpiprt14 at acpi0: bus -1 (RP14)
acpiprt15 at acpi0: bus -1 (RP15