Re: xenodm greeter pixmaps

2023-10-04 Thread Marcus MERIGHI
Hello, 

m...@paianis.name (Paianis), 2023.10.03 (Tue) 14:47 (CEST):
> I wanted some cleaner pixmaps of the logo for the login greeter than
> those currently in the tree, so I remade them from the PDFs that used to
> be on the website, using mutool and imagemagick's convert.
> 
> The low-color and greyscale versions are untested on suitable hardware.
> 
> I don't have the ability to commit changes, the files attached are for
> anyone who can and wants to.
> 
> Paianis

I tried to convert the files with xpmtoppm (from graphics/netpbm), which
complained:


xpmtoppm: Cannot find data structure declaration.  Expected a line
starting with 'static char', but found the line 'static const char
*OpenBSD_15bpp[] = {
'.


Today I saw the message below, it's about the last paragraph. 

+
Subject: X.Org Security Advisory: Issues in libX11 prior to 1.8.7 &
libXpm prior to 3.5.17
Date: Tue, 3 Oct 2023 09:27:22 -0700
From: Alan Coopersmith 
To: xorg-annou...@lists.x.org
CC: x...@lists.x.org

X.Org Security Advisory:  October 3, 2023

Issues in libX11 prior to 1.8.7 & libXpm prior to 3.5.17


Multiple issues have been found in the libX11 & libXpm libraries
published
by X.Org for which we are releasing security fixes in libX11 1.8.7 &
libXpm 3.5.17.

The first issue (CVE-2023-43785) can be triggered by connecting to an
X server that sends specially crafted replies to X11 protocol requests.

The other 4 issues can be triggered by opening specially crafted XPM
format
image files via libXpm.  Two of the four issues have root causes in the
libX11 library and are fixed there, but patches have also been applied
to libXpm to avoid passing the invalid data to libX11 in the first
place.
+

$ ldd /usr/local/bin/xpmtoppm
/usr/local/bin/xpmtoppm:
StartEnd  Type  Open Ref GrpRef Name
0da20cf0a000 0da20cf13000 exe   10   0
/usr/local/bin/xpmtoppm
0da416126000 0da416177000 rlib  01   0
/usr/local/lib/libnetpbm.so.6.0
0da508ff2000 0da509023000 rlib  02   0
/usr/lib/libm.so.10.1
0da4ccb95000 0da4ccc8f000 rlib  02   0
/usr/lib/libc.so.97.1
0da422105000 0da422105000 ld.so 01   0
/usr/libexec/ld.so

So I figure xpmtoppm isn't affected.

OpenBSD today has a syspatch for it... 

I have no idea whether the .xpm files sent yesterday are dangerous.

Nonetheless it was pretty careless of me to open a .xpm file from a
stranger on the Internet.

Marcus



Re: ssh(1) -v gives debug1: pledge: filesystem full

2021-05-20 Thread Marcus MERIGHI
Hello Hiltjo, 

thanks for looking further than I did...

Moving to tech@...

hil...@codemadness.org (Hiltjo Posthuma), 2021.05.19 (Wed) 16:59 (CEST):
> On Wed, May 19, 2021 at 01:20:34PM +0200, Marcus MERIGHI wrote:
> > By accident I noticed that 
> > 
> > $ ssh -v $host
> > 
> > gives me, among many other lines, this
> > 
> > debug1: pledge: filesystem full
> > 
> > Is this expected? Something to worry about?
> 
> A grep shows its in the file /usr/src/usr.bin/ssh/clientloop.c client_loop()
> function.

to prevent the *very* similiar wording of the infamous dmesg output

uid 539 on /var/db/clamav: file system full

I'd suggest a slightly different message, something like this?

Marcus

Index: usr.bin/ssh/clientloop.c
===
RCS file: /cvs/src/usr.bin/ssh/clientloop.c,v
retrieving revision 1.363
diff -u -p -u -r1.363 clientloop.c
--- usr.bin/ssh/clientloop.c19 May 2021 01:24:05 -  1.363
+++ usr.bin/ssh/clientloop.c20 May 2021 10:11:06 -
@@ -1232,7 +1232,7 @@ client_loop(struct ssh *ssh, int have_pt
fatal_f("pledge(): %s", strerror(errno));
 
} else if (options.update_hostkeys) {
-   debug("pledge: filesystem full");
+   debug("pledge: filesystem full access");
if (pledge("stdio rpath wpath cpath unix inet dns proc tty",
NULL) == -1)
fatal_f("pledge(): %s", strerror(errno));



ifconfig(8) add bpe(4)

2021-04-11 Thread Marcus MERIGHI
hello!

the description of bpe(4) is missing from ifconfig(8).
my attempt with what I could gather from bpe(4) below.

marcus

Index: ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.371
diff -u -p -u -r1.371 ifconfig.8
--- ifconfig.8  19 Mar 2021 19:36:10 -  1.371
+++ ifconfig.8  11 Apr 2021 14:41:08 -
@@ -182,6 +182,7 @@ Create the specified network pseudo-devi
 At least the following devices can be created on demand:
 .Pp
 .Xr aggr 4 ,
+.Xr bpe 4 ,
 .Xr bridge 4 ,
 .Xr carp 4 ,
 .Xr egre 4 ,
@@ -2205,6 +2206,31 @@ Valid tag values are from 1 to 4094 incl
 Clear the tag value.
 Packets on a VLAN interface without a tag set will use a value of
 0 in their headers.
+.El
+.Sh BPE
+.nr nS 1
+.Bk -words
+.Nm ifconfig
+.Ar bpe-interface
+.Op Oo Fl Oc Ns Cm parent Ar parent-interface
+.Op Ns Cm vnetid Ar vnetid-tag
+.Ek
+.nr nS 0
+.Pp
+The following options are available for
+.Xr bpe 4
+interfaces:
+.Bl -tag -width Ds
+.It Cm parent Ar parent-interface
+Associate the BPE interface with the interface
+.Ar parent-interface .
+.It Cm -parent
+Disassociate from the parent interface.
+This breaks the link between the BPE interface and its parent.
+.It Cm vnetid Ar vnetid-tag
+Set the virtual network identifier tag value to
+.Ar vnetid-tag .
+This is a 24-bit value in the range 0 to 16777215.
 .El
 .Sh WIREGUARD
 .nr nS 1



Re: monotonic time going back by wrong skews

2021-04-06 Thread Marcus MERIGHI
Good Evening!

giova...@paclan.it (Giovanni Bechis), 2021.04.06 (Tue) 11:14 (CEST):
> On 4/6/21 10:16 AM, YASUOKA Masahiko wrote:
> > I'm sorry..  I send a wrong diff to the people.  The result from
> > giovanni@ and mcmer seems wrong.  I suppose stu@ used the correct
> > diff.
> > giovanni and mcmer, can you test with the correct diff again?
> > I attached the correct diff at last of this mail.
> new .tgz attached.
>  Giovanni

Wow, that was fast, Giovanni :-)

Mine attached, with dmesg, this time from the kernel to be tested.

No "pstat: cannot read 0x9704: invalid address (9704)" this time.

Marcus


tsc.tar.gz
Description: application/tar-gz
OpenBSD 6.9 (GENERIC.MP) #3: Tue Apr  6 14:47:18 CEST 2021
me@host:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34224320512 (32638MB)
avail mem = 33171423232 (31634MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xec9b0 (74 entries)
bios0: vendor American Megatrends Inc. version "3.1" date 06/07/2018
bios0: www.1he-server.com GN#15069
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI HPET MSCT NFIT SLIT SRAT 
WDDT SSDT NITR SSDT SSDT PRAD DMAR HEST BERT ERST EINJ
acpi0: wakeup devices IP2P(S4) EHC1(S4) EHC2(S4) RP01(S4) RP02(S4) RP03(S4) 
RP04(S4) RP05(S4) RP06(S4) RP07(S4) RP08(S4) BR1B(S4) BR3A(S4) BR3B(S4) 
BR3C(S4) BR3D(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, 2100.34 MHz, 06-4f-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, 2100.02 MHz, 06-4f-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, 2100.02 MHz, 06-4f-01
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, 2100.02 MHz, 06-4f-01
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 8 (application processor)
cpu4: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, 2100.02 MHz, 06-4f-01
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu4: 256KB 64b/line 8-way L2 

Re: monotonic time going back by wrong skews

2021-04-05 Thread Marcus MERIGHI
Morning!

scottchel...@gmail.com (Scott Cheloha), 2021.04.05 (Mon) 22:25 (CEST):
> To be clear, userland TSC is disabled on this machine, yes?  And this
> is a physical server, not a VM?

$ sysctl |grep tsc
kern.timecounter.hardware=tsc

Do you want me to disable this?

yasuoka@ found a dmesg with 

cpu11: disabling user TSC (skew=240)
cpu11: smt 0, core 3, package 1

from this server (on ports@). I do not see such messages in the current
dmesg.

Yes, physical server.

Marcus



Re: monotonic time going back by wrong skews

2021-04-05 Thread Marcus MERIGHI
Hello!

scottchel...@gmail.com (Scott Cheloha), 2021.03.25 (Thu) 23:28 (CET):
> Feel free to share your raw data.

I think I followed the instructions; is it expected to get a lot of

pstat: cannot read 0x9704: invalid address (9704)

and that the script takes about six minutes to run?

Anyway, data in tar.gz attached. dmesg as well.

Marcus




tsc.tar.gz
Description: application/tar-gz
OpenBSD 6.8 (GENERIC.MP) #5: Mon Feb 22 04:36:10 MST 2021

r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34224320512 (32638MB)
avail mem = 33172041728 (31635MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xec9b0 (74 entries)
bios0: vendor American Megatrends Inc. version "3.1" date 06/07/2018
bios0: www.1he-server.com GN#15069
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI HPET MSCT NFIT SLIT SRAT 
WDDT SSDT NITR SSDT SSDT PRAD DMAR HEST BERT ERST EINJ
acpi0: wakeup devices IP2P(S4) EHC1(S4) EHC2(S4) RP01(S4) RP02(S4) RP03(S4) 
RP04(S4) RP05(S4) RP06(S4) RP07(S4) RP08(S4) BR1B(S4) BR3A(S4) BR3B(S4) 
BR3C(S4) BR3D(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, 2100.31 MHz, 06-4f-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, 2100.01 MHz, 06-4f-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, 2100.01 MHz, 06-4f-01
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, 2100.01 MHz, 06-4f-01
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 8 (application processor)
cpu4: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, 2100.01 MHz, 06-4f-01
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 0, core 4, package 0
cpu5 at mainbus0: apid 10 (application processor)
cpu5: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, 2100.01 MHz, 06-4f-01
cpu5: 

Re: iwm(4) A-MSDU support

2021-03-29 Thread Marcus MERIGHI
Hello!

s...@stsp.name (Stefan Sperling), 2021.03.29 (Mon) 19:27 (CEST):
> This patch attempts to add support for receiving A-MSDUs to iwm(4).
> If you are using iwm(4) then please run with this patch and let me
> know if it causes regressions. Thanks!

no regressions with:

iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 8260" rev
0x3a, msi
iwm0: hw rev 0x200, fw ver 34.0.1, address 34:f3:9a:xx:yy:zz

thanks for all your work on wifi!

Marcus

OpenBSD 6.9-beta (GENERIC.MP) #1: Mon Mar 29 20:50:53 CEST 2021
me@myself:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 7944069120 (7576MB)
avail mem = 7687913472 (7331MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xb7058000 (65 entries)
bios0: vendor LENOVO version "N1CET81W (1.49 )" date 06/04/2020
bios0: LENOVO 20FAS06G00
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT ECDT HPET APIC MCFG SSDT DBGP DBG2 BOOT 
BATB SLIC SSDT SSDT MSDM DMAR ASF! FPDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
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-6600U CPU @ 2.60GHz, 1596.94 MHz, 06-4e-03
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 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-6600U CPU @ 2.60GHz, 1435.78 MHz, 06-4e-03
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus 2 (EXP1)
acpiprt5 at acpi0: bus -1 (EXP2)
acpiprt6 at acpi0: bus 4 (EXP3)
acpiprt7 at acpi0: bus -1 (EXP5)
acpiprt8 at acpi0: bus -1 (RP09)
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
acpibat0 at acpi0: BAT0 model "00HW023" serial   605 type LiP oem "SMP"
acpibat1 at acpi0: BAT1 model "01AV462" serial   125 type LiP oem "SMP"
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0: version 2.0
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for XHCI
acpipwrres1 at acpi0: PG00, resource for PEG0
acpipwrres2 at acpi0: PG01, resource for PEG1
acpipwrres3 at acpi0: PG02, resource for PEG2
acpipwrres4 at acpi0: WRST
acpipwrres5 at acpi0: WRST
acpitz0 at acpi0: critical temperature is 128 degC
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: using VERW MDS workaround (except on vmm entry)
cpu0: Enhanced SpeedStep 1596 MHz: speeds: 2701, 2700, 2600, 2500, 2300, 2100, 
1900, 1800, 1600, 1400, 1300, 1100, 800, 700, 600, 400 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 6G Host" rev 0x08
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 520" rev 0x07
drm0 at inteldrm0
inteldrm0: msi, SKYLAKE, gen 9
"Intel Core GMM" rev 0x00 at pci0 dev 8 function 0 not configured
xhci0 at pci0 dev 20 function 0 "Intel 100 Series xHCI" rev 0x21: msi, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 
addr 1
pchtemp0 at pci0 dev 20 function 2 "Intel 100 Series Thermal" rev 0x21

Re: relayd patch for websocket upgrade

2021-03-07 Thread Marcus MERIGHI
Hello Jonathon!

welcome to the party:

https://marc.info/?t=15833439123

especially the two comments by sthen@:

https://marc.info/?m=161349608614743
https://marc.info/?m=16135019371

reyk@ removed from CC: on purpose: 
https://twitter.com/reykfloeter/status/1284868070901776384

Marcus

jonathon.fletc...@gmail.com (Jonathon Fletcher), 2021.03.06 (Sat) 21:02 (CET):
> When relayd relays a connection upgrade to a websocket, it relays
> the outbound "Connection: Upgrade" header from the interal server.
> 
> It also tags on a "Connection: close" header to the outbound
> response - ie the response goes out with two "Connection"
> header lines.
> 
> Chrome and Netscape work despite the double upgrade/close connection 
> headers. Safari fails.
> 
> Small patch below against 6.8 to only send the "Connection: close"
> header if we are not handling a http_status 101.
> 
> Thanks,
> Jonathon
> 
> 
> cvs -q -d /cvs diff -ub -rOPENBSD_6_8 usr.sbin/relayd/relay_http.c
> 
> 
> Index: usr.sbin/relayd/relay_http.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/relay_http.c,v
> retrieving revision 1.79
> diff -u -p -u -b -r1.79 relay_http.c
> --- usr.sbin/relayd/relay_http.c  4 Sep 2020 13:09:14 -   1.79
> +++ usr.sbin/relayd/relay_http.c  6 Mar 2021 19:46:56 -
> @@ -526,7 +526,7 @@ relay_read_http(struct bufferevent *bev,
>* Ask the server to close the connection after this request
>* since we don't read any further request headers.
>*/
> - if (cre->toread == TOREAD_UNLIMITED)
> + if (cre->toread == TOREAD_UNLIMITED && desc->http_status != 101)
>   if (kv_add(>http_headers, "Connection",
>   "close", 0) == NULL)
>   goto fail;
> 



Re: [PATCH] fixes relayd Websocket "Connection: close" header when Upgrade is requested

2021-02-14 Thread Marcus MERIGHI
Another month has passed, another friendly bump...

patch against -current attached, for convenience...

Marcus

Index: relay_http.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay_http.c,v
retrieving revision 1.80
diff -u -p -u -r1.80 relay_http.c
--- relay_http.c9 Jan 2021 08:53:58 -   1.80
+++ relay_http.c14 Feb 2021 11:03:12 -
@@ -527,7 +527,7 @@ relay_read_http(struct bufferevent *bev,
 * Ask the server to close the connection after this request
 * since we don't read any further request headers.
 */
-   if (cre->toread == TOREAD_UNLIMITED)
+   if (cre->toread == TOREAD_UNLIMITED && upgrade == NULL)
if (kv_add(>http_headers, "Connection",
"close", 0) == NULL)
    goto fail;

mcmer-open...@tor.at (Marcus MERIGHI), 2021.01.04 (Mon) 12:59 (CET):
> One month has passed, this is just a friendly ping...
> 
> Marcus
> 
> mcmer-open...@tor.at (Marcus MERIGHI), 2020.12.04 (Fri) 14:18 (CET):
> > This patch wasn't commited and not discussed (publicly). 
> > 
> > It lets me use relayd as a front-end to the mattermost-server.
> > 
> > @franz: Thank you!
> > 
> > fr...@bett.ag (Franz Bettag), 2020.03.04 (Wed) 17:52 (CET):
> > > After migrating my home setup from nginx reverse proxying to relayd, i
> > > noticed my iOS devices having issues connecting through Websockets.
> > > After debugging, i noticed that relayd adds the "Connection: close"
> > > regardless of upgrade being requested.
> > > 
> > > This issue is also reported on a blog-post using relayd as a Websocket
> > > Client. https://deftly.net/posts/2019-10-23-websockets-with-relayd.html
> > > 
> > > This resulted in the response having two Connection Headers, one
> > > "Connection: upgrade" and one "Connection: close", which iOS strict
> > > implementation does not allow.
> > > 
> > > I have fixed the if condition that leads to this issue.
> > > 
> > > The fix has been tested with Apple iOS 13 and the problem can be
> > > observed using Firefox and just connecting to something Websocket over
> > > relayd. Both "Connection:" headers will appear.
> > > 
> > > best regards
> > > 
> > > Franz
> > > 
> > > 
> > > diff --git usr.sbin/relayd/relay_http.c usr.sbin/relayd/relay_http.c
> > > index 960d4c54a..3a6678790 100644
> > > --- usr.sbin/relayd/relay_http.c
> > > +++ usr.sbin/relayd/relay_http.c
> > > @@ -524,9 +524,11 @@ relay_read_http(struct bufferevent *bev, void *arg)
> > > 
> > >   /*
> > >* Ask the server to close the connection after this request
> > > -  * since we don't read any further request headers.
> > > +  * since we don't read any further request headers, unless
> > > +  * an Upgrade is requested, in which case we do NOT want to add
> > > +  * this header.
> > >*/
> > > - if (cre->toread == TOREAD_UNLIMITED)
> > > + if (cre->toread == TOREAD_UNLIMITED && upgrade == NULL)
> > >   if (kv_add(>http_headers, "Connection",
> > >   "close", 0) == NULL)
> > >   goto fail;
Index: relay_http.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay_http.c,v
retrieving revision 1.80
diff -u -p -u -r1.80 relay_http.c
--- relay_http.c9 Jan 2021 08:53:58 -   1.80
+++ relay_http.c14 Feb 2021 11:03:12 -
@@ -527,7 +527,7 @@ relay_read_http(struct bufferevent *bev,
 * Ask the server to close the connection after this request
 * since we don't read any further request headers.
 */
-   if (cre->toread == TOREAD_UNLIMITED)
+   if (cre->toread == TOREAD_UNLIMITED && upgrade == NULL)
if (kv_add(>http_headers, "Connection",
"close", 0) == NULL)
goto fail;


Re: [PATCH] fixes relayd Websocket "Connection: close" header when Upgrade is requested

2021-01-04 Thread Marcus MERIGHI
One month has passed, this is just a friendly ping...

Marcus

mcmer-open...@tor.at (Marcus MERIGHI), 2020.12.04 (Fri) 14:18 (CET):
> This patch wasn't commited and not discussed (publicly). 
> 
> It lets me use relayd as a front-end to the mattermost-server.
> 
> @franz: Thank you!
> 
> fr...@bett.ag (Franz Bettag), 2020.03.04 (Wed) 17:52 (CET):
> > After migrating my home setup from nginx reverse proxying to relayd, i
> > noticed my iOS devices having issues connecting through Websockets.
> > After debugging, i noticed that relayd adds the "Connection: close"
> > regardless of upgrade being requested.
> > 
> > This issue is also reported on a blog-post using relayd as a Websocket
> > Client. https://deftly.net/posts/2019-10-23-websockets-with-relayd.html
> > 
> > This resulted in the response having two Connection Headers, one
> > "Connection: upgrade" and one "Connection: close", which iOS strict
> > implementation does not allow.
> > 
> > I have fixed the if condition that leads to this issue.
> > 
> > The fix has been tested with Apple iOS 13 and the problem can be
> > observed using Firefox and just connecting to something Websocket over
> > relayd. Both "Connection:" headers will appear.
> > 
> > best regards
> > 
> > Franz
> > 
> > 
> > diff --git usr.sbin/relayd/relay_http.c usr.sbin/relayd/relay_http.c
> > index 960d4c54a..3a6678790 100644
> > --- usr.sbin/relayd/relay_http.c
> > +++ usr.sbin/relayd/relay_http.c
> > @@ -524,9 +524,11 @@ relay_read_http(struct bufferevent *bev, void *arg)
> > 
> > /*
> >  * Ask the server to close the connection after this request
> > -* since we don't read any further request headers.
> > +* since we don't read any further request headers, unless
> > +* an Upgrade is requested, in which case we do NOT want to add
> > +* this header.
> >  */
> > -   if (cre->toread == TOREAD_UNLIMITED)
> > +   if (cre->toread == TOREAD_UNLIMITED && upgrade == NULL)
> > if (kv_add(>http_headers, "Connection",
> > "close", 0) == NULL)
> > goto fail;
> > 



Re: [PATCH] fixes relayd Websocket "Connection: close" header when Upgrade is requested

2020-12-04 Thread Marcus MERIGHI
Hello!

This patch wasn't commited and not discussed (publicly). 

It lets me use relayd as a front-end to the mattermost-server.

Just a friendly reminder...

@franz: Thank you!

Marcus

fr...@bett.ag (Franz Bettag), 2020.03.04 (Wed) 17:52 (CET):
> After migrating my home setup from nginx reverse proxying to relayd, i
> noticed my iOS devices having issues connecting through Websockets.
> After debugging, i noticed that relayd adds the "Connection: close"
> regardless of upgrade being requested.
> 
> This issue is also reported on a blog-post using relayd as a Websocket
> Client. https://deftly.net/posts/2019-10-23-websockets-with-relayd.html
> 
> This resulted in the response having two Connection Headers, one
> "Connection: upgrade" and one "Connection: close", which iOS strict
> implementation does not allow.
> 
> I have fixed the if condition that leads to this issue.
> 
> The fix has been tested with Apple iOS 13 and the problem can be
> observed using Firefox and just connecting to something Websocket over
> relayd. Both "Connection:" headers will appear.
> 
> best regards
> 
> Franz
> 
> 
> diff --git usr.sbin/relayd/relay_http.c usr.sbin/relayd/relay_http.c
> index 960d4c54a..3a6678790 100644
> --- usr.sbin/relayd/relay_http.c
> +++ usr.sbin/relayd/relay_http.c
> @@ -524,9 +524,11 @@ relay_read_http(struct bufferevent *bev, void *arg)
> 
>   /*
>* Ask the server to close the connection after this request
> -  * since we don't read any further request headers.
> +  * since we don't read any further request headers, unless
> +  * an Upgrade is requested, in which case we do NOT want to add
> +  * this header.
>*/
> - if (cre->toread == TOREAD_UNLIMITED)
> + if (cre->toread == TOREAD_UNLIMITED && upgrade == NULL)
>   if (kv_add(>http_headers, "Connection",
>   "close", 0) == NULL)
>   goto fail;
> 



Re: Make Rockchip RK3399 eMMC faster

2020-04-24 Thread Marcus MERIGHI
mark.kette...@xs4all.nl (Mark Kettenis), 2020.04.23 (Thu) 22:56 (CEST):
> I put this in at some point since I couldn't get the eMMC on my
> firefly-rk3399 working otherwise.  But its eMMC died and on my
> rockpro64 and rk3399-q7 boards things work very well without it.  On
> the latter board it even makes things a bit speedier: the raw read
> performance goes up from 35 MB/s to 43 MB/s.
> 
> Probably good if this was tested on the pinebook pro.

running with it on pinebook pro. no problems so far. 
i (still!) run OpenBSD from sdcard (sd0). 

tested write speed to emmc (sd1) is 14M without to 16M with the patch.
observed maximum during a 1GB write with:
  dd if=/dev/zero of=/mnt/sandisk_da4064-Sandisk.g.ffs/test.file bs=1m

sorry, did not test rsd1c, because OpenBSD already sits there waiting
for me making it boot from eMMC.

thanks for you work!

marcus

dmesg diff between this kernel and the last snapshot installed:

--- dmesg.2020-04-22-18-51-1587574272   Wed Apr 22 18:51:12 2020
+++ dmesg.2020-04-24-18-49-1587746995   Fri Apr 24 18:49:55 2020
@@ -1,4 +1,4 @@
-OpenBSD 6.7-beta (GENERIC.MP) #575: Wed Apr 22 00:26:52 MDT 2020
-dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
-real mem  = 4059058176 (3871MB)
-avail mem = 3861360640 (3682MB)
+OpenBSD 6.7-beta (GENERIC.MP) #0: Fri Apr 24 18:24:05 CEST 2020
+me@myself:/usr/src/sys/arch/arm64/compile/GENERIC.MP
+real mem  = 4058992640 (3870MB)
+avail mem = 3861295104 (3682MB)
@@ -104 +103,0 @@
-"thermal-zones" at mainbus0 not configured
@@ -140 +138,0 @@
-"reserved-memory" at mainbus0 not configured
@@ -204 +202 @@
-bootfile: sd0a:/bsd
+bootfile: sd0a:bsd.emmc
@@ -214,2 +212,2 @@
-hw.sensors.rktemp0.temp0=36.25 degC (CPU)
-hw.sensors.rktemp0.temp1=34.44 degC (GPU)
+hw.sensors.rktemp0.temp0=35.62 degC (CPU)
+hw.sensors.rktemp0.temp1=33.89 degC (GPU)

full dmesg:

OpenBSD 6.7-beta (GENERIC.MP) #0: Fri Apr 24 18:24:05 CEST 2020
me@myself:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 4058992640 (3870MB)
avail mem = 3861295104 (3682MB)
mainbus0 at root: Pine64 Pinebook Pro
cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4
cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu0: 512KB 64b/line 16-way L2 cache
efi0 at mainbus0: UEFI 2.0.5
efi0: Das U-boot rev 0x0
apm0 at mainbus0
psci0 at mainbus0: PSCI 1.0
agintc0 at mainbus0 sec shift 3:4 nirq 288 nredist 6 ipi: 0, 1: 
"interrupt-controller"
agintcmsi0 at agintc0
syscon0 at mainbus0: "qos"
syscon1 at mainbus0: "qos"
syscon2 at mainbus0: "qos"
syscon3 at mainbus0: "qos"
syscon4 at mainbus0: "qos"
syscon5 at mainbus0: "qos"
syscon6 at mainbus0: "qos"
syscon7 at mainbus0: "qos"
syscon8 at mainbus0: "qos"
syscon9 at mainbus0: "qos"
syscon10 at mainbus0: "qos"
syscon11 at mainbus0: "qos"
syscon12 at mainbus0: "qos"
syscon13 at mainbus0: "qos"
syscon14 at mainbus0: "qos"
syscon15 at mainbus0: "qos"
syscon16 at mainbus0: "qos"
syscon17 at mainbus0: "qos"
syscon18 at mainbus0: "qos"
syscon19 at mainbus0: "qos"
syscon20 at mainbus0: "qos"
syscon21 at mainbus0: "qos"
syscon22 at mainbus0: "qos"
syscon23 at mainbus0: "qos"
syscon24 at mainbus0: "qos"
syscon25 at mainbus0: "power-management"
"power-controller" at syscon25 not configured
syscon26 at mainbus0: "syscon"
"io-domains" at syscon26 not configured
rkclock0 at mainbus0
rkclock1 at mainbus0
syscon27 at mainbus0: "syscon"
"io-domains" at syscon27 not configured
"usb2-phy" at syscon27 not configured
"usb2-phy" at syscon27 not configured
rkemmcphy0 at syscon27
"pcie-phy" at syscon27 not configured
rkpinctrl0 at mainbus0: "pinctrl"
rkgpio0 at rkpinctrl0
rkgpio1 at rkpinctrl0
rkgpio2 at rkpinctrl0
rkgpio3 at rkpinctrl0
rkgpio4 at rkpinctrl0
pwmreg0 at mainbus0
rkdrm0 at mainbus0
drm0 at rkdrm0
"pmu_a53" at mainbus0 not configured
"pmu_a72" at mainbus0 not configured
agtimer0 at mainbus0: tick rate 24000 KHz
"xin24m" at mainbus0 not configured
simplebus0 at mainbus0: "amba"
"dma-controller" at simplebus0 not configured
"dma-controller" at simplebus0 not configured
rkpcie0 at mainbus0
rkpcie0: link training timeout
dwmmc0 at mainbus0: 50 MHz base clock
sdmmc0 at dwmmc0: 4-bit, sd high-speed, dma
dwmmc1 at mainbus0: 50 MHz base clock
sdmmc1 at dwmmc1: 4-bit, sd high-speed, mmc high-speed, dma
sdhc0 at mainbus0
sdhc0: SDHC 3.0, 200 MHz base clock
sdmmc2 at sdhc0: 8-bit, sd high-speed, mmc high-speed, dma
ehci0 at mainbus0
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 
addr 1
ohci0 at mainbus0: version 1.0
ehci1 at mainbus0
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 
addr 1
ohci1 at mainbus0: version 1.0
rkdwusb0 at mainbus0: "usb"
xhci0 at rkdwusb0, xHCI 1.10
usb2 at xhci0: USB revision 3.0
uhub2 at usb2 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 
addr 1
rkdwusb1 at mainbus0: "usb"
xhci1 at rkdwusb1, xHCI 1.10
usb3 at xhci1: USB revision 3.0
uhub3 at usb3 

simplepanel(4) man page stub

2020-04-05 Thread Marcus MERIGHI
Hello,

reading plus.html I noticed that the link to simplepanel(4) was a dead
end.

below is my attempt at a stub man page with what I could gather from
plus.html and the commit log.

Marcus

--- /dev/null   Sun Apr  5 15:13:10 2020
+++ src/share/man/man4/simplepanel.4Sun Apr  5 15:08:52 2020
@@ -0,0 +1,38 @@
+.\" Copyright (c) 2020 Patrick Wildt 
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.Dd $Mdocdate: April 5 2020 $
+.Dt SIMPLEPANEL 4
+.Os
+.Sh NAME
+.Nm simplepanel
+.Nd simple panel display
+.Sh SYNOPSIS
+.Cd "simplepanel* at mainbus?"
+.Sh DESCRIPTION
+The
+.Nm
+driver enables the Pinebook Pro display panel.
+.Sh SEE ALSO
+.Xr mainbus 4
+.Sh HISTORY
+The
+.Nm
+driver first appeared in
+.Ox 6.7
+.Sh AUTHORS
+The
+.Nm
+driver was written by
+.An Patrick Wildt Aq Mt patr...@openbsd.org .



Re: [patch] cwm: filter duplicate hostnames in ssh menu

2019-05-13 Thread Marcus MERIGHI
inform...@gmx.net (Bruno Flueckiger), 2019.05.12 (Sun) 14:39 (CEST):
> On 01.05., Marcus MERIGHI wrote:
> > Hello,
> >
> > o...@demirmen.com (Okan Demirmen), 2019.04.29 (Mon) 16:19 (CEST):
> > > On Fri 2019.04.26 at 07:15 +0200, Bruno Fl?ckiger wrote:
> > > > Hi,
> > > >
> > > > The ssh menu of cwm(1) doesn't filter duplicated hostnames when reading
> > > > them from ~/.ssh/known_hosts. This patch makes sure each hostname is
> > > > only displayed once to the menu.
> > >
> > > Sure, maybe; but why again do we even have this inside a window manager?
> > > Really, the known_hosts parsing is incomplete at best; either the entire
> > > parsing code needs to be lifted from ssh or this (mis)feature should be
> > > removed from cwm. I prefer the latter.
> >
> > FWIW, i use "M-period" a lot... are there easy alternatives?
> >
> I use dmenu[1] from suckless.org as a replacement. The following script
> reads the host names from ~/.ssh/known_hosts, feeds them to dmenu and
> executes ssh to the host I choose in an xterm:
 
Matthias, Landry, Thuban, Bruno - Thanks for your hints!

I settled for the script below. Thanks for the blueprint, Bruno!

Marcus

#!/bin/sh -eu 
_h=$(while read _l; do print ${_l%%[ ,]*}; done < ~/.ssh/known_hosts | \
  sort -u | dmenu)
exec xterm -T "[ssh] $_h" -e "ssh $_h || read _a?'enter to continue'"



Re: [patch] cwm: filter duplicate hostnames in ssh menu

2019-05-04 Thread Marcus MERIGHI
Hello,

o...@demirmen.com (Okan Demirmen), 2019.04.29 (Mon) 16:19 (CEST):
> On Fri 2019.04.26 at 07:15 +0200, Bruno Fl?ckiger wrote:
> > Hi,
> > 
> > The ssh menu of cwm(1) doesn't filter duplicated hostnames when reading
> > them from ~/.ssh/known_hosts. This patch makes sure each hostname is
> > only displayed once to the menu.
> 
> Sure, maybe; but why again do we even have this inside a window manager?
> Really, the known_hosts parsing is incomplete at best; either the entire
> parsing code needs to be lifted from ssh or this (mis)feature should be
> removed from cwm. I prefer the latter.

FWIW, i use "M-period" a lot... are there easy alternatives?

Marcus

> > Cheers,
> > Bruno
> > 
> > 
> > Index: app/cwm/kbfunc.c
> > ===
> > RCS file: /cvs/xenocara/app/cwm/kbfunc.c,v
> > retrieving revision 1.165
> > diff -u -p -r1.165 kbfunc.c
> > --- app/cwm/kbfunc.c7 Mar 2019 14:28:17 -   1.165
> > +++ app/cwm/kbfunc.c12 Mar 2019 11:24:47 -
> > @@ -672,6 +672,7 @@ kbfunc_menu_ssh(void *ctx, struct cargs
> > 
> > lbuf = NULL;
> > len = 0;
> > +skip:
> > while ((slen = getline(, , fp)) != -1) {
> > buf = lbuf;
> > if (buf[slen - 1] == '\n')
> > @@ -686,6 +687,10 @@ kbfunc_menu_ssh(void *ctx, struct cargs
> > if (p - buf + 1 > sizeof(hostbuf))
> > continue;
> > (void)strlcpy(hostbuf, buf, p - buf + 1);
> > +   /* skip duplicate hostnames */
> > +   TAILQ_FOREACH(mi, , entry);
> > +   if (strcmp(mi->text, hostbuf) == 0)
> > +   goto skip;
> > menuq_add(, NULL, "%s", hostbuf);
> > }
> > free(lbuf);
> > 
> 



Re: acpithinkpad: a fix for the x260

2019-03-08 Thread Marcus MERIGHI
No report for x220 yet: everything works as I'm used to.

Fn+F4 suspends, Fn+F12 hibernates, Fn+Pos1 display.brightness up, 
Fn+End display.brightness down, Fn+PageUp lights up "thinklight". 

Marcus

s...@spacehopper.org (Stuart Henderson), 2019.03.07 (Thu) 14:31 (CET):
> On 2019/03/06 20:55, joshua stein wrote:
> > sthen found that the HKEY version metric failed on the x260 where it 
> > reports version 1 but requires the new ACPI method of changing 
> > backlight.
> > 
> > This diff tries to do the ACPI method on all machines and falls back 
> > to the CMOS method if that fails.
> > 
> > Can all those that tried the previous diff (which has been 
> > committed) try this one and make sure nothing broke?
> > 
> > This also unmasks the microphone mute event which helps mixerctl 
> > stay in sync on the x260 (it has no effect on my x1c6, but probably 
> > can't hurt).
> > 
> > 
> > Index: sys/dev/acpi/acpithinkpad.c
> 
> The patch in the mail doesn't apply cleanly for me due to some
> whitespace issues, if anyone else is having problems with that here's
> a regenerated version:
> 
> 
> Index: acpithinkpad.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
> retrieving revision 1.63
> diff -u -p -r1.63 acpithinkpad.c
> --- acpithinkpad.c6 Mar 2019 15:36:30 -   1.63
> +++ acpithinkpad.c7 Mar 2019 13:29:46 -
> @@ -124,6 +124,7 @@
>  #define  THINKPAD_ADAPTIVE_MODE_HOME 1
>  #define  THINKPAD_ADAPTIVE_MODE_FUNCTION 3
>  
> +#define THINKPAD_MASK_MIC_MUTE   (1 << 14)
>  #define THINKPAD_MASK_BRIGHTNESS_UP  (1 << 15)
>  #define THINKPAD_MASK_BRIGHTNESS_DOWN(1 << 16)
>  #define THINKPAD_MASK_KBD_BACKLIGHT  (1 << 17)
> @@ -171,8 +172,8 @@ int   thinkpad_get_kbd_backlight(struct ws
>  int  thinkpad_set_kbd_backlight(struct wskbd_backlight *);
>  extern int (*wskbd_get_backlight)(struct wskbd_backlight *);
>  extern int (*wskbd_set_backlight)(struct wskbd_backlight *);
> -void thinkpad_get_brightness(struct acpithinkpad_softc *);
> -void thinkpad_set_brightness(void *, int);
> +int  thinkpad_get_brightness(struct acpithinkpad_softc *);
> +int  thinkpad_set_brightness(void *, int);
>  int  thinkpad_get_param(struct wsdisplay_param *);
>  int  thinkpad_set_param(struct wsdisplay_param *);
>  extern int (*ws_get_param)(struct wsdisplay_param *);
> @@ -345,7 +346,9 @@ thinkpad_enable_events(struct acpithinkp
>   }
>  
>   /* Enable events we need to know about */
> - mask |= (THINKPAD_MASK_BRIGHTNESS_UP | THINKPAD_MASK_BRIGHTNESS_DOWN |
> + mask |= (THINKPAD_MASK_MIC_MUTE |
> + THINKPAD_MASK_BRIGHTNESS_UP |
> + THINKPAD_MASK_BRIGHTNESS_DOWN |
>   THINKPAD_MASK_KBD_BACKLIGHT);
>  
>   DPRINTF(("%s: setting event mask to 0x%llx\n", DEVNAME(sc), mask));
> @@ -555,8 +558,7 @@ thinkpad_brightness_up(struct acpithinkp
>  {
>   int b;
>  
> - if (sc->sc_hkey_version == THINKPAD_HKEY_VERSION2) {
> - thinkpad_get_brightness(sc);
> + if (thinkpad_get_brightness(sc) == 0) {
>   b = sc->sc_brightness & 0xff;
>   if (b < ((sc->sc_brightness >> 8) & 0xff)) {
>   sc->sc_brightness = b + 1;
> @@ -573,8 +575,7 @@ thinkpad_brightness_down(struct acpithin
>  {
>   int b;
>  
> - if (sc->sc_hkey_version == THINKPAD_HKEY_VERSION2) {
> - thinkpad_get_brightness(sc);
> + if (thinkpad_get_brightness(sc) == 0) {
>   b = sc->sc_brightness & 0xff;
>   if (b > 0) {
>   sc->sc_brightness = b - 1;
> @@ -701,30 +702,39 @@ thinkpad_set_kbd_backlight(struct wskbd_
>   return 0;
>  }
>  
> -void
> +int
>  thinkpad_get_brightness(struct acpithinkpad_softc *sc)
>  {
> - aml_evalinteger(sc->sc_acpi, sc->sc_devnode,
> - "PBLG", 0, NULL, >sc_brightness);
> + int ret;
> +
> + ret = aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "PBLG", 0, NULL,
> + >sc_brightness);
>  
>   DPRINTF(("%s: %s: 0x%llx\n", DEVNAME(sc), __func__, sc->sc_brightness));
> +
> + return ret;
>  }
>  
> -void
> +int
>  thinkpad_set_brightness(void *arg0, int arg1)
>  {
>   struct acpithinkpad_softc *sc = arg0;
>   struct aml_value arg;
> + int ret;
>  
>   DPRINTF(("%s: %s: 0x%llx\n", DEVNAME(sc), __func__, sc->sc_brightness));
>  
>   memset(, 0, sizeof(arg));
>   arg.type = AML_OBJTYPE_INTEGER;
>   arg.v_integer = sc->sc_brightness & 0xff;
> - aml_evalname(sc->sc_acpi, sc->sc_devnode,
> - "PBLS", 1, , NULL);
> + ret = aml_evalname(sc->sc_acpi, sc->sc_devnode, "PBLS", 1, , NULL);
> +
> + if (ret)
> + return ret;
>  
>   thinkpad_get_brightness(sc);
> +
> + return 0;
>  }
>  
>  int
> @@ -765,7 +775,8 @@ thinkpad_set_param(struct wsdisplay_para
>   dp->curval = maxval;
>   sc->sc_brightness &= ~0xff;
>   sc->sc_brightness |= dp->curval;
> 

faq16 vmm - missing "rcctl start vmd"

2018-10-29 Thread Marcus MERIGHI
Hello, 

just had a reason to spin up a vmm(4) instance and followed the new
faq16 (thanks!). One step was missing for me, patch follows.

Marcus

Index: faq16.html
===
RCS file: /cvs/www/faq/faq16.html,v
retrieving revision 1.2
diff -u -p -u -r1.2 faq16.html
--- faq16.html  25 Oct 2018 15:43:31 -  1.2
+++ faq16.html  29 Oct 2018 08:52:40 -
@@ -105,6 +105,7 @@ It will boot from the installXX.is
 
 
 # vmctl create disk.qcow2 -s 50G
+# rcctl start vmd
 # vmctl start "example" -m 1G -L -i 1 -cdrom installXX.iso -d disk.qcow2
 # vmctl show
ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME



imxiomuxc(4),imxccm(4),acpicmos(4) man pages do not exist

2018-10-16 Thread Marcus MERIGHI
hello, 

reading plus64.html I saw the links to imxiomuxc(4), imxccm(4) and
acpicmos(4) did not give results; man -k agrees.

I would have sent man page drafts if I knew what these devices are.
The CVS commit messages did not help. 

Therefore this is just a reminder, sorry.

Marcus



www/64.html stray word, missing links

2018-10-16 Thread Marcus MERIGHI
Hello, 

thanks for all the work!

Just an extra "and" left behind. And some missing links. 

Yeehaa, console scrollback is back!

Marcus

Index: 64.html
===
RCS file: /cvs/www/64.html,v
retrieving revision 1.79
diff -u -p -r1.79 64.html
--- 64.html 16 Oct 2018 08:13:58 -  1.79
+++ 64.html 16 Oct 2018 15:58:23 -
@@ -253,7 +253,7 @@ to 6.4.
 information speculatively leaking across protection boundaries.
 Because Simultaneous MultiThreading (SMT) uses core resources in
 a shared and unsafe manner, it is now disabled by default.
-It and can be enabled with the new hw.smt
+It can be enabled with the new hw.smt
 https://man.openbsd.org/sysctl.2;>sysctl(2) variable.
 Audio recording is now disabled by default and can be enabled
 with the new kern.audio.record
@@ -275,8 +275,9 @@ to 6.4.
 bound into an alternate routing domain.
 https://man.openbsd.org/ospf6d.8;>ospf6d(8) is
 now pledged.
-Prevent ospfd(8) and ospf6d(8) from being started more than once
-(in the same routing domain).
+Prevent https://man.openbsd.org/ospfd.8;>ospfd(8) and 
+https://man.openbsd.org/ospf6d.8;>ospf6d(8) from being 
+started more than once (in the same routing domain).
 https://man.openbsd.org/slaacd.8;>slaacd(8) is now fully
 pledged.
 https://man.openbsd.org/slaacd.8;>slaacd(8) is informed by



Re: update ifstated parser

2018-08-25 Thread Marcus MERIGHI
Hello, 

cleaning up my inbox I stumbled over this, it would be handy, still
applies and compiles. 

But... it does not like my config when running "ifstated -n -v -f
/etc/ifstated.conf", as opposed to ifstated *before* the patch.

part of /etc/ifstated.conf

init-state auto
wireif = 'em0'
waveif = 'iwn0'
wire_act = '( "ifconfig wire | grep -q \"status: active$\"" every 10 )'
wave_act = '( "ifconfig wlan | grep -q \"status: active$\"" every 10 )'

output of "ifstated -n -v -f /etc/ifstated.conf"

wireif = "em0"
waveif = "iwn0"
/etc/ifstated.conf:6: macro '( "ifconfig wire | grep -q \"status:
active\' not defined
/etc/ifstated.conf:6: syntax error

Is there anything I can do apart from learning C?

BTW, rob@'s ifstated.conf.5 clarification was commited, thus
documentation and reality are aligned.

Marcus

r...@2keys.ca (Rob Pierce), 2018.03.05 (Mon) 19:55 (CET):
> On Mon, Feb 26, 2018 at 05:10:43PM -0600, Michael Graves wrote:
> > Hello
> > 
> > I use ifstated(8) to track the state of the the external interface that is
> > configured via dhcp and based upon the state, (re)configure a VXLAN
> > interface.
> > The ifstated.conf currently looks like
> > 
> > ===
> > exif="em0"
> > vxif="vxlan0"
> > 
> > init-state state_down
> > 
> > state state_up {
> >   init {
> > run "ifconfig vlxna0 up"
> >   }
> >   if ( "ifconfig em0 | grep -q inet" every 60 )
> > run "sleep 30 && ifconfig vxlan0 tunnel `ifconfig em0 | \
> >  sed -nre 's/.*inet ([^ ]+).*/\1/p'` \
> > `dig +short name-of-remote-device`"
> >   if $exif.link.down
> > set-state state_down
> > }
> > 
> > state state_down {
> >   init {
> > run "ifconfig vxlan0 down"
> >   }
> >   if $exif.link.up
> > set-state state_up
> > }
> > ===
> > 
> > The problem I ran into is that when I tried to substitute the vxlan0 and em0
> > entries with exif and vxif in the 'run' statements no macro expansion
> > occurred.
> > This patch allows macro expansion within the 'run' and 'if' statements.
> > 
> > I appreciate any feedback.
> > Regards
> 
> > Index: parse.y
> > ===
> > RCS file: /cvs/src/usr.sbin/ifstated/parse.y,v
> > retrieving revision 1.47
> > diff -u -p -r1.47 parse.y
> > --- parse.y 21 Aug 2017 17:38:55 -  1.47
> > +++ parse.y 26 Feb 2018 22:47:11 -
> > @@ -509,9 +509,10 @@ int
> >  yylex(void)
> >  {
> > u_char   buf[8096];
> > -   u_char  *p, *val;
> > +   u_char  *p, *p1, *val;
> > int  quotec, next, c;
> > int  token;
> > +   size_t  x;
> >  
> >  top:
> > p = buf;
> > @@ -575,6 +576,35 @@ top:
> > } else if (c == '\0') {
> > yyerror("syntax error");
> > return (findeol());
> > +   } else if (c == '$') {
> > +   p1 = p;
> > +   while (1) {
> > +   if ((c = lgetc(0)) == EOF)
> > +   return (0);
> > +   if (p1 + 1 >= buf + sizeof(buf) - 1) {
> > +   yyerror("string too long");
> > +   return (findeol());
> > +   }
> > +   if (isalnum(c) || c == '_') {
> > +   *p1++ = c;
> > +   continue;
> > +   }
> > +   *p1 = '\0';
> > +   lungetc(c);
> > +   break;
> > +   }
> > +   val = symget(p);
> > +   if (val == NULL) {
> > +   yyerror("macro '%s' not defined", buf);
> > +   return (findeol());
> > +   }
> > +   x = strlcpy(p,val,(buf-p));
> > +   if (x >= (buf-p)) {
> > +   yyerror("string too long");
> > +   return (findeol());
> > +   }
> > +   p += x;
> > +   continue;
> > }
> > if (p + 1 >= buf + sizeof(buf) - 1) {
> > yyerror("string too long");
> 
> Hey Michael,
> 
> Thank you for your email. I have been playing with your diff and will send you
> some comments shortly. This might be worth future consideration.
> 
> For now, I think we should update the man page to clearly state that macro
> expansion does not take place inside quotes as is currently done in the other
> man pages.
> 
> Ok?
> 
> Index: ifstated.conf.5
> ===
> RCS file: 

systat.1 bar graph - add lockspin "@"

2018-07-23 Thread Marcus MERIGHI
I've noticed that systat(1), in the CPU bar graph, shows "@"s, which
aren't explained in systat(1). I went looking and found:


src/sys/sys/sched.h
revision 1.45
date: 2018/05/14 12:31:21;  author: mpi;  state: Exp;  lines: +9 -12;
  commitid: NO9HXG6NFNz3ttlB;
Stopping counting and reporting CPU time spent spinning on a lock as
system time.

Introduce a new CP_SPIN "scheduler state" and modify userland tools
to display the % of timer a CPU spents spinning.

Based on a diff from jmatthew@, ok pirofti@, bluhm@, visa@, deraadt@


I've just tried to apply mpi@'s words, see below.

Marcus

Index: systat.1
===
RCS file: /cvs/src/usr.bin/systat/systat.1,v
retrieving revision 1.109
diff -u -p -u -r1.109 systat.1
--- systat.18 Jul 2018 13:23:57 -   1.109
+++ systat.123 Jul 2018 08:00:34 -
@@ -460,6 +460,8 @@ Below the queue length listing is a nume
 a bar graph showing the amount of
 interrupt (shown as
 .Ql | ) ,
+lockspin (shown as
+.Ql @ ) ,
 system (shown as
 .Ql = ) ,
 user (shown as



systat(1) iostat vs. iostat(1)

2018-07-07 Thread Marcus MERIGHI
Hello, 

when I run 'iostat(1) sd1 1' I get the transfer speed in MB/s. Running
'systat(1) iostat 1' in parallel I get the transfer speed in bytes, as
calculations show. Therefore adjust the manual of systat(1): 
kilobytes -> bytes.

Marcus

Index: systat.1
===
RCS file: /cvs/src/usr.bin/systat/systat.1,v
retrieving revision 1.106
diff -u -p -u -r1.106 systat.1
--- systat.130 May 2018 13:53:09 -  1.106
+++ systat.17 Jul 2018 06:20:03 -
@@ -293,7 +293,7 @@ this is the default.
 .It Ic iostat
 Display statistics about disk throughput.
 Statistics
-on disk throughput show, for each drive, data transferred in kilobytes,
+on disk throughput show, for each drive, data transferred in bytes,
 number of disk transactions performed, and time spent in disk accesses
 (in fractions of a second).
 .It Ic malloc



hppa.html broken link, fix

2018-05-21 Thread Marcus MERIGHI
Now that hppa is mentioned every day...

Index: hppa.html
===
RCS file: /cvs/www/hppa.html,v
retrieving revision 1.274
diff -u -p -u -r1.274 hppa.html
--- hppa.html   2 Apr 2018 02:48:19 -   1.274
+++ hppa.html   21 May 2018 11:37:44 -
@@ -47,7 +47,7 @@ Others are definitely welcome to contrib
 
 This project was started in those days when the only
 open source operating systems for HP PA-RISC computers were
-http://www.cs.utah.edu/projects/flux/lites/html;>Lites and
+http://www.cs.utah.edu/flux/lites/html;>Lites and
 http://www.mklinux.org;>MkLinux.
 These two sources were a major supply of information and
 code for initial development of the OpenBSD/hppa port.



relayd(8) relay_http.c comment RFC 7230 3.3.3 -> 3.3.2

2017-08-18 Thread Marcus MERIGHI
Hello, 

trying to get www/sogo (caldav/carddav server) to run behind relayd I
found relayd(8) is dropping responses of Code 204 (No Content) IF they
have a Content-Lenght header. 

This is on purpose as the code (relay_http.c, 329) has this comment:
* response with a status code of 1xx
* (Informational) or 204 (No Content) MUST
* not have a Content-Length (rfc 7230 3.3.3)

I could not find this MUST within section 3.3.3.
It took some reading until I found that it is actually in

3.3.2.  Content-Length
   [...]
   A server MUST NOT send a Content-Length header field in any response
   with a status code of 1xx (Informational) or 204 (No Content).  A
   server MUST NOT send a Content-Length header field in any 2xx
   (Successful) response to a CONNECT request (Section 4.3.6 of
   [RFC7231]).

OpenBSD does the right thing, thanks!

Marcus


Index: relay_http.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay_http.c,v
retrieving revision 1.66
diff -u -p -u -r1.66 relay_http.c
--- relay_http.c28 May 2017 10:39:15 -  1.66
+++ relay_http.c18 Aug 2017 13:03:42 -
@@ -324,7 +324,7 @@ relay_read_http(struct bufferevent *bev,
/*
 * response with a status code of 1xx
 * (Informational) or 204 (No Content) MUST
-* not have a Content-Length (rfc 7230 3.3.3)
+* not have a Content-Length (rfc 7230 3.3.2, p.30)
 */
if (desc->http_method == HTTP_METHOD_RESPONSE && (
((desc->http_status >= 100 &&



Re: Let inteldrm(4) publish a backlight property

2017-07-10 Thread Marcus MERIGHI
mark.kette...@xs4all.nl (Mark Kettenis), 2017.07.09 (Sun) 23:41 (CEST):
> Diff below publishes a "Backlight" property that can be used to get
> and set the backlight associated with a particular output.  This
> property can easily be exported by the X11 graphics drivers trough the
> RandR protocol.  A future diff will let the "modesetting" driver do
> this and make xbacklight(1) work.

xbacklight(1) works again, though I did not expect that after reading
your message above.

I used the snapshot "#93: Thu Jul  6 15:41:21 MDT 2017", updated src,
applied your patch and compiled/installed/booted kernel.  

BTW, I noticed that xrandr outputs were formerly named like "LVDS1", now
they follow the format of "LVDS-1". Is this part of the inteldrm changes
and is going to stay?

Thanks! Marcus

> Index: dev/pci/drm/drm_crtc.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_crtc.c,v
> retrieving revision 1.25
> diff -u -p -r1.25 drm_crtc.c
> --- dev/pci/drm/drm_crtc.c1 Jul 2017 16:00:25 -   1.25
> +++ dev/pci/drm/drm_crtc.c9 Jul 2017 21:32:53 -
> @@ -4049,6 +4049,23 @@ int drm_object_property_get_value(struct
>  {
>   int i;
>  
> +#ifdef __OpenBSD__
> + if (obj->type == DRM_MODE_OBJECT_CONNECTOR) {
> + struct drm_connector *connector = obj_to_connector(obj);
> +
> + if (property == connector->backlight_property) {
> + struct backlight_device *bd =
> + connector->backlight_device;
> +
> + if (bd->props.type == BACKLIGHT_FIRMWARE)
> + *val = bd->ops->get_brightness(bd);
> + else
> + *val = bd->props.brightness;
> + return 0;
> + }
> + }
> +#endif
> +
>   /* read-only properties bypass atomic mechanism and still store
>* their value in obj->properties->values[].. mostly to avoid
>* having to deal w/ EDID and similar props in atomic paths:
> @@ -4840,6 +4857,12 @@ static int drm_mode_connector_set_obj_pr
>   ret = 0;
>   if (connector->funcs->dpms)
>   ret = (*connector->funcs->dpms)(connector, (int)value);
> +#ifdef __OpenBSD__
> + } else if (property == connector->backlight_property) {
> + ret = 0;
> + connector->backlight_device->props.brightness = value;
> + backlight_schedule_update_status(connector->backlight_device);
> +#endif
>   } else if (connector->funcs->set_property)
>   ret = connector->funcs->set_property(connector, property, 
> value);
>  
> Index: dev/pci/drm/drm_crtc.h
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_crtc.h,v
> retrieving revision 1.10
> diff -u -p -r1.10 drm_crtc.h
> --- dev/pci/drm/drm_crtc.h1 Jul 2017 16:00:25 -   1.10
> +++ dev/pci/drm/drm_crtc.h9 Jul 2017 21:32:54 -
> @@ -741,6 +741,11 @@ struct drm_connector {
>   uint8_t num_h_tile, num_v_tile;
>   uint8_t tile_h_loc, tile_v_loc;
>   uint16_t tile_h_size, tile_v_size;
> +
> +#ifdef __OpenBSD__
> + struct backlight_device *backlight_device;
> + struct drm_property *backlight_property;
> +#endif
>  };
>  
>  /**
> Index: dev/pci/drm/drm_linux.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_linux.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 drm_linux.c
> --- dev/pci/drm/drm_linux.c   5 Jul 2017 20:30:13 -   1.14
> +++ dev/pci/drm/drm_linux.c   9 Jul 2017 21:32:54 -
> @@ -697,6 +697,12 @@ acpi_get_table_with_size(const char *sig
>  
>  #endif
>  
> +void
> +backlight_do_update_status(void *arg)
> +{
> + backlight_update_status(arg);
> +}
> +
>  struct backlight_device *
>  backlight_device_register(const char *name, void *kdev, void *data,
>  const struct backlight_ops *ops, struct backlight_properties *props)
> @@ -707,6 +713,8 @@ backlight_device_register(const char *na
>   bd->ops = ops;
>   bd->props = *props;
>   bd->data = data;
> +
> + task_set(>task, backlight_do_update_status, bd);
>   
>   return bd;
>  }
> @@ -715,4 +723,10 @@ void
>  backlight_device_unregister(struct backlight_device *bd)
>  {
>   free(bd, M_DRM, sizeof(*bd));
> +}
> +
> +void
> +backlight_schedule_update_status(struct backlight_device *bd)
> +{
> + task_add(systq, >task);
>  }
> Index: dev/pci/drm/drm_linux.h
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_linux.h,v
> retrieving revision 1.53
> diff -u -p -r1.53 drm_linux.h
> --- dev/pci/drm/drm_linux.h   5 Jul 2017 20:30:13 -   1.53
> +++ dev/pci/drm/drm_linux.h   9 Jul 2017 21:32:54 -
> @@ -1917,12 +1917,14 @@ struct backlight_ops {
>  struct backlight_device {
>   const struct backlight_ops 

www/60.html missing "syncachelimit"

2016-08-12 Thread Marcus MERIGHI
someone once said tech@ is where patches go and www@ is no longer
there...

Bye, Marcus

Index: 60.html
===
RCS file: /cvs/www/60.html,v
retrieving revision 1.47
diff -u -p -u -r1.47 60.html
--- 60.html 10 Aug 2016 13:49:33 -  1.47
+++ 60.html 12 Aug 2016 16:44:51 -
@@ -244,7 +244,7 @@ to 6.0.
 -s -p tcp shows the relevant information to tune
 the SYN cache with
 http://man.openbsd.org/sysctl.8;>sysctl(8)
-net.inet.tcp.
+net.inet.tcp.syncachelimit.
 The administrator can require root privileges for binding to some TCP
and UDP ports with
http://man.openbsd.org/sysctl.8;>sysctl(8)



Re: umb(4) attachment

2016-06-18 Thread Marcus MERIGHI
Hello, 

the kernel does not compile for me with this patch. 

src/sys/dev/usb/usb.h is missing UISUBCLASS_NETWORK_CONTROL_MODEL. 

What value does it need?

(I get no umb(4) device with a value of 15. Am I supposed to get one
with this hardware and the correct value?)

One OT GPS question below, lsusb -v + dmesg as well.

mark.kette...@xs4all.nl (Mark Kettenis), 2016.06.17 (Fri) 22:22 (CEST):
> As reported earlier, umb(4) currently doesn't attach to devices that
> implement both NCM 1.0 and MBIM, such as the Sierra Wireless EM7345
> that is found in some thinkpads.
> 
> The diff below fixes this.  It revamps the way we look up interface
> descriptors quite a bit.  I removed the unused code for matching
> devices based on vendor and product ids.  That code got a bit in my
> way.  It should be possible to bring that back if needed.
> 
> With this fix, the EM7345 attaches as:
> 
> umb0 at uhub0 port 4 configuration 1 interface 0 "Sierra Wireless Inc. Sierra 
> Wi
> reless EM7345 4G LTE" rev 2.00/17.29 addr 2
> umb0: ignoring invalid segment size 1500
> umb0: vers 1.0
> umodem0 at uhub0 port 4 configuration 1 interface 2 "Sierra Wireless Inc. 
> Sierra Wireless EM7345 4G LTE" rev 2.00/17.29 addr 2
> umodem0: data interface 3, has no CM over data, has break
> umodem0: status change notification available
> ucom0 at umodem0
> 
> Note that it still attaches as umodem(4) as well.  That is actually a
> good thing since it allows me to read out the GPS though that interface.

My /dev/cuaU? all respond to at -> OK. How do you get the GPS data?

> I believe this code should work on all devices that are properly MBIM
> compliant.  But of course vendors are notoriously sloppy in providing
> the right usb interface descriptors for their devices.  So testing is
> welcome.  If you run into issues, please provide lsusb -v output.


Bus 000 Device 001: ID 8086: Intel Corp. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize064
  idVendor   0x8086 Intel Corp.
  idProduct  0x 
  bcdDevice1.00
  iManufacturer   1 Intel
  iProduct2 EHCI root hub
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x40
  (Missing must-be-set bit!)
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  12
Hub Descriptor:
  bLength  10
  bDescriptorType  41
  nNbrPorts 3
  wHubCharacteristic 0x0002
No power switching (usb 1.0)
Ganged overcurrent protection
TT think time 8 FS bits
  bPwrOn2PwrGood  200 * 2 milli seconds
  bHubContrCurrent  0 milli Ampere
  DeviceRemovable0x00
  PortPwrCtrlMask0x00
 Hub Port Status:
   Port 1: .0503 highspeed power enable connect
   Port 2: .0500 highspeed power
   Port 3: .0500 highspeed power
Device Status: 0x0001
  Self Powered

Bus 000 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize064
  idVendor   0x8087 Intel Corp.
  idProduct  0x0024 Integrated Rate Matching Hub
  bcdDevice0.00
  iManufacturer   0 
  iProduct0 
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
 

Re: iwn(4) HT protection updates

2016-06-03 Thread Marcus MERIGHI
s...@stsp.name (Stefan Sperling), 2016.06.03 (Fri) 17:27 (CEST):
> On Fri, Jun 03, 2016 at 04:54:13PM +0200, Marcus MERIGHI wrote:
> > s...@stsp.name (Stefan Sperling), 2016.06.03 (Fri) 11:19 (CEST):
> > > Currently, iwn(4) does not track HT protection changes because the
> > > support code was broken and hence disabled.
> > > 
> > > Here's a fixed version which should allow us to enable HT protection
> > > updates again.
> > 
> > I'm not sure this was a call for testing. If it was:
> > 
> > Works here and I see no change in behavior. 

short: My gut feeling and tcpbench do not see a loss of quality. 
 
what I did: restart; start tcpdump and tcpbench; config iwn0; start
tcpdump; check netstat/tcpbench; insert/config run0; check
netstat/tcpbench; insert/config urtwn0; check netstat/tcpbench; stop
tcpdump; stop tcpbench; run tcpdump -r ... | grep ... | wc -l. 

I saved the tcpdump and a more detailed report in case you want it. 

> How many 'HT protection changes' are counted in 'netstat -W iwn0'?

First '0' (only iwn0). Then '1' after I added run0 and it stayed there
after a added urtwn0 (hey, another five-letter device :-).
Though now it's at 2, about half an hour later.

> While associated, the current protection mode can be seen with tcpdump:
> tcpdump -n -i iwn0 -s 4096 -y IEEE802_11_RADIO -vv subtype beacon 
> In the 'htop=' field, look for any of these strings:

Thanks for the instructions!
after testing it showed the following number of lines:

>   protect non-member

3649

>   protect 20MHz

0

>   protect non-HT

7895

> If none of those is printed, HT protection is disabled.
> An 11g device on the channel will always force it to "protect non-HT".
> 
> To trigger a change, try associating an additional 11g device to your AP
> while already associated with iwn0 in 11n mode.
> The counter in netstat -W iwn0 should go up, unless you already had 11g
> clients on the same channel because then protection settings won't change.
> If it's always "protect non-HT", you might have more luck after setting
> the AP to a different channel where no 11g client exists.
> 
> The question is:
> Does an HT protection change affect the quality of your iwn0 wifi connection?
> It should not.

My gut feeling and tcpbench do not see a loss of quality. 

Thank you once more, Marcus



Re: iwn(4) HT protection updates

2016-06-03 Thread Marcus MERIGHI
s...@stsp.name (Stefan Sperling), 2016.06.03 (Fri) 11:19 (CEST):
> Currently, iwn(4) does not track HT protection changes because the
> support code was broken and hence disabled.
> 
> Here's a fixed version which should allow us to enable HT protection
> updates again.

I'm not sure this was a call for testing. If it was:

Works here and I see no change in behavior. 

(under kernel #2165: cvs up, apply patch, config, make, move, boot)

lenovo x200s

iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5300" rev 0x00: msi, MIMO
  3T3R, MoW, address 00:21:6a:xx:yy:zz

iwn0: flags=8843 mtu 1500
lladdr 00:21:6a:xx:yy:zz
index 2 priority 4
groups: wlan egress
media: IEEE802.11 autoselect (HT-MCS7 mode 11n)
status: active
ieee80211: nwid foobar chan 6 bssid e2:46:9a:8c:59:c8 -51dBm
  wpakey  wpaprotos wpa1,wpa2 wpaakms psk
  wpaciphers tkip,ccmp wpagroupcipher tkip
inet 192.168.188.128 netmask 0xff00 broadcast
  192.168.188.255

OpenBSD 6.0-beta (GENERIC.MP) #11: Fri Jun  3 16:38:17 CEST 2016
foo@bar:/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4166717440 (3973MB)
avail mem = 4035948544 (3848MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
bios0: vendor LENOVO version "6DET72WW (3.22 )" date 10/25/2012
bios0: LENOVO 7470W1W
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT
  TCPA DMAR SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4)
  EXP2(S4) EXP3(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU L9400 @ 1.86GHz, 1862.26 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 6MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 265MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU L9400 @ 1.86GHz, 1862.00 MHz
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 6MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus -1 (EXP2)
acpiprt5 at acpi0: bus 5 (EXP3)
acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB3, USB5, EHC0, EHC1
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 104 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
"PNP0303" at acpi0 not configured
"IBM3780" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "93P5030" serial   165 type LION oem "SANYO"
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
"PNP0C14" at acpi0 not configured
acpidock0 at acpi0: GDCK not docked (0)
acpivideo0 at acpi0: VID_
acpivout0 at acpivideo0: LCD0
acpivideo1 at acpi0: VID_
cpu0: Enhanced SpeedStep 1862 MHz: speeds: 1867, 1866, 1600, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: msi
inteldrm0: 1280x800
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
"Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 
00:1f:16:32:df:5c
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 22
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 

add EdgeRouter Pro to www/octeon.html

2016-03-19 Thread Marcus MERIGHI
Hello,

"The patch seems to work fine on an EdgeRouter Pro.
OK visa@"
(http://marc.info/?l=openbsd-tech=145822792814191)

EdgeRouter Pro is not on octeon.html, put it there?

Bye, Marcus

Index: octeon.html
===
RCS file: /cvs/www/octeon.html,v
retrieving revision 1.27
diff -u -p -u -r1.27 octeon.html
--- octeon.html 13 Jan 2016 14:25:49 -  1.27
+++ octeon.html 18 Mar 2016 07:39:28 -
@@ -70,7 +70,8 @@ Portwell CAM-0100
 http://www.ubnt.com/edgemax/edgerouter-lite/;>Ubiquiti Networks
 EdgeRouter LITE
 http://www.ubnt.com/edgemax/edgerouter-poe/;>Ubiquiti Networks
-EdgeRouter PoE
+http://www.ubnt.com/edgemax/edgerouter-pro/;>Ubiquiti Networks
+EdgeRouter Pro
 
 
 



smtpd.conf(5) term filter misleading use

2016-01-02 Thread Marcus MERIGHI
When the text is not talking about filters, but about accept/reject
rules and using the term "filter", try to find some other wording.

Bye, Marcus


Index: smtpd.conf.5
===
RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v
retrieving revision 1.148
diff -u -p -u -r1.148 smtpd.conf.5
--- smtpd.conf.522 Dec 2015 20:59:14 -  1.148
+++ smtpd.conf.52 Jan 2016 17:24:32 -
@@ -74,7 +74,7 @@ accepts and rejects messages
 based on information gathered during the SMTP session.
 .Pp
 For each message processed by the daemon,
-the filter rules are evaluated in sequential order,
+the rules are evaluated in sequential order,
 from first to last.
 The first matching rule decides what action is taken.
 If no rule matches the message,
@@ -93,7 +93,7 @@ If specified, the rule will only be matc
 .Ar tag .
 .El
 .Pp
-After that the client's IP address filter is specified:
+After that the client's IP address rule is specified:
 .Bl -tag -width Ds
 .It Ic from any
 Make the rule match regardless of the IP of connecting client.
@@ -116,7 +116,7 @@ is declared in the table
 .Ar table .
 .El
 .Pp
-In addition, finer filtering may be achieved on the sender if desired:
+In addition, finer access control may be achieved on the sender if desired:
 .Bl -tag -width Ds
 .It Xo
 .Ic sender
@@ -247,7 +247,7 @@ The
 table will be used as the virtual domain mapping.
 .El
 .Pp
-Further filtering may be achieved on specific recipients if desired:
+Further access control may be achieved on specific recipients if desired:
 .Bl -tag -width Ds
 .It Xo
 .Ic recipient



Re: Thinkpad display brightness control

2015-12-21 Thread Marcus MERIGHI
Please disregard my message below, sorry for the noise.

The facts are wrong, I'm still having those plug/unplug brightness
jumps. (no idea what coincidence took place yesterday.)

Sorry, Marcus

mcmer-open...@tor.at (Marcus MERIGHI), 2015.12.20 (Sun) 16:04 (CET):
> I am somewhat confused; there were two recent changes that might cause
> the improvement:
> 
> - tedu@ 2015-12-16 acpi/dsdt.c
> - kettenis@ 2015-12-17 acpi/acpithinkpad.c
> 
> since tedu@s commit was inspired by kettenis@ I reply to this thread.
> 
> mark.kette...@xs4all.nl (Mark Kettenis), 2015.12.16 (Wed) 19:48 (CET):
> > Most, if not all, somewhat recent Thinkpads have some subtle issues
> > with display brightness control.  For example,if you change the
> > display brightness using wsconsctl(8) or cbacklight(1), and later use
> > the brightness control buttons on the keyboard, you're likely to see a
> > big jump in brightness.  or if you plug or unplug the power, the
> > display brightness will suddenly change.  The problem here is that on
> 
> hw.version=ThinkPad X200s
> 
> plug/unplug brightness jumps are gone, thank you!
> 
> But:
> - I cannot reach 100% with Fn+PgUp. 
> - Fn+PgUp/PgDown does not care about what I've set via software
>   (wsconsctl display.brightness=XYZ). It always changes based on the
>   value set by the last Fn+PgUp/PgDown, regardless of display.brightness
>   settings.
> 
> Thanks, Marcus
> 
> OpenBSD 5.8-current (GENERIC.MP) #1757: Sat Dec 19 08:17:18 MST 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4166717440 (3973MB)
> avail mem = 4036304896 (3849MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
> bios0: vendor LENOVO version "6DET72WW (3.22 )" date 10/25/2012
> bios0: LENOVO 7470W1W
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA 
> DMAR SSDT SSDT SSDT
> acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) 
> EXP3(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM)2 Duo CPU L9400 @ 1.86GHz, 1862.25 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
> cpu0: 6MB 64b/line 16-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
> cpu0: apic clock running at 265MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM)2 Duo CPU L9400 @ 1.86GHz, 1862.00 MHz
> 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
> cpu1: 6MB 64b/line 16-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
> ioapic0: misconfigured as apic 2, remapped to apid 1
> acpimcfg0 at acpi0 addr 0xe000, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (AGP_)
> acpiprt2 at acpi0: bus 2 (EXP0)
> acpiprt3 at acpi0: bus 3 (EXP1)
> acpiprt4 at acpi0: bus -1 (EXP2)
> acpiprt5 at acpi0: bus 5 (EXP3)
> acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: PUBS, resource for USB0, USB3, USB5, EHC0, EHC1
> acpitz0 at acpi0: critical temperature is 127 degC
> acpitz1 at acpi0: critical temperature is 104 degC
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: SLPB
> acpibat0 at acpi0: BAT0 model "93P5030" serial   165 type LION oem "SANYO"
> acpibat1 at acpi0: BAT1 not present
> acpiac0 at acpi0: AC unit online
> acpithinkpad0 at acpi0
> acpidock0 at acpi0: GDCK not docked (0)
> cpu0: Enhanced SpeedStep 1862 MHz: speeds: 1867, 1866, 1600, 800 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
> inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
> drm0 at inteldrm0
> intagp0 at inteldrm0
> agp0 at intagp0: aperture at 0xd000, size 0x1000
> inteldrm0: msi
> inte

Re: initial 11n support for iwn (n, not m)

2015-12-21 Thread Marcus MERIGHI
s...@stsp.name (Stefan Sperling), 2015.12.20 (Sun) 19:59 (CET):
> On Sat, Dec 19, 2015 at 01:08:26PM +0100, Stefan Sperling wrote:
> > On Fri, Dec 18, 2015 at 05:40:39PM -0500, David Hill wrote:
> > > With sthen@'s patch I can associate, dhcp, and use net.
> > 
> > Here's an updated iwn diff with a better approach for Stuart's fix.
> > 
> > Thanks for helping, Stuart, and to everyone who sent beacons which
> > allowed us to narrow this problem down to protection settings being
> > set up the wrong way in iwn_run().
> 
> And another update (hopefully) fixing some reported issues, with some
> uncommitted net80211 changes included.
> 
> I haven't put these diffs in yet because I'm still hearing about regressions
> in some form or another. Sometimes it's unclear what people are running,
> so I hope this version will linger for a bit and get tested.
> Thanks for all the help so far from more people than I expected!

my iwn works:

iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5300" rev 0x00: msi, MIMO
  3T3R, MoW
media: IEEE802.11 autoselect (HT-MCS7 mode 11n)
status: active

Thanks again, Stefan!

OpenBSD 5.9-beta (GENERIC.MP) #1: Mon Dec 21 13:49:20 CET 2015
fifi@fofo:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4166717440 (3973MB)
avail mem = 4036313088 (3849MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
bios0: vendor LENOVO version "6DET72WW (3.22 )" date 10/25/2012
bios0: LENOVO 7470W1W
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR 
SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) 
EXP3(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU L9400 @ 1.86GHz, 1862.32 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 6MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 265MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU L9400 @ 1.86GHz, 1862.00 MHz
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 6MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus -1 (EXP2)
acpiprt5 at acpi0: bus 5 (EXP3)
acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB3, USB5, EHC0, EHC1
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 104 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "93P5030" serial   165 type LION oem "SANYO"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
cpu0: Enhanced SpeedStep 1862 MHz: speeds: 1867, 1866, 1600, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: msi
inteldrm0: 1280x800
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
"Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 
00:1f:16:32:df:5c
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 22
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 

Re: Thinkpad display brightness control

2015-12-20 Thread Marcus MERIGHI
I am somewhat confused; there were two recent changes that might cause
the improvement:

- tedu@ 2015-12-16 acpi/dsdt.c
- kettenis@ 2015-12-17 acpi/acpithinkpad.c

since tedu@s commit was inspired by kettenis@ I reply to this thread.

mark.kette...@xs4all.nl (Mark Kettenis), 2015.12.16 (Wed) 19:48 (CET):
> Most, if not all, somewhat recent Thinkpads have some subtle issues
> with display brightness control.  For example,if you change the
> display brightness using wsconsctl(8) or cbacklight(1), and later use
> the brightness control buttons on the keyboard, you're likely to see a
> big jump in brightness.  or if you plug or unplug the power, the
> display brightness will suddenly change.  The problem here is that on

hw.version=ThinkPad X200s

plug/unplug brightness jumps are gone, thank you!

But:
- I cannot reach 100% with Fn+PgUp. 
- Fn+PgUp/PgDown does not care about what I've set via software
  (wsconsctl display.brightness=XYZ). It always changes based on the
  value set by the last Fn+PgUp/PgDown, regardless of display.brightness
  settings.

Thanks, Marcus

OpenBSD 5.8-current (GENERIC.MP) #1757: Sat Dec 19 08:17:18 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4166717440 (3973MB)
avail mem = 4036304896 (3849MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
bios0: vendor LENOVO version "6DET72WW (3.22 )" date 10/25/2012
bios0: LENOVO 7470W1W
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR 
SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) 
EXP3(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU L9400 @ 1.86GHz, 1862.25 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 6MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 265MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU L9400 @ 1.86GHz, 1862.00 MHz
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 6MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus -1 (EXP2)
acpiprt5 at acpi0: bus 5 (EXP3)
acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB3, USB5, EHC0, EHC1
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 104 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "93P5030" serial   165 type LION oem "SANYO"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
cpu0: Enhanced SpeedStep 1862 MHz: speeds: 1867, 1866, 1600, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: msi
inteldrm0: 1280x800
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
"Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 
00:1f:16:32:df:5c
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 22
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 

Re: initial 11n support for iwn - defunc: Intel WiFi Link 5300 rev 0x00

2015-12-19 Thread Marcus MERIGHI
t;Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x93
pci4 at ppb3 bus 13
pcib0 at pci0 dev 31 function 0 "Intel 82801IEM LPC" rev 0x03
ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x03: msi, AHCI 1.2
ahci0: port 0: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, SanDisk SDSSDHII, X312> SCSI3 0/direct 
fixed naa.5001b44e1d7ef244
sd0: 228936MB, 512 bytes/sector, 468862128 sectors, thin
ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x03: apic 1 int 23
iic0 at ichiic0
usb2 at uhci0: USB revision 1.0
uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci1: USB revision 1.0
uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci2: USB revision 1.0
uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb5 at uhci3: USB revision 1.0
uhub5 at usb5 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb6 at uhci4: USB revision 1.0
uhub6 at usb6 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb7 at uhci5: USB revision 1.0
uhub7 at usb7 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
aps0 at isa0 port 0x1600/31
uvideo0 at uhub0 port 6 configuration 1 interface 0 "Lenovo product 0x480c" rev 
2.00/31.34 addr 2
umass0 at uhub1 port 1 configuration 1 interface 0 "Generic Mass Storage" rev 
2.00/1.0e addr 2
umass0: using SCSI over Bulk-Only
scsibus2 at umass0: 2 targets, initiator 0
sd1 at scsibus2 targ 1 lun 0: <Generic, Flash Disk, 8.07> SCSI2 0/direct 
removable
sd1: 7680MB, 512 bytes/sector, 15728640 sectors
umass1 at uhub1 port 6 configuration 1 interface 0 "RICOH USB2.0-FLASH Media" 
rev 2.00/0.01 addr 3
umass1: using SCSI over Bulk-Only
scsibus3 at umass1: 2 targets, initiator 0
probe(umass1:1:0): Check Condition (error 0x70) on opcode 0x0
SENSE KEY: Aborted Command
 ASC/ASCQ: I/O Process Terminated
sd2 at scsibus3 targ 1 lun 0: <RICOH, R5U880FlashMedia, > SCSI2 0/direct 
removable serial.05ca1880R5U880-3
vscsi0 at root
scsibus4 at vscsi0: 256 targets
softraid0 at root
scsibus5 at softraid0: 256 targets
root on sd1a (21f0b3cdd8d0af2e.a) swap on sd1b dump on sd1b
video0 at uvideo0

st...@openbsd.org (Stuart Henderson), 2015.12.17 (Thu) 14:05 (CET):
> On 2015/12/17 13:22, Stefan Sperling wrote:
> > On Thu, Dec 17, 2015 at 12:40:48PM +0100, Marcus MERIGHI wrote:
> > > iwn0: sending auth to 80:1f:02:c1:fd:86 on channel 5 mode 11b
> > > iwn0: sending assoc_req to 80:1f:02:c1:fd:86 on channel 5 mode 11b
> > > iwn0: received auth from 80:1f:02:c1:fd:86 rssi -54 mode 11b
> > > iwn0: association failed (status 18) for 80:1f:02:c1:fd:86
> > 
> > IEEE80211_STATUS_BASIC_RATE = 18,
> > 
> > This could mean we're sending a bad basic rate element in
> > association requests while in 11n mode. I'll investigate.
> > 
> > Is your AP restricting clients to a particular mode, like 11g-only?
> > Perhaps it means your AP requires clients to support MCS higher
> > than MCS 7, which we don't support yet?
> > 
> > Can you somehow change AP settings in this regard?
> > 
> 
> It seems that some APs get upset if you send rates that are not in their
> advertised list.
> 
> https://supportforums.cisco.com/document/141136/80211-association-status-80211-deauth-reason-codes
> says "Will happen if the rates in the assoc request are not in the
> BasicRateSet in the beacon" for this.
> 
> We don't do much decode of assoc requests in tcpdump at the moment.
> Marcus, it might be useful to get a pcap file (tcpdump -s1500 -iiwn0
> -yIEEE802_11_RADIO -w /tmp/iwn.pcap) from while it's trying to
> associate - if you send it to me off list (and probably best to
> cc stsp) I can take a look and see if I spot anything.



Re: initial 11n support for iwn - defunc: Intel WiFi Link 5300 rev 0x00

2015-12-17 Thread Marcus MERIGHI
s...@stsp.name (Stefan Sperling), 2015.12.16 (Wed) 15:35 (CET):
> This diff adds 11n MCS 0-7 with A-MPDU and A-MSDU Rx to the iwn(4) driver.
> 
> It also tweaks replay detection for CCMP encrypted frames, which needed
> tweaking for A-MPDU anyway (see comments in code). Even in non-11n modes
> this driver was discarding some retransmitted frames for no good reason.
> 
> This driver supports a very wide range of hardware so please test this
> with as many iwn(4) adapters as possible. If we don't get enough tests
> this change may not be able to make the 5.9 release.
> 
> Works for me on:
> iwn0 at pci3 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, 
> MIMO 2T2R, MoW
> 
> Please post here or let me know in private which hardware you're
> testing on. Thanks.

iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5300" rev 0x00: msi, MIMO
  3T3R, MoW, address 00:21:6a:8c:3d:9c

Does not link up with my access point as usual. 
An usb wifi dongle (run) does, contents of hostname.if are the same.

iwn0 in debug mode says:

iwn0: sending auth to 80:1f:02:c1:fd:86 on channel 5 mode 11b
iwn0: sending assoc_req to 80:1f:02:c1:fd:86 on channel 5 mode 11b
iwn0: received auth from 80:1f:02:c1:fd:86 rssi -54 mode 11b
iwn0: association failed (status 18) for 80:1f:02:c1:fd:86

Fetched bsd.rd from ftp.openbsd.org directly. No mirror had the Dec 17 
1:17 build already. Booted from SSD/bsd.rd and installed onto USB Stick.
Booted from USB, ran fw_update -a. 

dmesg of three boots: install, normal boot, normal boot with iwn debug.
followed by pcidump and usbdevs. acpidump available.

Bye, Marcus

OpenBSD 5.8-current (RAMDISK_CD) #1587: Thu Dec 17 01:22:12 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 4166717440 (3973MB)
avail mem = 4038721536 (3851MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
bios0: vendor LENOVO version "6DET72WW (3.22 )" date 10/25/2012
bios0: LENOVO 7470W1W
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR 
SSDT SSDT SSDT
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU L9400 @ 1.86GHz, 1862.29 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 6MB 64b/line 16-way L2 cache
cpu0: apic clock running at 265MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus -1 (EXP2)
acpiprt5 at acpi0: bus 5 (EXP3)
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
"Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
"Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 
00:1f:16:32:df:5c
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 22
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
"Intel 82801I HD Audio" rev 0x03 at pci0 dev 27 function 0 not configured
ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x03: msi
pci1 at ppb0 bus 2
ppb1 at pci0 dev 28 function 1 "Intel 82801I PCIE" rev 0x03: msi
pci2 at ppb1 bus 3
iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5300" rev 0x00: msi, MIMO 3T3R, 
MoW, address 00:21:6a:8c:3d:9c
ppb2 at pci0 dev 28 function 3 "Intel 82801I PCIE" rev 0x03: msi
pci3 at ppb2 bus 5
uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 16
uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 17
uhci5 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 18
ehci1 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 19
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x93
pci4 at ppb3 bus 13
"Intel 82801IEM LPC" rev 0x03 at pci0 dev 31 function 0 not configured
ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x03: msi, AHCI 1.2
ahci0: port 0: 3.0Gb/s
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0:  SCSI3 0/direct 
fixed naa.5001b44e1d7ef244

rdate.c pledge error messages diff

2015-10-31 Thread Marcus MERIGHI
The first one seems to be a pasto from the fork(2) error message. 
The second just makes the error message unique. 

My coding foo lives in /nonexistent. That's the reason I was trying to
read the code after seeing the commit message (fork(2)/pipe(2)).
Please bear with me.

Bye, Marcus

Index: rdate.c
===
RCS file: /cvs/src/usr.sbin/rdate/rdate.c,v
retrieving revision 1.33
diff -u -p -u -r1.33 rdate.c
--- rdate.c 29 Oct 2015 03:16:15 -  1.33
+++ rdate.c 30 Oct 2015 17:44:22 -
@@ -144,7 +144,7 @@ main(int argc, char **argv)
break;
case 0:
if (pledge("stdio inet dns", NULL) == -1)
-   err(1, "fork");
+   err(1, "child pledge");
 
close(p[0]);/* read side of pipe */
dup2(p[1], STDIN_FILENO);
@@ -168,7 +168,7 @@ main(int argc, char **argv)
}
 
if (pledge("stdio rpath wpath settime", NULL) == -1)
-   err(1, "pledge");
+   err(1, "parent pledge");
 
close(p[1]);/* write side of pipe */
if (read(p[0], , sizeof pdata) < 1)



bank-donation.html SEPA BIC format error

2015-10-29 Thread Marcus MERIGHI
so diffs go to tech@? even that one?

Reason: the electronic banking form of my bank does not like the
formatting of the BIC number. 
Possibly others have different experiences...

(In the SWIFT column the proposed formatting is already used.)

Bye, Marcus

Index: bank-donation.html
===
RCS file: /cvs/www/bank-donation.html,v
retrieving revision 1.23
diff -u -p -u -r1.23 bank-donation.html
--- bank-donation.html  11 May 2015 11:18:29 -  1.23
+++ bank-donation.html  29 Oct 2015 12:38:55 -
@@ -21,7 +21,7 @@ the following information:
 From Inside Europe (SEPA):
 
 IBAN: DE91 7007 0024 0338 1779 00
-BIC: DEUT DE DBMUC
+BIC: DEUTDEDBMUC
 Name: Theo de Raadt
 Address: Deutsche Bank, Marienplatz 21
 80331 Mnchen, Germany



Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

2015-08-08 Thread Marcus MERIGHI
ch...@nmedia.net (Chris Cappuccio), 2015.08.07 (Fri) 22:34 (CEST):
 Maxime Villard [m...@m00nbsd.net] wrote:
  Now, I believe that this effort is too much for my spare time. If you
  want to say thanks to me for reporting this vulnerability, dear Sam,
  it's never too late.
 
 I put here a thanks among others:
 
 Thank you for your effort to help improve the OpenBSD operating system,
 to the benefit of its users, developers, and the many others who are
 using the code in their own systems. Your work is appreciated, each
 commit fixing a bug that you found is perhaps the spiritual thank-you
 of which you have detected the subtle presence :)
 
 Chris

Pretty late to say thank you, I guess... None the less: Thank you!

Bye, Marcus

 !DSPAM:55c51679296674511250856!



Re: syslogd sending via tcp

2014-12-28 Thread Marcus MERIGHI
minimal man page adaption:

Index: syslog.conf.5
===
RCS file: /cvs/src/usr.sbin/syslogd/syslog.conf.5,v
retrieving revision 1.26
diff -u -r1.26 syslog.conf.5
--- syslog.conf.5   25 Aug 2014 20:25:46 -  1.26
+++ syslog.conf.5   28 Dec 2014 16:53:17 -
@@ -227,8 +227,8 @@
 and
 .Ql ]\
 .Pc .
-A prefix udp4:// or udp6:// in front of the hostname and after the
-at sign will force IPv4 or IPv6 addresses for UDP transport.
+A prefixed udp4://, udp6://, tcp4:// or tcp6:// in front of the hostname and
+after the at sign will force IPv4 or IPv6 addresses for UDP or TCP transport.
 .It
 A comma separated list of users.
 Selected messages are written to those users



mg/theo.c + Guess you don't understand internet.

2014-12-27 Thread Marcus MERIGHI
see http://marc.info/?l=openbsd-miscm=141947339308369

Index: theo.c
===
RCS file: /cvs/src/usr.bin/mg/theo.c,v
retrieving revision 1.143
diff -u -r1.143 theo.c
--- theo.c  19 Nov 2014 21:22:47 -  1.143
+++ theo.c  27 Dec 2014 11:56:38 -
@@ -187,6 +187,7 @@
Kill the past with fire, and declare Duran Duran is less cool today.  
Await remixes of the same thing performed by new talent.,
Where did my \fuck backwards compat\ compatriots go?,
I want a new vax, one that's not so slow.,
+   Guess you don't understand internet.,
 };
 
 static const int ntalk = sizeof(talk)/sizeof(talk[0]);



Re: getent(1) hosts enumeration defunc

2014-06-29 Thread Marcus MERIGHI
Hello, 

(this was on tech@, therefore reviving it here.)

getent(1) manual and output stil do not match. It does not enumerate for
database ``hosts'' and does not return 3 as exit status, as stated by
the man page.

Bye, Marcus

st...@openbsd.org (Stuart Henderson), 2013.04.26 (Fri) 13:27 (CEST):
 On 2013/04/26 12:57, MERIGHI Marcus wrote:
  there is no more listing (enumerating) of hosts entries. Suspect: [1]
  +++
  $ getent hosts; echo $?
  0
  $ getent hosts fifi
  127.0.0.1   fifi
  $ getent ethers
  getent: Enumeration not supported on ethers
  +++
  So this is inconsistent at least and it introduced different behaviour. 
  
  I could provide a man page fix and/or a current.html entry but fixing
  getent.c is beyond my coding foo.
  
  [1]
  http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/getent/getent.c.diff?r1=1.5;r2=1.6
  
  OpenBSD 5.3-current (GENERIC.MP) #103: Wed Apr 24 09:33:02 MDT 2013
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
  
 
 This wasn't caused by that commit; previously there was no output
 but exit code 127.
 
 This does work as expected on a Mar 12 system, so this was more likely
 caused by the switch to asr.

flor...@openbsd.org (Florian Obser), 2013.04.26 (Fri) 13:31 (CEST):
 On Fri, Apr 26, 2013 at 12:57:32PM +0200, MERIGHI Marcus wrote:
  there is no more listing (enumerating) of hosts entries. Suspect: [1]
 [...]
  [1]
  http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/getent/getent.c.diff?r1=1.5;r2=1.6
  
  OpenBSD 5.3-current (GENERIC.MP) #103: Wed Apr 24 09:33:02 MDT 2013
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
  
 
 nope, this change works fine on a Mar 13 snap, I suspect asr



Re: Soekris net6501 GPIO LED support

2014-03-04 Thread Marcus MERIGHI
Apologies if I missed something but to me it looks like this was neither
commited nor declined.

This is about
src/sys/dev/isa/soekris.c (nonexistent)

and not
src/sys/arch/amd64/amd64/bios.c Revision 1.23 
Fake 'SMBIOS detection' for the Soekris boxes, by Matt Dainty

References:
http://marc.info/?l=openbsd-techm=136317575910043
http://marc.info/?l=openbsd-techm=137130692221862

Bye, Marcus

m...@bodgit-n-scarper.com (Matt Dainty), 2013.03.13 (Wed) 12:55 (CET):
 * Matt Dainty m...@bodgit-n-scarper.com [2013-01-14 11:13:59]:
  Attached is a patch that adds soekris(4) which provides access to the
  GPIO and LEDs as implemented by the onboard Xilinx FPGA on the Soekris
  net6501. The driver provides two GPIO buses; one for the 16 real GPIO
  pins exposed on the board, and another which has the LEDs coerced into
  the GPIO framework as output-only pins.
  
  I kept them separate to prevent confusion and make the code slightly
  simpler, if it's preferred to have just one GPIO bus let me know.
  
  It's enabled in the kernel config with:
  
  soekris0 at isa? port 0x680
  gpio*at soekris?
  
  The driver cannot be enabled by default as there's no reliable way to
  detect the hardware, it's just a handful of I/O ports at a known
  address, (GPIO isn't enabled by default in GENERIC so a kernel compile
  is required regardless).
  
  This is what is shown at boot:
  
  soekris0 at isa0 port 0x680/32
  gpio0 at soekris0: 16 pins
  gpio1 at soekris0: 2 pins
  
  I then have the following in /etc/rc.securelevel:
  
  gpioctl -q gpio1 0 set out error_led
  gpioctl -q gpio1 1 set out ready_led
  
  If this driver is acceptable I can send a further patch with man pages.
  Tested on a Soekris net6501 running amd64, LEDs work and I've put
  simple LED and pushbutton circuits on the GPIO pins.
 
 Here's an updated patch for the driver, the only change is in the
 *_match() function that is now simplified and much more reliable thanks
 to the committed Soekris comBIOS patch to bios(4).
 
 I've still left the GENERIC config unchanged as there's no other gpio(4)
 drivers enabled, I'm guessing as general policy.
 
 I'll send a separate patch with the various man page changes.
 
 Matt
 
 --- /dev/null Wed Mar 13 10:27:40 2013
 +++ sys/dev/isa/soekris.c Tue Feb 19 08:31:10 2013
 @@ -0,0 +1,239 @@
 +/*   $OpenBSD$ */
 +
 +/*
 + * Copyright (c) 2013 Matt Dainty m...@bodgit-n-scarper.com
 + *
 + * Permission to use, copy, modify, and distribute this software for any
 + * purpose with or without fee is hereby granted, provided that the above
 + * copyright notice and this permission notice appear in all copies.
 + *
 + * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 + * WHATSOEVER RESULTING FROM LOSS OF MIND, USE, DATA OR PROFITS, WHETHER IN
 + * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
 + * OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 + */
 +
 +/*
 + * Soekris net6501 GPIO and LEDs as implemented by the onboard Xilinx FPGA 
 + */
 +
 +#include sys/param.h
 +#include sys/systm.h
 +#include sys/device.h
 +#include sys/gpio.h
 +
 +#include machine/bus.h
 +#include machine/intr.h
 +
 +#include dev/isa/isavar.h
 +
 +#include dev/gpio/gpiovar.h
 +
 +#define  SOEKRIS_BASE0x680   /* Base address of FPGA I/O */
 +#define  SOEKRIS_IOSIZE  32  /* I/O region size */
 +
 +#define  SOEKRIS_NPINS   16  /* Number of Pins */
 +#define  SOEKRIS_GPIO_INPUT  0x000   /* Current state of pins */
 +#define  SOEKRIS_GPIO_OUTPUT 0x004   /* Set state of output pins */
 +#define  SOEKRIS_GPIO_RESET  0x008   /* Reset output pins */
 +#define  SOEKRIS_GPIO_SET0x00c   /* Set output pins */
 +#define  SOEKRIS_GPIO_DIR0x010   /* Direction, set for output */
 +
 +#define  SOEKRIS_NLEDS   2   /* Number of LEDs */
 +#define  SOEKRIS_LED_ERROR   0x01c   /* Offset to error LED */
 +#define  SOEKRIS_LED_READY   0x01d   /* Offset to ready LED */
 +
 +extern char *hw_vendor, *hw_prod;
 +
 +const u_int soekris_led_offset[SOEKRIS_NLEDS] = {
 + SOEKRIS_LED_ERROR, SOEKRIS_LED_READY
 +};
 +
 +struct soekris_softc {
 + struct devicesc_dev;
 +
 + bus_space_tag_t  sc_iot;
 + bus_space_handle_t   sc_ioh;
 +
 + struct gpio_chipset_tag  sc_gpio_gc;
 + gpio_pin_t   sc_gpio_pins[SOEKRIS_NPINS];
 +
 + /* Fake GPIO device for the LEDs */
 + struct gpio_chipset_tag  sc_led_gc;
 + gpio_pin_t   sc_led_pins[SOEKRIS_NLEDS];
 +};
 +
 +int   soekris_match(struct device *, void *, void *);
 +void  soekris_attach(struct device *, struct device *, void *);
 +int   

Re: duid support to dump

2014-03-04 Thread Marcus MERIGHI
I could not find this commited or further discussed. 
Therefore: ping?

Bye, Marcus

ccut...@csail.mit.edu (Cody Cutler), 2013.11.29 (Fri) 20:32 (CET):
 j...@sing.id.au (Joel Sing) - Thu, Nov 28, 2013 at 03:16:20AM +1100
  From a quick glance, you should be able to use opendev(3) to open the disk 
  device (rather than using open), in which case you'll get DUID handling for 
  free. This also avoids the TOCTOU issues associated with attempting to map 
  a 
  DUID back to a name. Even if this is not possible, then it would be 
  preferable to use opendev(3) to get the realname (as is done in fsck(8) 
  from 
  memory), rather than the hand rolled version below.
 
 thanks joel. round two is inline below.
 
 Index: Makefile
 ===
 RCS file: /cvs/src/sbin/dump/Makefile,v
 retrieving revision 1.11
 diff -p -u -r1.11 Makefile
 --- Makefile  6 Jan 2013 21:59:28 -   1.11
 +++ Makefile  29 Nov 2013 19:26:23 -
 @@ -12,6 +12,8 @@
  #TDEBUG  trace out the process forking
  
  PROG=dump
 +LDADD=   -lutil
 +DPADD=   ${LIBUTIL}
  LINKS=   ${BINDIR}/dump ${BINDIR}/rdump
  CFLAGS+=-DRDUMP
  SRCS=itime.c main.c optr.c dumprmt.c tape.c traverse.c
 Index: dump.h
 ===
 RCS file: /cvs/src/sbin/dump/dump.h,v
 retrieving revision 1.17
 diff -p -u -r1.17 dump.h
 --- dump.h11 Jun 2013 16:42:04 -  1.17
 +++ dump.h29 Nov 2013 19:26:23 -
 @@ -86,6 +86,7 @@ int tp_bshift;  /* log2(TP_BSIZE) */
  /* operator interface functions */
  void broadcast(char *message);
  time_t   do_stats(void);
 +char *duidtorawname(char *duid, char *buf, size_t s);
  void lastdump(int arg);  /* int should be char */
  void msg(const char *fmt, ...)
  __attribute__((__format__ (printf, 1, 2)));
 Index: main.c
 ===
 RCS file: /cvs/src/sbin/dump/main.c,v
 retrieving revision 1.46
 diff -p -u -r1.46 main.c
 --- main.c16 Apr 2013 18:17:39 -  1.46
 +++ main.c29 Nov 2013 19:26:23 -
 @@ -51,6 +51,7 @@
  #include string.h
  #include time.h
  #include unistd.h
 +#include util.h
  
  #include dump.h
  #include pathnames.h
 @@ -204,7 +205,9 @@ main(int argc, char *argv[])
   for (i = 0; i  argc; i++) {
   struct stat sb;
  
 - if (lstat(argv[i], sb) == -1) {
 + if (isduid(argv[i], 0))
 + break;
 + else if (lstat(argv[i], sb) == -1) {
   msg(Cannot lstat %s: %s\n, argv[i], strerror(errno));
   exit(X_STARTUP);
   }
 @@ -341,7 +344,8 @@ main(int argc, char *argv[])
   }
   } else if ((dt = fstabsearch(disk)) != NULL) {
   /* in fstab? */
 - disk = rawname(dt-fs_spec);
 + if (!isduid(disk, 0))
 + disk = rawname(dt-fs_spec);
   mount_point = dt-fs_file;
   (void)strlcpy(spcl.c_dev, dt-fs_spec, sizeof(spcl.c_dev));
   if (dirlist != 0) {
 @@ -378,7 +382,7 @@ main(int argc, char *argv[])
   else
   msgtail(to %s\n, tape);
  
 - if ((diskfd = open(disk, O_RDONLY))  0) {
 + if ((diskfd = opendev(disk, O_RDONLY, 0, NULL))  0) {
   msg(Cannot open %s\n, disk);
   exit(X_STARTUP);
   }
 @@ -605,16 +609,39 @@ sig(int signo)
  }
  
  char *
 +duidtorawname(char *duid, char *buf, size_t s)
 +{
 + char *rp;
 + int fd;
 +
 + if (s)
 + buf[0] = '\0';
 +
 + if ((fd = opendev(duid, O_RDONLY, 0, rp))  0)
 + return NULL;
 +
 + close(fd);
 + strlcpy(buf, rp, s);
 +
 + return buf;
 +}
 +
 +char *
  rawname(char *cp)
  {
   static char rawbuf[MAXPATHLEN];
 - char *dp = strrchr(cp, '/');
 -
 - if (dp == NULL)
 - return (NULL);
 - *dp = '\0';
 - (void)snprintf(rawbuf, sizeof(rawbuf), %s/r%s, cp, dp + 1);
 - *dp = '/';
 + char *dp;
 + 
 + if (isduid(cp, 0))
 + return duidtorawname(cp, rawbuf, sizeof(rawbuf));
 + else {
 + dp = strrchr(cp, '/');
 + if (dp == NULL)
 + return (NULL);
 + *dp = '\0';
 + (void)snprintf(rawbuf, sizeof(rawbuf), %s/r%s, cp, dp + 1);
 + *dp = '/';
 + }
   return (rawbuf);
  }
  
 Index: optr.c
 ===
 RCS file: /cvs/src/sbin/dump/optr.c,v
 retrieving revision 1.34
 diff -p -u -r1.34 optr.c
 --- optr.c12 Nov 2013 04:59:02 -  1.34
 +++ optr.c29 Nov 2013 19:26:23 -
 @@ -47,6 +47,7 @@
  #include tzfile.h
  #include unistd.h
  #include utmp.h
 +#include util.h
  
  #include dump.h
  #include pathnames.h
 @@ -335,17 +336,23 @@ getfstab(void)
  struct fstab *
  fstabsearch(char *key)
  {
 + char keyrn[MAXPATHLEN];

Re: security(8) check maildir as well as mailbox permissions

2013-12-19 Thread Marcus MERIGHI
Am 12/19/13 10:55, schrieb Henning Brauer:
 * Craig R. Skinner skin...@britvault.co.uk [2013-12-19 10:18]:
 On 2013-12-18 Wed 20:48 PM |, J??r??mie Courr??ges-Anglas wrote:
 skin...@britvault.co.uk (Craig R. Skinner) writes:
 On 2013-12-18 Wed 15:54 PM |, Stuart Henderson wrote:
 Check the security of /var/mail/dirs similar to /var/mail/boxes:


 Indeed, but security(8) really reflects things in the base OS,


 smtpd.conf(8)
deliver to maildir path
Mail is added to a maildir.  Its location, path, may
contain format specifiers that are expanded before use


 Therefore: ... deliver to maildir /var/mail/%{user.username}
 Therefore?  How so?  What's the logic, here?
 THEREFORE software in base can deliver to maildir in /var/mail
 
 THEREFORE software in base can also deliver mail to
 /omgohmymail/pr0n/$uid - does that mean we check it in security?
 
 The question is rather wether Maildirs in /var/mail are a common
 enough setup to warrant a check in security.

By default it's supposed to be in $HOME/Maildir:

smtpd.conf(5)

deliver to maildir path
  [snip what's quoted above]
  If path is not provided, then ~/Maildir is assumed.

Bye, Marcus