Re: Configure interface by lladdr during install

2022-12-07 Thread Stuart Henderson
On 2022/12/06 19:57, Andrew Hewus Fresh wrote:
> Which interface do you wish to configure? (name, lladdr, '?', or 'done') 
> [vio0] ?
> Available network interfaces are: vio0 vlan0.
>  vio0: lladdr fe:e1:bb:d1:dd:97
> Which interface do you wish to configure? (name, lladdr, '?', or 'done') 
> [vio0] fe:e1:bb:d1:dd:97
> IPv4 address for vio0? (or 'autoconf' or 'none') [autoconf] 
> IPv6 address for vio0? (or 'autoconf' or 'none') [none] 
> Available network interfaces are: vio0 vlan0.

It doesn't seem right to offer vio0 in the list if it was already
configured via lladdr?

(Brushing aside the issue that fe:e1:b[ab]:dX:XX:XX addresses
are usually random so the hostname.lladdr scheme won't work for
them anyway..)



Re: OpenSSH and -current out-of-tree patched for ~C?

2022-11-30 Thread Stuart Henderson
On 2022/11/30 08:53, Andy Bradford wrote:
> Thus said "Theo de Raadt" on Wed, 23 Nov 2022 18:56:21 -0700:
> 
> > A  new  "enablecommandline"   configuration  option  re-enables  those
> > particular features, and the diff later on will show why we feel these
> > features should be optional.
> 
> Glad  that the  option is  being retained  as optional  but I  also look
> forward to seeing the  rationale for this change. I for  one use the ~C,
> not daily,  but often  enough that  I would have  noticed over  a longer
> period of time because I don't run -current.

It allows a much tighter pledge in the client, so less attack surface
against a bad server.

> In my  particular scenario, I  often open  up long running  SSH sessions
> that have tunnels  to other TCP/IP sessions (some  of them interactive),
> and the  ability to add tunnels  dynamically means that I  don't have to
> restart a bunch of interactive  sessions or interrupt other long-running
> things over the tunnels. If I decide that the tunnel is something I want
> to use long-term, I'll add it to ~/.ssh/config for future use.

Alternatively you can use connection multiplexing (which didn't support
~C anyway) and run a separate ssh -L / -R, which will establish an extra
channel using the existing connection.



Re: lladdr support for netstart/hostname.if

2022-11-24 Thread Stuart Henderson
On 2022/11/24 14:36, Vitaliy Makkoveev wrote:
> On Wed, Nov 23, 2022 at 09:36:28PM -0700, Theo de Raadt wrote:
> > Theo de Raadt  wrote:
> > 
> > > > The other, that if both exist,
> > > > /etc/hostname.$if will override /etc/hostname.$lladdr.
> > > 
> > > We do need to decide which one is priority, and document that.
> > > 
> > > I am still unsure which is better.  (I've seen a lot of spurious comments
> > > from folk, so please think about realistic cases, and don't make stuff 
> > > up..)
> > 
> > And by that I mean: Actually try andrews's diff.  It does it one way (.if
> > is more important).  Maybe it needs to be the other way.
> > 
> 
> Could we check the simultaneous existence of both hostname.if and
> hostname.lladdr corresponding to one interface and print error message
> if so?
> 
> I'm also interesting how the following case will be handled. We have
> /etc/hostname.vlan0 and /etc/hostname.08002233ccbb, network devices
> configured as:

I don't see how this scheme can work with vlans (or any interface which
changes its MAC address, whether that's automatically - vlan, trunk -
randomly - vether, etc - or explicitly with lladdr).

Another thing with vlans is that, they have a 00:00:00:00:00:00 MAC
address until they're configured, but if you then later re-run netstart,
they then *will* have a MAC address (matching a physical interface),
so netstart's behaviour will be different between running at boot,
and running later.

That's not really a problem as such, it just limits the scope of where
this functionality could be used.

(It wouldn't really help vlans anyway - the thing which needs changing
for those is picking which parent interface to use, not picking a
different hostname file for the vlan interface).



Re: lladdr support for netstart/hostname.if

2022-11-22 Thread Stuart Henderson

Need to query (and set $if, which might be used in route commands etc) I think.

--
 Sent from a phone, apologies for poor formatting.

On 22 November 2022 08:37:05 Florian Obser  wrote:


On 2022-11-22 18:06 +10, David Gwynne  wrote:


There are a few things to keep in mind if we're going to use lladdrs like this.

vlan interfaces start with their lladdr as 00:00:00:00:00:00 and then 
assume the lladdr of the parent interface when that is configured.


Clonable devices (eg, egre, vport, aggr, etc) tend to generate random
lladdrs when they're created. If you want a consistent lladdr for
these you configure that in /etc/hostname.vportX or whatever you're
using.


ifconfig(8) already knows about these (see -C option). Which made me
think, it might be easier to just ask ifconfig(8).

$ ifconfig -Q 00:80:41:7b:f3:c3
vio0

Would that be helpful?

Or would you need

# ifconfig 00:80:41:7b:f3:c3 inet 192.0.2.2/24

to work?

I think you want to query,no?



"Platform deficient" systems like arm SBCs don't always do a good job
of providing lladdrs for their ethernet interfaces. I'm working on one
now that has rge(4) and it comes up with an lladdr of
00:00:00:00:00:00. I have another one where the drivers fall back to
randomly generating an lladdr if none is set by u-boot/edk/etc.

I don't think any of these are showstoppers, but do need to be considered.



--
I'm not entirely sure you are real.




Re: xenodm: save ~/.xesssion to ~/.xsession.old

2022-11-14 Thread Stuart Henderson
On 2022/11/14 16:50, Klemens Nanni wrote:
> X segfaulted when I opened a window, Xorg.log.old only showed the
> address without anything specific, no core dump was created and
> xenodm automatically restarted.
> 
> After I logged in I checked ~/.xsession for possible indications, but
> that file gets truncated on login.
> 
> I've restarted xenodm again, so the old Xorg.log.old containing the
> generic "X segfaulted at addr 0x86..." is also gone.
> 
> Woul it make sense to save an old copy in analogy to Xorg.log.old
> so crashes like this have a higher chance of being hunted down?
> 
> I haven't extensively tested this patch, but relogging into X now leaves
> ~/.xesssion-errors.old with logs from the previous session behind.
> 
> Index: app/xenodm//config/Xsession.in
> ===
> RCS file: /cvs/xenocara/app/xenodm/config/Xsession.in,v
> retrieving revision 1.2
> diff -u -p -r1.2 Xsession.in
> --- app/xenodm//config/Xsession.in1 Jul 2022 20:42:06 -   1.2
> +++ app/xenodm//config/Xsession.in14 Nov 2022 16:47:03 -
> @@ -7,6 +7,7 @@ exec_prefix="@exec_prefix@"
>  # redirect errors to a file in user's home directory if we can
>  
>  errfile="$HOME/.xsession-errors"
> +cp -f "$errfile" "$errfile.old" 2> /dev/null

Those files can get pretty big. mv is probably a better idea than cp.

>  if ( umask 077 && cp /dev/null "$errfile" 2> /dev/null )
>  then
>   exec > "$errfile" 2>&1
> 



Re: mount_ntfs.8: Fix swapped -g user and -u group

2022-11-14 Thread Stuart Henderson
ha, good catch. committed, thanks.



route(8) example for "out of prefix" default gateway

2022-11-08 Thread Stuart Henderson
Seems some hosting providers have annoying "out of prefix"
default gateways whuch are painful to configure
(https://marc.info/?t=16678224225=1=2), should
we give a pointer in route(8)?

Index: route.8
===
RCS file: /cvs/src/sbin/route/route.8,v
retrieving revision 1.104
diff -u -p -r1.104 route.8
--- route.8 29 Jul 2022 18:28:32 -  1.104
+++ route.8 9 Nov 2022 07:29:59 -
@@ -596,6 +596,14 @@ Delete the
 route to the 192.168.5.0/24 network:
 .Pp
 .Dl # route delete -inet 192.168.5.0/24
+.Pp
+Add a static
+.Xr inet6 4
+route to a host which is on the vio0 interface that is outside the prefix
+configured on the interface, and use that host as a default gateway:
+.Pp
+.Dl # route add -inet6 2001:db8:efef::1 -cloning -link -iface vio0
+.Dl # route add -inet6 default 2001:db8:efef::1
 .Sh DIAGNOSTICS
 .Bl -diag
 .It "%s: gateway %s flags %x"



Re: rc(8): reorder_libs(): print names of relinked libraries

2022-11-08 Thread Stuart Henderson
On 2022/11/07 23:54, Theo de Raadt wrote:
> Klemens Nanni  wrote:
> 
> > > I know this makes rc(8) a bit noisier but it really does improve my
> > > (for want of a better term) "user experience" as I wait for my machine
> > > to boot.
> > 
> > I like this and it doesn't add more **lines** to the boot log, but maybe
> > print library names without versions to reduces noise?
> 
> Only if it is the short names.

No need for the .so really either. ld.so libc libcrypto is enough.

> But I am not sure people need to see this detail.  It just takes a bit
> of time.  How does knowing what steps are being taken help...

Sometimes it's a bit of time, sometimes it's a _lot_ of time until
people get a new computer or raid battery or something and it's less
annoying if you can see _some_ progress.



Re: Questions about the code review process in OpenBSD

2022-11-07 Thread Stuart Henderson
On 2022/11/04 23:32, i...@tutanota.com wrote:
> I am trying to understand how the code review process is conducted in
> OpenBSD. I can see all the OK's in the commit log, but not every commit
> has the OK.
> 
> On FreeBSD there where a serious problem with a developer who was hired
> to by Netgear to create a WireGuard VPN implementation as a kernel-mode

Note: netgate, not netgear.

> solution and this was then contributed to FreeBSD. It was removed in
> the last minute.
> 
> https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/



Re: ssh-keygen(1): by default generate ed25519 key (instead of rsa)

2022-11-07 Thread Stuart Henderson
On 2022/11/07 12:02, Solène Rapenne wrote:
> Le Sun, 6 Nov 2022 18:41:50 +0400,
> Loganaden Velvindron  a écrit :
> 
> > On Sun, 6 Nov 2022 at 18:31, Job Snijders  wrote:
> > >
> > > Dear all,
> > >
> > > Support for using Ed25519 for server and user authentication was
> > > introduced in 2014. I like the compactness of Ed25519 public keys.
> > >
> > > Perhaps now is a good time to make Ed25519 the default key type when
> > > invoking ssh-keygen(1) without arguments?
> > >  
> > 
> > I agree, but I think we lack data on deployed ssh systems at large.
> > 
> > > Kind regards,
> > >
> > > Job
> 
> FWIW, Azure doesn't support ed25519 yet
> 
> https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/ed25519-ssh-keys
> 

This doesn't cause a problem, you can simply generate an RSA key if you
would like to use a key to connect to a system that does not yet support
ed25519 keys.

Using ed25519 by default is also a gentle nudge to vendors (maybe it
will become easier for them to add support than explain to users how to
generate an rsa key).



Re: 7.2 miniroot pointed to /pub/OpenBSD/snapshots for sets

2022-10-20 Thread Stuart Henderson
On 2022/10/20 09:44, Heppler, J. Scott wrote:
> I was testing the full setup for a lightweight desktop I posted on
> https://daemonforums.org/showpost.php?p=67677=1
> 
> My downloaded miniroot:
> -rw-r--r--1 jsh   jsh  5832704 Oct 20 08:51 miniroot72.img
> 
> The system had previously been running snapshot, but I had selected
> Install(I) and whole disk GPT(G).  The whole disk should have been
> newly formatted.  /etc/installurl came up as my nearest mirror:
> mirrors.sonic.net which I had previously used for the snapshot install.
> 
> If it's working - sorry for the noise.

For an install (rather than an upgrade) it's not based on what you've
installed on the individual machine before; when install is done
the source URL is sent to ftpinstall.cgi which offers it back via
ftplist.cgi for further installs from the same IP address.

The mechanism for saving the full directory or not is in install.sub
around line 1850.



Re: 7.2 miniroot pointed to /pub/OpenBSD/snapshots for sets

2022-10-20 Thread Stuart Henderson
On 2022/10/20 09:05, Heppler, J. Scott wrote:
> Using the miniroot img from https://cdn.openbsd.org/pub/OpenBSD/7.2, the
> set retrival still points to snapshots.

You (or someone else using the same IP) must have done an install from a
full URL previously rather than picking a mirror from the list.

Check 'ftp -Vo- https://ftplist1.openbsd.org/cgi-bin/ftplist.cgi | head'



Re: em(4) IPv4, TCP, UDP checksum offloading

2022-10-11 Thread Stuart Henderson
On 2022/10/11 15:03, Moritz Buhl wrote:
> Here is a new diff for checksum offloading (ipv4, udp, tcp) for em(4).
> 
> The previous diff didn't implement hardware vlan tagging for >em82578
> which should result in variable ethernet header lengths and thus
> wrong checksums inserted at wrong places.
> 
> The diff below addresses this.
> I would appreciate further testing reports with different controllers.
> 
> mbuhl

I tried this on my laptop which has I219-V em (I run it in a trunk
with iwm). It breaks tx (packets don't show up on the other side).
rx seems ok.

There is also a "em0: watchdog: head 111 tail 20 TDH 20 TDT 111"
but that was after ~10 mins uptime so may have occurred after
I switched the active port on the trunk(4) over to the iwm, or
back again.

OpenBSD 7.2-current (GENERIC.MP) #64: Tue Oct 11 14:30:52 BST 2022
st...@bamboo.spacehopper.org:/sys/arch/amd64/compile/GENERIC.MP
real mem = 16926281728 (16142MB)
avail mem = 16395878400 (15636MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.1 @ 0x77d49000 (64 entries)
bios0: vendor LENOVO version "N2HET63W (1.46 )" date 06/01/2021
bios0: LENOVO 20QF00B2UK
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT TPM2 UEFI SSDT HPET APIC MCFG 
ECDT SSDT SSDT SSDT BOOT SLIC SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB NHLT FPDT 
UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) 
RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1795.82 MHz, 06-8e-0c
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
4-way L2 cache, 8MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1795.82 MHz, 06-8e-0c
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
4-way L2 cache, 8MB 64b/line 16-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1795.82 MHz, 06-8e-0c
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
4-way L2 cache, 8MB 64b/line 16-way L3 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1698.73 MHz, 06-8e-0c
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
4-way L2 cache, 8MB 64b/line 16-way L3 cache
cpu3: smt 0, core 

Re: sysupgrade: exit 1 instead of exit 0 when ending early

2022-10-11 Thread Stuart Henderson
On 2022/10/11 03:44, Mikolaj Kucharski wrote:
> On Mon, Oct 10, 2022 at 11:17:32AM -0600, Theo de Raadt wrote:
> 
> > Any non-zero value indicates an error, that would include 2.  You are
> > marking this as an error, when it isn't.
> > 
> > You think this will help your scripting.  Do you not realize the proposed
> > changes will break someone else's scripting?
> 
> I don't insist on this approach. I just propose a patch.
> 
> I do recognize that it is going to break someone else's workflow.

And relying on it also means that your own scripts won't work on
older versions, whereas if you just check for /bsd.upgrade then they'll
work in both cases (and won't break things for anyone else who uses
"set -e" in their sysupgrade wrapper scripts).



Re: snmp: Add support for PF_LIMIT_ANCHORS

2022-10-06 Thread Stuart Henderson
On 2022/10/06 18:20, Martijn van Duren wrote:
> Just before lock mbuhl pointed out a new limit placed in pf, not
> exported yet over snmp. Here's a diff to add support for
> PF_LIMIT_ANCHORS.
> 
> the OPENBSD-PF-MIB.txt DESCRIPTION is adapted from pfLimitMaxTables.
> The snmp{,d} parts are there just for pretty printing.
> 
> OK?
> 
> martijn@
> 
> Index: share/snmp/OPENBSD-PF-MIB.txt
> ===
> RCS file: /cvs/src/share/snmp/OPENBSD-PF-MIB.txt,v
> retrieving revision 1.7
> diff -u -p -r1.7 OPENBSD-PF-MIB.txt
> --- share/snmp/OPENBSD-PF-MIB.txt 23 Mar 2021 19:37:51 -  1.7
> +++ share/snmp/OPENBSD-PF-MIB.txt 6 Oct 2022 16:14:32 -
> @@ -493,6 +493,14 @@ pfLimitMaxTableEntries OBJECT-TYPE
>   tables."
>   ::= { pfLimits 5 }
>  
> +pfLimitAnchors OBJECT-TYPE
> + SYNTAX  Unsigned32
> + MAX-ACCESS  read-only
> + STATUS  current
> + DESCRIPTION
> + "The maximum number of anchors that can be created as part of the
> + active ruleset."
> + ::= { pfLimits 6 }
>  
>  -- pfTimeouts

Needs something like this on top; otherwise OK (and smilint is happy)

Index: OPENBSD-PF-MIB.txt
===
RCS file: /cvs/src/share/snmp/OPENBSD-PF-MIB.txt,v
retrieving revision 1.7
diff -u -p -r1.7 OPENBSD-PF-MIB.txt
--- OPENBSD-PF-MIB.txt  23 Mar 2021 19:37:51 -  1.7
+++ OPENBSD-PF-MIB.txt  6 Oct 2022 19:37:41 -
@@ -36,7 +36,7 @@ IMPORTS
FROM SNMPv2-CONF;
 
 pfMIBObjects MODULE-IDENTITY
-LAST-UPDATED "202103231933Z"
+LAST-UPDATED "202210061936Z"
 ORGANIZATION "OpenBSD"
 CONTACT-INFO "
   Author: Joel Knight
@@ -46,6 +46,8 @@ pfMIBObjects MODULE-IDENTITY
 DESCRIPTION "The MIB module for gathering information from
OpenBSD's packet filter.
 "
+REVISION "202210061936Z"
+DESCRIPTION "Add counter exporting the maximum number of anchors that can 
be created"
 REVISION "202103231933Z"
 DESCRIPTION "Use DisplayString/SnmpAdminString not OCTET STRING where 
appropriate"
 REVISION "201506091728Z"



>  
> Index: usr.bin/snmp/mib.h
> ===
> RCS file: /cvs/src/usr.bin/snmp/mib.h,v
> retrieving revision 1.10
> diff -u -p -r1.10 mib.h
> --- usr.bin/snmp/mib.h23 Mar 2021 22:05:21 -  1.10
> +++ usr.bin/snmp/mib.h6 Oct 2022 16:14:32 -
> @@ -580,6 +580,7 @@
>  #define MIB_pfLimitFragments MIB_pfLimits, 3
>  #define MIB_pfLimitMaxTables MIB_pfLimits, 4
>  #define MIB_pfLimitMaxTableEntries   MIB_pfLimits, 5
> +#define MIB_pfLimitAnchors   MIB_pfLimits, 6
>  #define MIB_pfTimeouts   MIB_pfMIBObjects, 7
>  #define MIB_pfTimeoutTcpFirstMIB_pfTimeouts, 1
>  #define MIB_pfTimeoutTcpOpening  MIB_pfTimeouts, 2
> @@ -1217,6 +1218,7 @@
>   { MIBDECL(pfLimitFragments) },  \
>   { MIBDECL(pfLimitMaxTables) },  \
>   { MIBDECL(pfLimitMaxTableEntries) },\
> + { MIBDECL(pfLimitAnchors) },\
>   { MIBDECL(pfTimeouts) },\
>   { MIBDECL(pfTimeoutTcpFirst) }, \
>   { MIBDECL(pfTimeoutTcpOpening) },   \
> Index: usr.sbin/snmpd/mib.h
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/mib.h,v
> retrieving revision 1.41
> diff -u -p -r1.41 mib.h
> --- usr.sbin/snmpd/mib.h  19 Jan 2022 10:26:37 -  1.41
> +++ usr.sbin/snmpd/mib.h  6 Oct 2022 16:14:32 -
> @@ -550,6 +550,7 @@
>  #define MIB_pfLimitFragments MIB_pfLimits, 3
>  #define MIB_pfLimitMaxTables MIB_pfLimits, 4
>  #define MIB_pfLimitMaxTableEntries   MIB_pfLimits, 5
> +#define MIB_pfLimitAnchors   MIB_pfLimits, 6
>  #define MIB_pfTimeouts   MIB_pfMIBObjects, 7
>  #define MIB_pfTimeoutTcpFirstMIB_pfTimeouts, 1
>  #define MIB_pfTimeoutTcpOpening  MIB_pfTimeouts, 2
> @@ -1126,6 +1127,7 @@
>   { MIBDECL(pfLimitFragments) },  \
>   { MIBDECL(pfLimitMaxTables) },  \
>   { MIBDECL(pfLimitMaxTableEntries) },\
> + { MIBDECL(pfLimitAnchors) },\
>   { MIBDECL(pfTimeouts) },\
>   { MIBDECL(pfTimeoutTcpFirst) }, \
>   { MIBDECL(pfTimeoutTcpOpening) },   \
> Index: libexec/snmpd/snmpd_metrics/mib.c
> ===
> RCS file: /cvs/src/libexec/snmpd/snmpd_metrics/mib.c,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 mib.c
> --- libexec/snmpd/snmpd_metrics/mib.c 1 Sep 2022 14:20:34 -   1.1.1.1
> +++ libexec/snmpd/snmpd_metrics/mib.c 6 Oct 2022 16:14:32 -
> @@ -146,6 +146,7 

Re: tftpd: add -R for read-only mode/reduced pledges

2022-10-04 Thread Stuart Henderson
On 2022/10/04 10:36, David Gwynne wrote:
> On Sun, Oct 02, 2022 at 06:32:04PM +, Klemens Nanni wrote:
> > diskless(8) just needs tftpd(8) to deliver files, none of the possibly
> > untrusted clients are supposed to ever write anything.
> > 
> > Either way, even when run without -c, a single file writable by _tftpd
> > might be enough for a malicious client to fill up the server's disk.
> > 
> > A proper read-only mode ("stdio rpath dns inet") seems much safer.
> 
> agreed. i'm ok with this diff, but it's worth asking if we can make the
> default read-only and ask people to opt in for write (and create) before
> this specific diff goes in. ie, read-only be default, '-w' to enable
> write mode, '-c' to enable write+create?

yes please!



Re: Remove some unnecessary setproctitle(3) format strings

2022-09-27 Thread Stuart Henderson
These programs seem OK as-is, they are following the advice in
https://man.openbsd.org/setproctitle.3#CAVEATS

On 2022/09/26 18:06, Josiah Frentsos wrote:
> Index: sbin/dhcpleased/engine.c
> ===
> RCS file: /cvs/src/sbin/dhcpleased/engine.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 engine.c
> --- sbin/dhcpleased/engine.c  5 May 2022 14:44:59 -   1.38
> +++ sbin/dhcpleased/engine.c  26 Sep 2022 21:43:28 -
> @@ -197,7 +197,7 @@ engine(int debug, int verbose)
>   if (unveil(NULL, NULL) == -1)
>   fatal("unveil");
>  
> - setproctitle("%s", "engine");
> + setproctitle("engine");
>   log_procinit("engine");
>  
>   if (setgroups(1, >pw_gid) ||
> Index: sbin/dhcpleased/frontend.c
> ===
> RCS file: /cvs/src/sbin/dhcpleased/frontend.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 frontend.c
> --- sbin/dhcpleased/frontend.c14 Jul 2022 15:23:09 -  1.30
> +++ sbin/dhcpleased/frontend.c26 Sep 2022 21:43:29 -
> @@ -151,7 +151,7 @@ frontend(int debug, int verbose)
>   if (unveil(NULL, NULL) == -1)
>   fatal("unveil");
>  
> - setproctitle("%s", "frontend");
> + setproctitle("frontend");
>   log_procinit("frontend");
>  
>   if ((ioctlsock = socket(AF_INET, SOCK_DGRAM | SOCK_CLOEXEC, 0)) == -1)
> Index: sbin/slaacd/engine.c
> ===
> RCS file: /cvs/src/sbin/slaacd/engine.c,v
> retrieving revision 1.84
> diff -u -p -r1.84 engine.c
> --- sbin/slaacd/engine.c  26 Aug 2022 00:02:08 -  1.84
> +++ sbin/slaacd/engine.c  26 Sep 2022 21:43:29 -
> @@ -372,7 +372,7 @@ engine(int debug, int verbose)
>   if (unveil(NULL, NULL) == -1)
>   fatal("unveil");
>  
> - setproctitle("%s", "engine");
> + setproctitle("engine");
>   log_procinit("engine");
>  
>   if (setgroups(1, >pw_gid) ||
> Index: sbin/slaacd/frontend.c
> ===
> RCS file: /cvs/src/sbin/slaacd/frontend.c,v
> retrieving revision 1.64
> diff -u -p -r1.64 frontend.c
> --- sbin/slaacd/frontend.c12 Jul 2022 16:54:59 -  1.64
> +++ sbin/slaacd/frontend.c26 Sep 2022 21:43:29 -
> @@ -153,7 +153,7 @@ frontend(int debug, int verbose)
>   if (unveil(NULL, NULL) == -1)
>   fatal("unveil");
>  
> - setproctitle("%s", "frontend");
> + setproctitle("frontend");
>   log_procinit("frontend");
>  
>   if ((ioctlsock = socket(AF_INET6, SOCK_DGRAM | SOCK_CLOEXEC, 0)) == -1)
> Index: sbin/unwind/frontend.c
> ===
> RCS file: /cvs/src/sbin/unwind/frontend.c,v
> retrieving revision 1.73
> diff -u -p -r1.73 frontend.c
> --- sbin/unwind/frontend.c13 Mar 2022 15:14:01 -  1.73
> +++ sbin/unwind/frontend.c26 Sep 2022 21:43:30 -
> @@ -207,7 +207,7 @@ frontend(int debug, int verbose)
>   if (chdir("/") == -1)
>   fatal("chdir(\"/\")");
>  
> - setproctitle("%s", "frontend");
> + setproctitle("frontend");
>   log_procinit("frontend");
>  
>   if (setgroups(1, >pw_gid) ||
> Index: sbin/unwind/resolver.c
> ===
> RCS file: /cvs/src/sbin/unwind/resolver.c,v
> retrieving revision 1.155
> diff -u -p -r1.155 resolver.c
> --- sbin/unwind/resolver.c12 Mar 2022 14:35:29 -  1.155
> +++ sbin/unwind/resolver.c26 Sep 2022 21:43:30 -
> @@ -368,7 +368,7 @@ resolver(int debug, int verbose)
>   if ((pw = getpwnam(UNWIND_USER)) == NULL)
>   fatal("getpwnam");
>  
> - setproctitle("%s", "resolver");
> + setproctitle("resolver");
>   log_procinit("resolver");
>  
>   if (setgroups(1, >pw_gid) ||
> Index: usr.bin/ssh/sshd.c
> ===
> RCS file: /cvs/src/usr.bin/ssh/sshd.c,v
> retrieving revision 1.591
> diff -u -p -r1.591 sshd.c
> --- usr.bin/ssh/sshd.c17 Sep 2022 10:34:29 -  1.591
> +++ usr.bin/ssh/sshd.c26 Sep 2022 21:43:34 -
> @@ -492,7 +492,7 @@ privsep_preauth(struct ssh *ssh)
>   set_log_handler(mm_log_handler, pmonitor);
>  
>   privsep_preauth_child();
> - setproctitle("%s", "[net]");
> + setproctitle("[net]");
>   if (box != NULL)
>   ssh_sandbox_child(box);
>  
> @@ -1627,7 +1627,7 @@ main(int ac, char **av)
>   if ((cfg = sshbuf_new()) == NULL)
>   fatal_f("sshbuf_new failed");
>   if (rexeced_flag) {
> - setproctitle("%s", "[rexeced]");
> + setproctitle("[rexeced]");
>   recv_rexec_state(REEXEC_CONFIG_PASS_FD, cfg);
>   if (!debug_flag) {
>   startup_pipe = 

unbound 1.16.3

2022-09-21 Thread Stuart Henderson
Released today so I haven't been able to give it much testing yet...

Index: doc/Changelog
===
RCS file: /cvs/src/usr.sbin/unbound/doc/Changelog,v
retrieving revision 1.45
diff -u -p -r1.45 Changelog
--- doc/Changelog   29 Aug 2022 16:05:00 -  1.45
+++ doc/Changelog   21 Sep 2022 12:41:57 -
@@ -1,5 +1,5 @@
-7 February 2022: Wouter
-   - Fix that TCP interface does not use TLS when TLS is also configured.
+21 September 2022: Wouter
+   - Patch for CVE-2022-3204 Non-Responsive Delegation Attack.
 
 1 August 2022: Wouter
- Fix the novel ghost domain issues CVE-2022-30698 and CVE-2022-30699.
Index: config.guess
===
RCS file: /cvs/src/usr.sbin/unbound/config.guess,v
retrieving revision 1.12
diff -u -p -r1.12 config.guess
--- config.guess7 Jun 2022 15:42:53 -   1.12
+++ config.guess21 Sep 2022 12:41:57 -
@@ -4,7 +4,7 @@
 
 # shellcheck disable=SC2006,SC2268 # see below for rationale
 
-timestamp='2022-05-25'
+timestamp='2022-08-01'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -1036,7 +1036,7 @@ EOF
 k1om:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
-loongarch32:Linux:*:* | loongarch64:Linux:*:* | loongarchx32:Linux:*:*)
+loongarch32:Linux:*:* | loongarch64:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
 m32r*:Linux:*:*)
Index: config.sub
===
RCS file: /cvs/src/usr.sbin/unbound/config.sub,v
retrieving revision 1.11
diff -u -p -r1.11 config.sub
--- config.sub  23 Feb 2022 12:04:05 -  1.11
+++ config.sub  21 Sep 2022 12:41:57 -
@@ -4,7 +4,7 @@
 
 # shellcheck disable=SC2006,SC2268 # see below for rationale
 
-timestamp='2022-01-03'
+timestamp='2022-08-01'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -1207,7 +1207,7 @@ case $cpu-$vendor in
| k1om \
| le32 | le64 \
| lm32 \
-   | loongarch32 | loongarch64 | loongarchx32 \
+   | loongarch32 | loongarch64 \
| m32c | m32r | m32rle \
| m5200 | m68000 | m680[012346]0 | m68360 | m683?2 | 
m68k \
| m6811 | m68hc11 | m6812 | m68hc12 | m68hcs12x \
Index: configure
===
RCS file: /cvs/src/usr.sbin/unbound/configure,v
retrieving revision 1.47
diff -u -p -r1.47 configure
--- configure   29 Aug 2022 16:04:59 -  1.47
+++ configure   21 Sep 2022 12:41:57 -
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.71 for unbound 1.16.2.
+# Generated by GNU Autoconf 2.71 for unbound 1.16.3.
 #
 # Report bugs to https://github.com/NLnetLabs/unbound/issues>.
 #
@@ -622,8 +622,8 @@ MAKEFLAGS=
 # Identity of this package.
 PACKAGE_NAME='unbound'
 PACKAGE_TARNAME='unbound'
-PACKAGE_VERSION='1.16.2'
-PACKAGE_STRING='unbound 1.16.2'
+PACKAGE_VERSION='1.16.3'
+PACKAGE_STRING='unbound 1.16.3'
 PACKAGE_BUGREPORT='unbound-b...@nlnetlabs.nl or 
https://github.com/NLnetLabs/unbound/issues'
 PACKAGE_URL=''
 
@@ -1503,7 +1503,7 @@ if test "$ac_init_help" = "long"; then
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures unbound 1.16.2 to adapt to many kinds of systems.
+\`configure' configures unbound 1.16.3 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1569,7 +1569,7 @@ fi
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of unbound 1.16.2:";;
+ short | recursive ) echo "Configuration of unbound 1.16.3:";;
esac
   cat <<\_ACEOF
 
@@ -1812,7 +1812,7 @@ fi
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-unbound configure 1.16.2
+unbound configure 1.16.3
 generated by GNU Autoconf 2.71
 
 Copyright (C) 2021 Free Software Foundation, Inc.
@@ -2469,7 +2469,7 @@ cat >config.log <<_ACEOF
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by unbound $as_me 1.16.2, which was
+It was created by unbound $as_me 1.16.3, which was
 generated by GNU Autoconf 2.71.  Invocation command line was
 
   $ $0$ac_configure_args_raw
@@ -3233,11 +3233,11 @@ UNBOUND_VERSION_MAJOR=1
 
 UNBOUND_VERSION_MINOR=16
 
-UNBOUND_VERSION_MICRO=2
+UNBOUND_VERSION_MICRO=3
 
 
 LIBUNBOUND_CURRENT=9
-LIBUNBOUND_REVISION=18

Re: iked problems with Apple clients in 7.1

2022-09-21 Thread Stuart Henderson
On 2022/05/21 17:04, Tobias Heider wrote:
> On Sat, May 21, 2022 at 12:51:19PM +0100, Stuart Henderson wrote:
> > On 2022/05/21 13:44, Tobias Heider wrote:
> > > On Fri, May 20, 2022 at 03:41:12PM +0100, Stuart Henderson wrote:
> > > > I ran into problems with Apple clients failing to connect to
> > > > iked after updating a machine to 7.1, introduced by
> > > > https://github.com/openbsd/src/commit/e3f5cf2ee26929d75dc2df9e86d97c36b2a94268
> > > > 
> > > > spi=0xac3d46687441f957: recv IKE_SA_INIT req 0 peer 
> > > > rrr.rrr.rrr.rr:49436 local lll.ll.lll.lll:500, 308 bytes, policy 
> > > > 'default'
> > > > spi=0xac3d46687441f957: send IKE_SA_INIT res 0 peer 
> > > > rrr.rrr.rrr.rr:49436 local lll.ll.lll.lll:500, 341 bytes
> > > > spi=0xac3d46687441f957: recv IKE_AUTH req 1 peer rrr.rrr.rrr.rr:64892 
> > > > local lll.ll.lll.lll:4500, 368 bytes, policy 'default'
> > > > policy_test: localid mismatch
> > > > spi=0xac3d46687441f957: ikev2_ike_auth_recv: no compatible policy found
> > > > spi=0xac3d46687441f957: ikev2_send_auth_failed: authentication failed 
> > > > for
> > > > spi=0xac3d46687441f957: send IKE_AUTH res 1 peer rrr.rrr.rrr.rr:64892 
> > > > local lll.ll.lll.lll:4500, 80 bytes, NAT-T
> > > > spi=0xac3d46687441f957: sa_free: authentication failed
> > > > 
> > > > I don't have full details of config done on the other side nor any
> > > > fruit-based phones to test from myself, did anyone already run into this
> > > > and figure out a way around it?
> > > 
> > > Hey Stuart,
> > > 
> > > I haven't seen this before but I have a theory.
> > > Based on the commit you pointed out the problem is probably the
> > > `dstid kk.kkk.kkk.kkk` line which was ignored before this change.
> > > 
> > > This should be easy to check without access to the other device if
> > > you enable verbose logging on your server and look for "ikev2_pld_id"
> > > above the error. I suspect that the ID sent by your apple peer might
> > > actually be a different one than kk.kkk.kkk.kkk.
> > > 
> > > Another thing you could try is just removing the dstid part and see
> > > if that works.
> > 
> > Oh sorry I wasn't clear about which one the apple was using - the one with
> > "kk.kkk.kkk.kkk" is a lan-to-lan configuration (fixed IP on both endpoints) 
> > -
> > the apple is expected to be using the first "from 0.0.0.0/0 to dynamic" one
> > which doesn't have any dstid set, and that's the only one where the IP 
> > matches.
> 
> Oh, makes sense.  I think it may still be related to the IDs, so checking if
> ikev2_pld_id matches what you expect for srcid might be a good start.
> Maybe the apple client is sending something different than 
> ""
> in their dstid.

I was able to get someone to do a couple of tests (after accidentally updating
that machine and running into the problem again..) - debug log from iked shows

2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_payloads: decrypted payload 
IDi nextpayload NOTIFY critical 0x00 length 28
2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_id: id 
FQDN/vpn2.xxx length 24
2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_payloads: decrypted payload 
NOTIFY nextpayload IDr critical 0x00 length 8
2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_notify: protoid NONE 
spisize 0 type INITIAL_CONTACT
2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_payloads: decrypted payload 
IDr nextpayload CP critical 0x00 length 12
2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_id: id FQDN/user length 8
...
2022-09-21T09:10:44.371Z vpn2 iked[9682]: ikev2_resp_recv: NAT-T message 
received, updated SA
2022-09-21T09:10:44.371Z vpn2 iked[9682]: sa_stateok: SA_INIT flags 0x, 
require 0x
2022-09-21T09:10:44.371Z vpn2 iked[9682]: spi=0xbb3b1aa559598982: sa_state: 
SA_INIT -> EAP
2022-09-21T09:10:44.371Z vpn2 iked[9682]: policy_lookup: peerid 
'vpn2.xxx'
2022-09-21T09:10:44.371Z vpn2 iked[9682]: policy_lookup: localid 'user'
2022-09-21T09:10:44.372Z vpn2 iked[9682]: policy_test: localid mismatch
2022-09-21T09:10:44.372Z vpn2 iked[9682]: spi=0xbb3b1aa559598982: 
ikev2_ike_auth_recv: no compatible policy found
2022-09-21T09:10:44.372Z vpn2 iked[9682]: spi=0xbb3b1aa559598982: 
ikev2_send_auth_failed: authentication failed for

Which, given that the apple device is initiator, suggests that they're
sending the IDs the wrong way round. I don't know whether that's a
bug Apple-side or a config issue, either way it's going to be hard
to fix as I d

Re: ftp(1) connection timeouts and hostnames with multiple addresses

2022-09-13 Thread Stuart Henderson
On 2022/09/13 13:25, Todd C. Miller wrote:
> On Tue, 13 Sep 2022 20:21:58 +0100, Stuart Henderson wrote:
> 
> > Oh great, that works very nicely for this use case, thank you. Connecting
> > via a proxy also still works as I'd expect. I'm basically OK with that
> > diff though I'd like to test the installer (I have some mkb/mkr running
> > now).
> 
> Great.  I've only done minimal testing (and no installer tests).
> 
> > Then we could either have fw_update call ftp with something like "-w 12",
> > or automatically lower ftp(1)'s default as with the diff in
> > https://marc.info/?l=openbsd-tech=165736755609602=2
> 
> I'd be OK with that too but it should be a follow-on commit.

Absolutely.



Re: ftp(1) connection timeouts and hostnames with multiple addresses

2022-09-13 Thread Stuart Henderson
On 2022/09/13 10:57, Todd C. Miller wrote:
> On Sat, 09 Jul 2022 12:53:17 +0100, Stuart Henderson wrote:
> 
> > I'm trying to teach ftp(1) to do something like gui web browsers do
> > and reduce the HTTP/HTTPS connection timeout from the default (75 seconds)
> > if there are multiple addresses behind a hostname.
> >
> > There's an existing connection timeout mechanism that I thought it
> > might make sense to reuse...
> >
> >  -w seconds
> >  For URL format connections to HTTP/HTTPS servers, abort a slow
> >  connection after seconds.
> 
> Here's a diff to implement timed_connect().  It replaces the alarm
> used for slow connections with non-blocking connect(2) and ppoll(2).
> I've also replaced the other connect(2) + connect_wait() calls with
> timed_connect() so the -w option now works for more that just http.

Oh great, that works very nicely for this use case, thank you. Connecting
via a proxy also still works as I'd expect. I'm basically OK with that
diff though I'd like to test the installer (I have some mkb/mkr running
now).

Then we could either have fw_update call ftp with something like "-w 12",
or automatically lower ftp(1)'s default as with the diff in
https://marc.info/?l=openbsd-tech=165736755609602=2

Looking at fw_update.sh I see there's already a timer mechanism there
which I'm rather confused about because I've definitely seen the installer
sit for a long time at that point before (checking svn log for my config
files, I changed my PF rules in July when I ran into this with 7.1
autoinstalls)... Even if that shell timer was working as expected,
the timeout in ftp is more useful as it gives a chance to move past
a single downed server.

>  - todd
> 
> Index: usr.bin/ftp/extern.h
> ===
> RCS file: /cvs/src/usr.bin/ftp/extern.h,v
> retrieving revision 1.52
> diff -u -p -u -r1.52 extern.h
> --- usr.bin/ftp/extern.h  2 Feb 2021 12:58:42 -   1.52
> +++ usr.bin/ftp/extern.h  13 Sep 2022 16:43:30 -
> @@ -62,6 +62,7 @@
>   */
>  
>  #include 
> +#include 
>  
>  void abort_remote(FILE *);
>  void abortpt(int);
> @@ -75,7 +76,6 @@ voidcmdabort(int);
>  void cmdscanner(int);
>  int  command(const char *, ...);
>  int  confirm(const char *, const char *);
> -int  connect_wait(int);
>  FILE   *dataconn(const char *);
>  int  foregroundproc(void);
>  int  fileindir(const char *, const char *);
> @@ -109,6 +109,7 @@ void  sethash(int, char **);
>  void setpeer(int, char **);
>  void setttywidth(int);
>  char   *slurpstring(void);
> +int  timed_connect(int s, const struct sockaddr *, socklen_t, int);
>  
>  __dead void  usage(void);
>  
> Index: usr.bin/ftp/fetch.c
> ===
> RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
> retrieving revision 1.209
> diff -u -p -u -r1.209 fetch.c
> --- usr.bin/ftp/fetch.c   8 Sep 2022 11:12:44 -   1.209
> +++ usr.bin/ftp/fetch.c   13 Sep 2022 16:40:00 -
> @@ -173,14 +173,6 @@ url_encode(const char *path)
>   return (epath);
>  }
>  
> -/* ARGSUSED */
> -static void
> -tooslow(int signo)
> -{
> - dprintf(STDERR_FILENO, "%s: connect taking too long\n", __progname);
> - _exit(2);
> -}
> -
>  /*
>   * Copy a local file (used by the OpenBSD installer).
>   * Returns -1 on failure, 0 on success
> @@ -604,14 +596,8 @@ noslash:
>   }
>  #endif /* !SMALL */
>  
> - if (connect_timeout) {
> - (void)signal(SIGALRM, tooslow);
> - alarmtimer(connect_timeout);
> - }
> -
> - for (error = connect(fd, res->ai_addr, res->ai_addrlen);
> - error != 0 && errno == EINTR; error = connect_wait(fd))
> - continue;
> + error = timed_connect(fd, res->ai_addr, res->ai_addrlen,
> + connect_timeout);
>   if (error != 0) {
>   save_errno = errno;
>   close(fd);
> @@ -700,11 +686,6 @@ noslash:
>   }
>  #endif
>  
> - if (connect_timeout) {
> - signal(SIGALRM, SIG_DFL);
> - alarmtimer(0);
> - }
> -
>   /*
>* Construct and send the request. Proxy requests don't want leading /.
>*/
> @@ -1242,7 +1223,6 @@ aborthttp(int signo)
>  {
>   const char errmsg[] = "\nfetch aborted.\n";
>  
> - alarmtimer(0);
>   write(fileno(ttyout), errmsg, sizeof(errmsg) - 1);
>   longjmp(httpabort, 1);
>  }
> Index: usr.bin/ftp/ftp.1
> ==

Re: ifconfig, wireguard output less verbose, unless -A or

2022-09-07 Thread Stuart Henderson
On 2022/09/07 15:25, Mikolaj Kucharski wrote:
> Hi.
> 
> I didn't get a lof of feedback on this on the code level, however
> got some intput on manual page changes. At the end of the email is
> ifconfig.8 change from jmc@ and ifconfig.c from me.
> 
> 
> On Sat, Sep 03, 2022 at 04:51:03PM +0100, Jason McIntyre wrote:
> > On Sat, Sep 03, 2022 at 08:55:51AM +, Mikolaj Kucharski wrote:
> > > Hi,
> > > 
> > > I tried to address what jmc@ mentioned below. I don't really know
> > > mdoc(7) and English is not my native language, so I imagine there is
> > > place for improvement in the wg(4) diff.
> > > 
> > 
> > hi.
> > 
> > after looking again, i think maybe ifconfig.8 is the better place, but
> > just not where it was originally proposed. by way of a peace offering,
> > how about the diff below?
> > 
> > jmc
> > 
> [...]

It's all in ifndef SMALL so there are no ramdisk space concerns.
Works as expected, I think it's a good idea. It's OK with me.


> 
> Index: ifconfig.c
> ===
> RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
> retrieving revision 1.456
> diff -u -p -u -r1.456 ifconfig.c
> --- ifconfig.c8 Jul 2022 07:04:54 -   1.456
> +++ ifconfig.c7 Sep 2022 15:18:50 -
> @@ -363,7 +363,7 @@ void  unsetwgpeer(const char *, int);
>  void unsetwgpeerpsk(const char *, int);
>  void unsetwgpeerall(const char *, int);
>  
> -void wg_status();
> +void wg_status(int);
>  #else
>  void setignore(const char *, int);
>  #endif
> @@ -679,7 +679,7 @@ void  printgroupattribs(char *);
>  void printif(char *, int);
>  void printb_status(unsigned short, unsigned char *);
>  const char *get_linkstate(int, int);
> -void status(int, struct sockaddr_dl *, int);
> +void status(int, struct sockaddr_dl *, int, int);
>  __dead void  usage(void);
>  const char *get_string(const char *, const char *, u_int8_t *, int *);
>  int  len_string(const u_int8_t *, int);
> @@ -1195,7 +1195,7 @@ printif(char *name, int ifaliases)
>   continue;
>   ifdata = ifa->ifa_data;
>   status(1, (struct sockaddr_dl *)ifa->ifa_addr,
> - ifdata->ifi_link_state);
> + ifdata->ifi_link_state, ifaliases);
>   count++;
>   noinet = 1;
>   continue;
> @@ -3316,7 +3316,7 @@ get_linkstate(int mt, int link_state)
>   * specified, show it and it only; otherwise, show them all.
>   */
>  void
> -status(int link, struct sockaddr_dl *sdl, int ls)
> +status(int link, struct sockaddr_dl *sdl, int ls, int ifaliases)
>  {
>   const struct afswtch *p = afp;
>   struct ifmediareq ifmr;
> @@ -3391,7 +3391,7 @@ status(int link, struct sockaddr_dl *sdl
>   mpls_status();
>   pflow_status();
>   umb_status();
> - wg_status();
> + wg_status(ifaliases);
>  #endif
>   trunk_status();
>   getifgroups();
> @@ -5907,7 +5907,7 @@ process_wg_commands(void)
>  }
>  
>  void
> -wg_status(void)
> +wg_status(int ifaliases)
>  {
>   size_t   i, j, last_size;
>   struct timespec  now;
> @@ -5942,45 +5942,47 @@ wg_status(void)
>   printf("\twgpubkey %s\n", key);
>   }
>  
> - wg_peer = _interface->i_peers[0];
> - for (i = 0; i < wg_interface->i_peers_count; i++) {
> - b64_ntop(wg_peer->p_public, WG_KEY_LEN,
> - key, sizeof(key));
> - printf("\twgpeer %s\n", key);
> -
> - if (wg_peer->p_flags & WG_PEER_HAS_PSK)
> - printf("\t\twgpsk (present)\n");
> -
> - if (wg_peer->p_flags & WG_PEER_HAS_PKA && wg_peer->p_pka)
> - printf("\t\twgpka %u (sec)\n", wg_peer->p_pka);
> -
> - if (wg_peer->p_flags & WG_PEER_HAS_ENDPOINT) {
> - if (getnameinfo(_peer->p_sa, wg_peer->p_sa.sa_len,
> - hbuf, sizeof(hbuf), sbuf, sizeof(sbuf),
> - NI_NUMERICHOST | NI_NUMERICSERV) == 0)
> - printf("\t\twgendpoint %s %s\n", hbuf, sbuf);
> - else
> - printf("\t\twgendpoint unable to print\n");
> - }
> + if (ifaliases) {
> + wg_peer = _interface->i_peers[0];
> + for (i = 0; i < wg_interface->i_peers_count; i++) {
> + b64_ntop(wg_peer->p_public, WG_KEY_LEN,
> + key, sizeof(key));
> + printf("\twgpeer %s\n", key);
> +
> + if (wg_peer->p_flags & WG_PEER_HAS_PSK)
> + printf("\t\twgpsk (present)\n");
> +
> + if (wg_peer->p_flags & WG_PEER_HAS_PKA && 
> wg_peer->p_pka)
> + printf("\t\twgpka %u (sec)\n", wg_peer->p_pka);
> +
> + if (wg_peer->p_flags & WG_PEER_HAS_ENDPOINT) {
> +   

Re: Support Wacom One S (CTL-472)

2022-09-03 Thread Stuart Henderson
On 2022/09/03 21:37, Marcus Glocker wrote:
> On Sat, Sep 03, 2022 at 05:43:25PM +0200, Caspar Schutijser wrote:
> 
> > Hi,
> > 
> > On Sat, Sep 03, 2022 at 05:00:00PM +0200, Stefan Hagen wrote:
> > > This is a better version of an earlier attempt to make my wacom tablet
> > > work. I have the tablet here in Bad Liebenzell if you want to give it a
> > > spin (on my or on your machine).
> > > 
> > > Comments? OK?
> > 
> > I don't feel entirely qualified to give OKs in this area so I won't do
> > that. But I tested it on my machine with sdk@'s tablet and it works well
> > here. Nice!
> > 
> > Is there any chance it breaks other supported tablets? Should it be
> > tested there as well?
> 
> The driver only attaches to specific products, currently
> Intuos Draw, CTL-490.  So there shouldn't be too much to break I guess.

Agreed, I don't see how it can break anything that already works.

> > One whitespace nit below.

+1

also make sure to commit usbdevs first to uodate rcsid, then re-run
"make" to copy the new rcsid to the "generated from" comment before
commiting the usbdevs/usbdevs_data.j files.

OK sthen

> > Caspar
> > 
> > > 
> > > Best Regards,
> > > Stefan
> 
> I have an Wacom One CTL-672, never used it on OpenBSD.  Currently
> it attaches to ums(4).  Works fine with that.  It also works fine
> when attaching to uwacom(4), without and with your diff.  It doesn't
> seem to require specific 'tsscale' nor 'loc_tip_press' settings.
> I wonder if it would change something.
> 
> Some very few comments inline.
> 
> > > Index: share/man/man4/uwacom.4
> > > ===
> > > RCS file: /cvs/src/share/man/man4/uwacom.4,v
> > > retrieving revision 1.2
> > > diff -u -p -u -p -r1.2 uwacom.4
> > > --- share/man/man4/uwacom.4   12 Sep 2016 10:39:06 -  1.2
> > > +++ share/man/man4/uwacom.4   1 Sep 2022 19:57:37 -
> > > @@ -42,6 +42,7 @@ driver supports the following Wacom tabl
> > >  .Bl -column "Intuos Draw" "Model Number" -offset 6n
> > >  .It Em Name Ta Em Model Number
> > >  .It Li Intuos Draw Ta CTL-490
> > > +.It Li One Ta CTL-472
> 
> Shouldn't that be 'One S'?
> 
> > >  .El
> > >  .Sh SEE ALSO
> > >  .Xr uhidev 4 ,
> > > Index: sys/dev/usb/usbdevs
> > > ===
> > > RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> > > retrieving revision 1.748
> > > diff -u -p -u -p -r1.748 usbdevs
> > > --- sys/dev/usb/usbdevs   23 Aug 2022 08:10:35 -  1.748
> > > +++ sys/dev/usb/usbdevs   1 Sep 2022 19:57:38 -
> > > @@ -4613,6 +4613,7 @@ product WACOM GRAPHIRE3_4X5 0x0013  Graph
> > >  product WACOM GRAPHIRE4_4X5  0x0015  Graphire4 Classic A6
> > >  product WACOM INTUOSA5   0x0021  Intuos A5
> > >  product WACOM INTUOS_DRAW0x033b  Intuos Draw (CTL-490)
> > > +product WACOM ONE_S  0x037a  One S (CTL-472)
> > >  product WACOM INTUOS_PRO_S   0x0392  Intuos Pro S
> > >  
> > >  /* WAGO Kontakttechnik products */
> > > Index: sys/dev/usb/usbdevs.h
> > > ===
> > > RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
> > > retrieving revision 1.760
> > > diff -u -p -u -p -r1.760 usbdevs.h
> > > --- sys/dev/usb/usbdevs.h 23 Aug 2022 08:11:01 -  1.760
> > > +++ sys/dev/usb/usbdevs.h 1 Sep 2022 19:57:38 -
> > > @@ -1,4 +1,4 @@
> > > -/*   $OpenBSD: usbdevs.h,v 1.760 2022/08/23 08:11:01 jsg Exp $   
> > > */
> > > +/*   $OpenBSD$   */
> > >  
> > >  /*
> > >   * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
> > > @@ -4620,6 +4620,7 @@
> > >  #define  USB_PRODUCT_WACOM_GRAPHIRE4_4X5 0x0015  /* Graphire4 
> > > Classic A6 */
> > >  #define  USB_PRODUCT_WACOM_INTUOSA5  0x0021  /* Intuos A5 */
> > >  #define  USB_PRODUCT_WACOM_INTUOS_DRAW   0x033b  /* Intuos Draw 
> > > (CTL-490) */
> > > +#define  USB_PRODUCT_WACOM_ONE_S 0x037a  /* One S (CTL-472) */
> > >  #define  USB_PRODUCT_WACOM_INTUOS_PRO_S  0x0392  /* Intuos Pro S 
> > > */
> > >  
> > >  /* WAGO Kontakttechnik products */
> > > Index: sys/dev/usb/usbdevs_data.h
> > > ===
> > > RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
> > > retrieving revision 1.754
> > > diff -u -p -u -p -r1.754 usbdevs_data.h
> > > --- sys/dev/usb/usbdevs_data.h23 Aug 2022 08:11:01 -  1.754
> > > +++ sys/dev/usb/usbdevs_data.h1 Sep 2022 19:57:39 -
> > > @@ -1,4 +1,4 @@
> > > -/*   $OpenBSD: usbdevs_data.h,v 1.754 2022/08/23 08:11:01 jsg Exp $  
> > > */
> > > +/*   $OpenBSD$   */
> > >  
> > >  /*
> > >   * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
> > > @@ -11824,6 +11824,10 @@ const struct usb_known_product usb_known
> > >   {
> > >   USB_VENDOR_WACOM, USB_PRODUCT_WACOM_INTUOS_DRAW,
> > >   "Intuos Draw (CTL-490)",
> > > + },
> > > + {
> > > + USB_VENDOR_WACOM, USB_PRODUCT_WACOM_ONE_S,

Re: unbound and cannot increase max open fds from 512 to 4152

2022-09-02 Thread Stuart Henderson
On 2022/09/02 11:25, Sebastian Benoit wrote:
> > > > Sep  2 06:39:58 x1c unbound: [14264:0] notice: Restart of unbound 
> > > > 1.16.0.
> > > > Sep  2 06:39:58 x1c unbound: [14264:0] notice: init module 0: validator
> > > > Sep  2 06:39:58 x1c unbound: [14264:0] notice: init module 1: iterator
> > > 
> > > As far as i understand, the number of fds that unbound is asking for is
> > > based on the num-threads, outgoing-num-tcp, interface and some other 
> > > setting
> > > in the unbound config.
> > 
> > Those particular settings mentioned I did not modified. However the
> > values are not that important. I expected /etc/login.conf.d/unbound to
> > be present on a fresh install. More on that below.
> 
> It would still be interesting why it wants to increase the limit to 4152.
> My list of settings is probably not complete. Show your config if you can.

The key thing here is that it's for reload not startup.
Easy to reproduce here.



Re: ps(1): add -d (descendancy) option to display parent/child process relationships

2022-09-01 Thread Stuart Henderson
On 2022/09/01 15:14, Martin Schröder wrote:
> Am Do., 1. Sept. 2022 um 05:38 Uhr schrieb Job Snijders :
> > Some ps(1) implementations have an '-d' ('descendancy') option. Through
> > ASCII art parent/child process relationships are grouped and displayed.
> >
> > Thoughts?
> 
> gnu ps has
> 
> -d Select all processes except session leaders.
> 
> and
> 
>f  ASCII art process hierarchy (forest).
> 
>--forest
>   ASCII art process tree.
> 
> Best
> Martin
> 

given the big differences for flags in ps between sysv-ish and bsd-ish OS,
it totally makes sense to follow the flag used by other BSDs here.



Re: add sendmmsg and recvmmsg systemcalls

2022-08-30 Thread Stuart Henderson
btw a few ports will likely pick this up:

paths/devel/glib2.log:Checking for function "recvmmsg" : NO
paths/net/tinc.log:checking for recvmmsg... no
paths/net/knot.log:checking for recvmmsg... no
paths/net/knot.log:Use recvmmsg:   no
paths/net/gdnsd.log:checking whether recvmmsg is declared... no
paths/net/gdnsd.log:checking for recvmmsg... no
paths/net/powerdns.log:checking for recvmmsg... no
paths/net/powerdns.log:checking for recvmmsg... (cached) no
paths/net/dnsdist.log:checking for recvmmsg... no
paths/net/powerdns_recursor.log:checking for recvmmsg... no
paths/sysutils/rsyslog,-elasticsearch.log:checking for recvmmsg... no




Re: unbound update

2022-08-29 Thread Stuart Henderson
On 2022/08/26 17:47, void wrote:
> On Wed, Aug 24, 2022 at 03:03:01PM +0100, Stuart Henderson wrote:
> > Anyone want to test this?
> > 
> > Any OKs?
> 
> Hello,
> 
> Seemed to patch OK and built OK with a -current made yesterday, on aarch64.
> 
> I'm a newbie at building/patching openbsd, so if there's anything you
> can suggest I test, I'll test. unbound is working.
> 
> unbound -V still reports Version 1.16.0 though.

Something went wrong with your patching/build if it shows 1.16.2, I confirmed
that it was updated.

for reference for building parts of base which have a Makefile.bsd-wrapper
file, normally use this:

make -f Makefile.bsd-wrapper obj
make -f Makefile.bsd-wrapper
doas make -f Makefile.bsd-wrapper install



Re: remove net/ofp.h? switch(4) remnant

2022-08-29 Thread Stuart Henderson

It could move to a private header in tcpdump though.

--
 Sent from a phone, apologies for poor formatting.

On 29 August 2022 08:03:30 Klemens Nanni  wrote:


Scratch that, tcpdump uses it.




Re: libfido2 update

2022-08-28 Thread Stuart Henderson
On 2022/08/24 17:09, Damien Miller wrote:
> Hi,
> 
> https://www.mindrot.org/misc/libfido2-1.11.0.diff contains an update
> for src/libfido2 from 1.8 to 1.11 (about 10 months of upstream
> development).
> 
> I've tested it with OpenSSH, which is the only thing in src/ that
> uses it as well as compiling www/chromium and performing a FIDO login
> with it.
> 
> ok?
> 
> -d
> 

Works for me, OK sthen@.

Would you mind adding NEWS from upstream so we can see a quick summary
of what's changed please?



Re: tetris(6) "Random Generator" and advanced controls

2022-08-28 Thread Stuart Henderson
On 2022/08/27 19:58, Tom MTT. wrote:
> Apparently, as some people pointed it out, DMARC doesn't influence spam score.

Depends on the mail server doing filtering.

> I thought that since my e-mail failed both SPF and DKIM and my DMARC
> policy was set to quarantine my mail would've been trashed instantly.

openbsd.org lists *strip* dkim headers anyway, so recipients with a strict
dmarc setup are unlikely to receive mail from sending domains with p=reject 
policy.

> I'm really sorry for the inconvenience, I won't do the same mistake twice.
> 
> ~ tmtt
> 



Re: [PATCH] Correctly (per POSIX) round up df usage percentage

2022-08-27 Thread Stuart Henderson
On 2022/08/27 15:53, наб wrote:
>  PROG=df
>  SRCS=df.c ffs_df.c ext2fs_df.c
> -LDADD=   -lutil
> -DPADD=   ${LIBUTIL}
> +LDADD=   -lutil -lm
> +DPADD=   ${LIBUTIL} ${LIBM}

df is used on the ramdisk, so this would need testing there (at least on
the tighter media on some archs).

at least one other ramdisk binary does pull in libm so the overall size
increase might not be terrible, but definitely would need checking.



Re: struct ifnet: remove unused if_switchport member

2022-08-26 Thread Stuart Henderson
On 2022/08/26 16:50, Klemens Nanni wrote:
> Running the packages.txt files through 'sort -u' and 'comm -12' and
> filtering for ports we actually have leaves us with
> 
>   aircrack-ng
>   firefox
>   firefox-esr
>   gst-plugins-bad1.0
>   gst-plugins-bad1.0-contrib
>   libgtop2
>   libusrsctp
>   miniupnpd
>   net-snmp
>   qt6-webengine
>   qtwebengine-opensource-src
>   thunderbird
>   warzone2100
>   zabbix
> 
> I'm sure that some of them are false positives because they
> a) define _KERNEL after including 
> b) don't do either of it on OpenBSD

likely the case for some of them, but checking a couple of likely
candidates I am pretty sure they do use it (e.g. net-snmp, libgtop2,
zabbix, via kvm_read).

> OK if I just REVISION bump all these and be done with it?  That'd be
> this list of PKGPATHs:

bumps need to be done *after* snapshots with the changes are available
(I would wait at least a day after) otherwise if a ports builder starts
a build after the bump but before they have the new header, the bump
won't help.

>   security/aircrack-ng
>   www/firefox-esr
>   www/mozilla-firefox
>   multimedia/gstreamer1/plugins-bad
>   devel/libgtop2
>   net/usrsctp
>   net/miniupnp/miniupnpd
>   net/net-snmp,-main
>   net/net-snmp,-tkmib

only REVISION-main for net-snmp, it's used for some mibII things in the
agent, tkmib is just a Perl/Tk-based viewer and doesn't go anywhere near
it so unaffected.

>   net/zabbix,-main
>   net/zabbix,-proxy,mysql
>   net/zabbix,-proxy,pgsql
>   net/zabbix,-proxy,sqlite3
>   net/zabbix,-server,mysql
>   net/zabbix,-server,pgsql
>   net/zabbix,-web

same only REVISION-main for zabbix (agent)

>   mail/mozilla-thunderbird
>   games/warzone2100



Re: struct ifnet: remove unused if_switchport member

2022-08-26 Thread Stuart Henderson
On 2022/08/26 09:49, Klemens Nanni wrote:
> grep and CVS agree that this is a switch(4) left-over.
> 
> OK?

This is exported to userland isn't it?

If so, I think all ports using it will need a bump.


> Index: if_var.h
> ===
> RCS file: /cvs/src/sys/net/if_var.h,v
> retrieving revision 1.114
> diff -u -p -r1.114 if_var.h
> --- if_var.h  20 Feb 2021 04:55:52 -  1.114
> +++ if_var.h  26 Aug 2022 09:47:37 -
> @@ -133,7 +133,6 @@ struct ifnet {/* and the 
> entries */
>   int if_pcount;  /* [N] # of promiscuous listeners */
>   unsigned int if_bridgeidx;  /* [K] used by bridge ports */
>   caddr_t if_bpf; /* packet filter structure */
> - caddr_t if_switchport;  /* used by switch ports */
>   caddr_t if_mcast;   /* used by multicast code */
>   caddr_t if_mcast6;  /* used by IPv6 multicast code */
>   caddr_t if_pf_kif;  /* pf interface abstraction */
> 



Re: bgpd silence "connection from non-peer" unless verbose

2022-08-25 Thread Stuart Henderson
On 2022/08/25 14:38, Claudio Jeker wrote:
> On Thu, Aug 25, 2022 at 09:23:01AM +0100, Stuart Henderson wrote:
> > On 2022/08/24 18:47, Denis Fondras wrote:
> > > Le Tue, Aug 23, 2022 at 06:28:12PM +0200, Claudio Jeker a écrit :
> > > > I noticed that the "connection from non-peer" message can fill the log 
> > > > and
> > > > be so chatty that it is hard to see the other messages. The system I see
> > > > this on is a bit special since it gets hammered by incorrectly 
> > > > configured
> > > > systems. Maybe other people find this message helpful. If so please
> > > > speak up now because I think the message does not add much info and 
> > > > should
> > > > be skipped unless verbose logging is used.
> > > > 
> > > 
> > > I agree with this change (I also have a log full of this message).
> > 
> > btw I like the log message, it shows me if I messed up and forgot to add a
> > session, or if someone else messed up and added a session without arranging
> > it (or typoed the address, etc). But I only allow port 179 connections from
> > possible candidates for peering (IXP peering lans etc) - I consider that
> > good practice anyway - and means it isn't too noisy.
> 
> True but in my case of a route collector misconfigured neighbors try to
> connect more or less every other second. This results in a lot of log
> chatter that is very annoying.
> 
> Maybe bgpd needs to keep some state so that the message is not shown over and
> over again.

Looking at the actual log message I see -v isn't much more noisy for bgpd
anyway, so it's not a problem to use that.

I thought about keeping state, but there are a lot of potential non-peers
that might try to connect, which could result in a a lot of addresses
for bgpd to keep track of :)



Re: bgpd silence "connection from non-peer" unless verbose

2022-08-25 Thread Stuart Henderson
On 2022/08/24 18:47, Denis Fondras wrote:
> Le Tue, Aug 23, 2022 at 06:28:12PM +0200, Claudio Jeker a écrit :
> > I noticed that the "connection from non-peer" message can fill the log and
> > be so chatty that it is hard to see the other messages. The system I see
> > this on is a bit special since it gets hammered by incorrectly configured
> > systems. Maybe other people find this message helpful. If so please
> > speak up now because I think the message does not add much info and should
> > be skipped unless verbose logging is used.
> > 
> 
> I agree with this change (I also have a log full of this message).

btw I like the log message, it shows me if I messed up and forgot to add a
session, or if someone else messed up and added a session without arranging
it (or typoed the address, etc). But I only allow port 179 connections from
possible candidates for peering (IXP peering lans etc) - I consider that
good practice anyway - and means it isn't too noisy.



unbound update

2022-08-24 Thread Stuart Henderson
Anyone want to test this?

Any OKs?

The CVEs mentioned are these:

=== CVE-2022-30698
Unbound prior to 1.16.2 allows malicious users to trigger continued
resolvability of malicious domain names, even after their revocation
from the parent zone, via a novel type of the "ghost domain names"
attack that targets child-centric DNS resolvers.

=== CVE-2022-30699
Unbound prior to 1.16.2 allows malicious users to trigger continued
resolvability of malicious domain names, even after their revocation
from the parent zone, via a novel type of the "ghost domain names"
attack that targets child-centric DNS resolvers.

More info at
https://www.nlnetlabs.nl/downloads/unbound/CVE-2022-30698_CVE-2022-30699.txt




Index: doc/Changelog
===
RCS file: /cvs/src/usr.sbin/unbound/doc/Changelog,v
retrieving revision 1.44
diff -u -p -r1.44 Changelog
--- doc/Changelog   7 Jun 2022 15:42:53 -   1.44
+++ doc/Changelog   24 Aug 2022 14:00:08 -
@@ -1,9 +1,115 @@
 7 February 2022: Wouter
- Fix that TCP interface does not use TLS when TLS is also configured.
 
+1 August 2022: Wouter
+   - Fix the novel ghost domain issues CVE-2022-30698 and CVE-2022-30699.
+   - Tests for ghost domain fixes.
+
+19 July 2022: George
+   - Update documentation for 'outbound-msg-retry:'.
+
+19 July 2022: Wouter
+   - Merge #718: Introduce infra-cache-max-rtt option to config max
+ retransmit timeout.
+
+15 July 2022: Wouter
+   - Merge PR 714: Avoid treat normal hosts as unresponsive servers.
+ And fixup the lock code.
+   - iana portlist update.
+
+12 July 2022: George
+   - For windows crosscompile, fix setting the IPV6_MTU socket option
+ equivalent (IPV6_USER_MTU); allows cross compiling with latest
+ cross-compiler versions.
+
+12 July 2022: Wouter
+   - Fix dname count in sldns parse type descriptor for SVCB and HTTPS.
+
+11 July 2022: Wouter
+   - Fix verbose EDE error printout.
+
+4 July 2022: George
+   - Fix bug introduced in 'improve val_sigcrypt.c::algo_needs_missing for
+ one loop pass'.
+   - Merge PR #668 from Cristian Rodríguez: Set IP_BIND_ADDRESS_NO_PORT on
+ outbound tcp sockets.
+
+4 July 2022: Wouter
+   - Tag for 1.16.1rc1 release. This became 1.16.1 on 11 July 2022.
+ The code repo continues with version 1.16.2 under development.
+
+3 July 2022: George
+   - Merge PR #671 from Petr Menšík: Disable ED25519 and ED448 in FIPS
+ mode on openssl3.
+   - Merge PR #660 from Petr Menšík: Sha1 runtime insecure.
+   - For #660: formatting, less verbose logging, add EDE information.
+   - Fix for correct openssl error when adding windows CA certificates to
+ the openssl trust store.
+   - Improve val_sigcrypt.c::algo_needs_missing for one loop pass.
+   - Reintroduce documentation and more EDE support for
+ val_sigcrypt.c::dnskeyset_verify_rrset_sig.
+
+1 July 2022: George
+   - Merge PR #706: NXNS fallback.
+   - From #706: Cached NXDOMAIN does not increase the target nx
+ responses.
+   - From #706: Don't generate parent side queries if we already
+ have the lame records in cache.
+   - From #706: When a lame address is the best choice, don't try to
+ generate target queries when the missing targets are all lame.
+
+29 June 2022: Wouter
+   - iana portlist update.
+   - Fix detection of libz on windows compile with static option.
+   - Fix compile warning for windows compile.
+
+29 June 2022: George
+   - Add debug option to the mini_tdir.sh test code.
+   - Fix #704: [FR] Statistics counter for number of outgoing UDP queries
+ sent; introduces 'num.query.udpout' to the 'unbound-control stats'
+ command.
+   - Fix to not count cached NXDOMAIN for MAX_TARGET_NX.
+   - Allow fallback to the parent side when MAX_TARGET_NX is reached.
+ This will also allow MAX_TARGET_NX more NXDOMAINs.
+
+28 June 2022: George
+   - Show the output of the exact .rpl run that failed with 'make test'.
+   - Fix for cached 0 TTL records to not trigger prefetching when
+ serve-expired-client-timeout is set.
+
+28 June 2022: Wouter
+   - Fix test program dohclient close to use portability routine.
+
+23 June 2022: Tom
+   - Clarify -v flag manpage entry (#705)
+
+22 June 2022: Philip
+   - Fix #663: use after free issue with edns options.
+
+21 June 2022: Philip
+   - Fix for loading locally stored zones that have lines with blanks or
+ blanks and comments.
+
+20 June 2022: George
+   - Remove unused LDNS function check for GOST Engine unloading.
+
+14 June 2022: George
+   - Merge PR #688: Rpz url notify issue.
+   - Note in the unbound.conf text that NOTIFY is allowed from the url:
+ addresses for auth and rpz zones.
+
+3 June 2022: George
+   - Fix for edns client subnet 

Re: [PATCH] Exclude pico-debug from the uhid driver

2022-08-22 Thread Stuart Henderson
On 2022/08/22 20:33, Josuah Demangeon wrote:
> The pico-debug [1] is a debug firmware, loaded on a Raspberry Pi RP2040
> microcontroller to provide a standard debug interface.
> The host support tool OpenOCD already upstreamed it [2].
> 
> But it does not work with OpenBSD yet, as uhid(4) takes over the
> RP2040 once plugged, blocking full libusb access [3].
> 
> This patch excludes the vendor and product ID chosen by the
> pico-debug developer from uhid and uhidev.
> 
> The USB Product ID is not from the USB Implementation Forum:
> A project reuses some of the defunct InterBiometrics product IDs
> for open-source hardware [4].
> 
> I could recompile and see the device listed as ugen(4):
> 
>   $ dmesg | grep pico-debug
>   ugen1 at uhub4 port 2 "pico-debug CMSIS-DAP" rev 1.10/10.05 addr 2
> 
> Does this patch make sense?

Yes, that's exactly how it's handled for other similar devices.
Unless there are objections or someone beats me to it (ok sthen@) I'll
commit this later.

> Thanks!
> 
> [1]: https://github.com/majbthrd/pico-debug/discussions/23
> [2]: https://repo.or.cz/openocd.git/commitdiff/b60d06?hp=64a3e7
> [3]: https://marc.info/?l=openbsd-misc=160336348703669
> [4]: https://pid.codes/faq/
> 
> diff --git sys/dev/usb/usb_quirks.c sys/dev/usb/usb_quirks.c
> index be65ad086..b0e29038a 100644
> --- sys/dev/usb/usb_quirks.c
> +++ sys/dev/usb/usb_quirks.c
> @@ -134,6 +134,7 @@ const struct usbd_quirk_entry {
>   { USB_VENDOR_OMRON, USB_PRODUCT_OMRON_BX35F,ANY,{ 
> UQ_BAD_HID }},
>   { USB_VENDOR_OMRON, USB_PRODUCT_OMRON_BX50F,ANY,{ 
> UQ_BAD_HID }},
>   { USB_VENDOR_OMRON, USB_PRODUCT_OMRON_BY35S,ANY,{ 
> UQ_BAD_HID }},
> + { USB_VENDOR_PIDCODES, USB_PRODUCT_PIDCODES_DAPPERMISER,ANY,{ 
> UQ_BAD_HID }},
>   { USB_VENDOR_TENX, USB_PRODUCT_TENX_MISSILE,ANY,{ 
> UQ_BAD_HID }},
>   { USB_VENDOR_TERRATEC, USB_PRODUCT_TERRATEC_AUREON, ANY,{ UQ_BAD_HID }},
>   { USB_VENDOR_TI, USB_PRODUCT_TI_MSP430, ANY,{ UQ_BAD_HID }},
> diff --git sys/dev/usb/usbdevs sys/dev/usb/usbdevs
> index 398e93df1..8690a0cad 100644
> --- sys/dev/usb/usbdevs
> +++ sys/dev/usb/usbdevs
> @@ -510,6 +510,7 @@ vendor SIERRA 0x1199  Sierra Wireless
>  vendor SIEMENS3  0x11f5  Siemens
>  vendor ALCATEL   0x11f7  Alcatel
>  vendor INTERBIO  0x1209  InterBiometrics
> +vendor PIDCODES  0x1209  pid.codes
>  vendor UNKNOWN3  0x1233  Unknown vendor
>  vendor TSUNAMI   0x1241  Tsunami
>  vendor PHEENET   0x124a  Pheenet
> @@ -1516,6 +1517,9 @@ product DAISY DMC   0x6901  PhotoClip
>  product DALLAS USB_FOB_IBUTTON   0x2490  USB-FOB/iBUTTON
>  product DALLAS J6502 0x4201  J-6502 speakers
>  
> +/* pid.codes products */
> +product PIDCODES DAPPERMISER 0x2488  Peter Lawrence CMSIS-DAP Dapper Miser
> +
>  /* DataApex products */
>  product DATAAPEX MULTICOM0xead6  MultiCom
>  
> diff --git sys/dev/usb/usbdevs.h sys/dev/usb/usbdevs.h
> index a6bdfbd85..23d9124b9 100644
> --- sys/dev/usb/usbdevs.h
> +++ sys/dev/usb/usbdevs.h
> @@ -1,4 +1,4 @@
> -/*   $OpenBSD: usbdevs.h,v 1.759 2022/06/23 00:32:06 jsg Exp $   */
> +/*   $OpenBSD$   */
>  
>  /*
>   * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
> @@ -517,6 +517,7 @@
>  #define  USB_VENDOR_SIEMENS3 0x11f5  /* Siemens */
>  #define  USB_VENDOR_ALCATEL  0x11f7  /* Alcatel */
>  #define  USB_VENDOR_INTERBIO 0x1209  /* InterBiometrics */
> +#define  USB_VENDOR_PIDCODES 0x1209  /* pid.codes */
>  #define  USB_VENDOR_UNKNOWN3 0x1233  /* Unknown vendor */
>  #define  USB_VENDOR_TSUNAMI  0x1241  /* Tsunami */
>  #define  USB_VENDOR_PHEENET  0x124a  /* Pheenet */
> @@ -1523,6 +1524,9 @@
>  #define  USB_PRODUCT_DALLAS_USB_FOB_IBUTTON  0x2490  /* 
> USB-FOB/iBUTTON */
>  #define  USB_PRODUCT_DALLAS_J65020x4201  /* J-6502 
> speakers */
>  
> +/* pid.codes products */
> +#define  USB_PRODUCT_PIDCODES_DAPPERMISER0x2488  /* 
> Peter Lawrence CMSIS-DAP Dapper Miser */
> +
>  /* DataApex products */
>  #define  USB_PRODUCT_DATAAPEX_MULTICOM   0xead6  /* MultiCom */
>  
> diff --git sys/dev/usb/usbdevs_data.h sys/dev/usb/usbdevs_data.h
> index 38a43697c..b5b546c67 100644
> --- sys/dev/usb/usbdevs_data.h
> +++ sys/dev/usb/usbdevs_data.h
> @@ -1,4 +1,4 @@
> -/*   $OpenBSD: usbdevs_data.h,v 1.753 2022/06/23 00:32:06 jsg Exp $  */
> +/*   $OpenBSD$   */
>  
>  /*
>   * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
> @@ -2437,6 +2437,10 @@ const struct usb_known_product usb_known_products[] = {
>   USB_VENDOR_DALLAS, USB_PRODUCT_DALLAS_J6502,
>   "J-6502 speakers",
>   },
> + {
> + USB_VENDOR_PIDCODES, USB_PRODUCT_PIDCODES_DAPPERMISER,
> + "Peter Lawrence 

Re: mention double quotes for passwords with white spaces

2022-08-22 Thread Stuart Henderson
On 2022/08/22 16:41, Theo de Raadt wrote:
> Hi,
> 
> Do you recommend we do the same in the cat manual page, regarding filenames?
> 
> Or for that matter, in hundreds of other manual pages.
> 
> Unix does whitespace-seperated tokenization, nearly everywhere, so I
> do not think this needs to be documented.

Agreed. It's handled by the shell, so normal shell rules apply.

> >  .Nm
> >  will hash the nwid along with the passphrase to create the key.
> > +If a passphrase contains one or more whitespaces, it can be surrounded
> > +by double quotes.

The same applies for nwid, pppoekey, descr, pass (carp).

The place this is needed is hostname.if(5) where it's not clear whether
normal shell rules apply, and it is already mentioned there (and used in
an example).



Re: ifconfig, wireguard output less verbose, unless -A or

2022-08-20 Thread Stuart Henderson
On 2022/07/14 09:37, Mikolaj Kucharski wrote:
> Hi,
> 
> Per other thread, Theo expressed dissatisfaction with long ifconfig(8)
> for wg(4) interface. Stuart Henderson pointed me at direction, which
> below diff makes it work.
> 
> I guess to questions are:
> 
> - Does the behaviour of ifconfig(8) make sense?
> - Does the code which makes above, make sense?

I think so, and the diff works exactly as I would expect it to.

> This is minimal diff, I would appreciate feedback, I did least
> resistance approach. Looking at diff -wu shows even less changes
> as wg_status() is mainly identation with if-statement.
> 
> 
> Short output by default, only 6 lines, no wgpeers section:
> 
> pce-0067# ifconfig.ifaliases -a | tail -n6
> wg0: flags=80c3 mtu 1420
> index 8 priority 0 llprio 3
> wgport 51820
> wgpubkey qcb...
> groups: wg
> inet6 fde4:f456:48c2:13c0::cc67 prefixlen 64
> 
> 
> Long output with  as an argument, wgpeers section present:
> 
> pce-0067# ifconfig.ifaliases wg0
> wg0: flags=80c3 mtu 1420
> index 8 priority 0 llprio 3
> wgport 51820
> wgpubkey qcb...
> wgpeer klM...
> wgpsk (present)
> wgpka 25 (sec)
> wgendpoint xxx.xxx.xxx.xxx 51820
> tx: 178764, rx: 65100
> last handshake: 7 seconds ago
> wgaip fde4:f456:48c2:13c0::/64
> groups: wg
> inet6 fde4:f456:48c2:13c0::cc67 prefixlen 64
> 
> 
> Above long output works with group as an argument (ifconfig wg) and with
> option -A (ifconfig -A), so I think from user experience perspective,
> works as expected.
> 
> Manual page changes not provided, as I'm not sure are they needed with
> this diff.

At least a small change is needed. Maybe some different text would
be more appropriate though.

Index: ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.384
diff -u -p -r1.384 ifconfig.8
--- ifconfig.8  27 Jun 2022 16:27:03 -  1.384
+++ ifconfig.8  20 Aug 2022 13:22:43 -
@@ -75,7 +75,7 @@ Only the superuser may modify the config
 The following options are available:
 .Bl -tag -width Ds
 .It Fl A
-Causes full interface alias information for each interface to
+Causes full interface alias and wgpeer information for each interface to
 be displayed.
 .It Fl a
 Causes

> Comments?
> 
> 
> Index: ifconfig.c
> ===
> RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
> retrieving revision 1.456
> diff -u -p -u -r1.456 ifconfig.c
> --- ifconfig.c8 Jul 2022 07:04:54 -   1.456
> +++ ifconfig.c14 Jul 2022 09:25:21 -
> @@ -363,7 +363,7 @@ void  unsetwgpeer(const char *, int);
>  void unsetwgpeerpsk(const char *, int);
>  void unsetwgpeerall(const char *, int);
>  
> -void wg_status();
> +void wg_status(int);
>  #else
>  void setignore(const char *, int);
>  #endif
> @@ -679,7 +679,7 @@ void  printgroupattribs(char *);
>  void printif(char *, int);
>  void printb_status(unsigned short, unsigned char *);
>  const char *get_linkstate(int, int);
> -void status(int, struct sockaddr_dl *, int);
> +void status(int, struct sockaddr_dl *, int, int);
>  __dead void  usage(void);
>  const char *get_string(const char *, const char *, u_int8_t *, int *);
>  int  len_string(const u_int8_t *, int);
> @@ -1195,7 +1195,7 @@ printif(char *name, int ifaliases)
>   continue;
>   ifdata = ifa->ifa_data;
>   status(1, (struct sockaddr_dl *)ifa->ifa_addr,
> - ifdata->ifi_link_state);
> + ifdata->ifi_link_state, ifaliases);
>   count++;
>   noinet = 1;
>   continue;
> @@ -3316,7 +3316,7 @@ get_linkstate(int mt, int link_state)
>   * specified, show it and it only; otherwise, show them all.
>   */
>  void
> -status(int link, struct sockaddr_dl *sdl, int ls)
> +status(int link, struct sockaddr_dl *sdl, int ls, int ifaliases)
>  {
>   const struct afswtch *p = afp;
>   struct ifmediareq ifmr;
> @@ -3391,7 +3391,7 @@ status(int link, struct sockaddr_dl *sdl
>   mpls_status();
>   pflow_status();
>   umb_status();
> - wg_status();
> + wg_status(ifaliases);
>  #endif
>   trunk_status();
>   getifgroups();
> @@ -5907,7 +5907,7 @@ process_wg_commands(void)
>  }
>  
>  void
> -wg_status(void)
> +wg_status(int ifaliases)
>  {
>   size_t   i

Re: bgpd fix nexthop lookup for connected networks

2022-08-19 Thread Stuart Henderson
On 2022/08/19 10:45, Claudio Jeker wrote:
> When implementing knexthop_true_nexthop() to do the lookup from BGP
> nexthop to the true nexthop used by the FIB I forgot to handle connected
> networks properly.
> 
> For connected networks and connected nexthops the BGP exit nexthop is
> equal to the true nexthop used by the FIB since the nexthop is directly
> reachable. kroutes which have F_CONNECTED set do not have a nexthop so
> the code should not try to fill the gateway. Since the input nexthop
> is already the right value the code can just return success (1).
> 
> Problem noticed by Daniel Jakots. Fix tested by me.

I found a router which has the same issue and this fixes it.

OK



> -- 
> :wq Claudio
> 
> Index: kroute.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/kroute.c,v
> retrieving revision 1.294
> diff -u -p -r1.294 kroute.c
> --- kroute.c  18 Aug 2022 17:02:42 -  1.294
> +++ kroute.c  19 Aug 2022 06:45:55 -
> @@ -2152,11 +2152,15 @@ knexthop_true_nexthop(struct ktable *kt,
>   switch (kn->nexthop.aid) {
>   case AID_INET:
>   kr = kn->kroute;
> + if (kr->flags & F_CONNECTED)
> + return 1;
>   gateway.aid = AID_INET;
>   gateway.v4.s_addr = kr->nexthop.s_addr;
>   break;
>   case AID_INET6:
>   kr6 = kn->kroute;
> + if (kr6->flags & F_CONNECTED)
> + return 1;
>   gateway.aid = AID_INET6;
>   gateway.v6 = kr6->nexthop;
>   gateway.scope_id = kr6->nexthop_scope_id;
> 



Re: libsoup2/3 conflicts and gstreamer1 [Re: audio/quodlibet & devel/libsoup]

2022-08-11 Thread Stuart Henderson
Moving from ports@.

Quick intro:

A library (gstreamer1) uses functions from another library (libsoup)
which exists in two incompatible versions (libsoup-2.4.so.XX and
libsoup-3.0.so.XX).

Other software calling gstreamer might use one or other of these two
libsoups for its own purposes, so gstreamer has been written to work
with either version of libsoup, but it needs to know which it should
use.

the text below from my ports@ mail follows on:

> gstreamer is supposed to detect a libsoup which is already loaded into the
> address space (by using dlopen() with RTLD_NOLOAD to test this) and adapts
> itself to use the appropriate libsoup API+ABI. It does this specifically
> to avoid this type of conflict. Only if it can't find a copy of libsoup2
> or libsoup3 already loaded does it use its own preference order (libsoup3
> by default) and dlopen()s it (via g_module_open) itself.
> 
> (see gst_soup_load_library() in ext/soup/gstsouploader.c from
> gstreamer1/plugins-good).
> 
> But we don't have RTLD_NOLOAD so this trick doesn't work...

... gstreamer code for this is at
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/ext/soup/gstsouploader.c#L146

Brad pointed me at a diff from guenther@ adding RTLD_NOLOAD (and
RTLD_NODELETE, written before semarie's version of RTLD_NODELETE):
https://marc.info/?l=openbsd-tech=162068525021512=2

With this applied and gstreamer1-plugins-good rebuilt, the code in
gst_soup_load_library works as expected.

I've included the rebased diff below and added a simple regress test
that I wrote, loosely based on the rtld_nodelete test plus what
gstreamer1 is doing.

Looking around some other ports (it's difficult to do a proper search
because it shows up in rust's translated version of dlfcn.h for various
OS which ends up vendored into various trees) I see some optional use
in a few ports e.g. asterisk ("Check to see if the given resource is
loaded") and vlc (I think this is trying to load a linux v4l2 library
only if not already loaded but allow it to fail gracefully).

Is this something we want?


Index: include/dlfcn.h
===
RCS file: /cvs/src/include/dlfcn.h,v
retrieving revision 1.15
diff -u -p -r1.15 dlfcn.h
--- include/dlfcn.h 2 Jun 2021 07:29:03 -   1.15
+++ include/dlfcn.h 11 Aug 2022 09:04:59 -
@@ -43,6 +43,7 @@
 #define RTLD_LOCAL 0x000
 #define RTLD_TRACE 0x200
 #define RTLD_NODELETE  0x400
+#define RTLD_NOLOAD0x800
 
 /*
  * Special handle arguments for dlsym().
Index: libexec/ld.so/dlfcn.c
===
RCS file: /cvs/src/libexec/ld.so/dlfcn.c,v
retrieving revision 1.110
diff -u -p -r1.110 dlfcn.c
--- libexec/ld.so/dlfcn.c   8 Jan 2022 17:28:49 -   1.110
+++ libexec/ld.so/dlfcn.c   11 Aug 2022 09:04:59 -
@@ -45,6 +45,15 @@ static int _dl_real_close(void *handle);
 static lock_cb *_dl_thread_fnc = NULL;
 static elf_object_t *obj_from_addr(const void *addr);
 
+#define OK_FLAGS   (0 \
+   | RTLD_TRACE\
+   | RTLD_LAZY \
+   | RTLD_NOW  \
+   | RTLD_GLOBAL   \
+   | RTLD_NODELETE \
+   | RTLD_NOLOAD   \
+   )
+
 void *
 dlopen(const char *libname, int flags)
 {
@@ -53,7 +62,7 @@ dlopen(const char *libname, int flags)
int failed = 0;
int obj_flags;
 
-   if (flags & ~(RTLD_TRACE|RTLD_LAZY|RTLD_NOW|RTLD_GLOBAL|RTLD_NODELETE)) 
{
+   if (flags & ~OK_FLAGS) {
_dl_errno = DL_INVALID_MODE;
return NULL;
}
@@ -78,7 +87,9 @@ dlopen(const char *libname, int flags)
_dl_loading_object = NULL;
 
obj_flags = (flags & RTLD_NOW ? DF_1_NOW : 0)
-   | (flags & RTLD_GLOBAL ? DF_1_GLOBAL : 0);
+   | (flags & RTLD_GLOBAL ? DF_1_GLOBAL : 0)
+   | (flags & RTLD_NOLOAD ? DF_1_NOOPEN : 0)
+   ;
object = _dl_load_shlib(libname, _dl_objects, OBJTYPE_DLO, obj_flags);
if (object == 0) {
DL_DEB(("dlopen: failed to open %s\n", libname));
Index: libexec/ld.so/library.c
===
RCS file: /cvs/src/libexec/ld.so/library.c,v
retrieving revision 1.86
diff -u -p -r1.86 library.c
--- libexec/ld.so/library.c 8 Jan 2022 06:49:41 -   1.86
+++ libexec/ld.so/library.c 11 Aug 2022 09:04:59 -
@@ -129,17 +129,15 @@ _dl_tryload_shlib(const char *libname, i
for (object = _dl_objects; object != NULL; object = object->next) {
if (object->dev == sb.st_dev &&
object->inode == sb.st_ino) {
-   object->obj_flags |= flags & DF_1_GLOBAL;
_dl_close(libfile);
-   if (_dl_loading_object == NULL)
-   _dl_loading_object = object;
-   if (object->load_object != _dl_objects &&
-   

Re: echo(1): check for stdio errors

2022-08-11 Thread Stuart Henderson
On 2022/08/10 19:37, Scott Cheloha wrote:
> On Thu, Aug 11, 2022 at 02:22:08AM +0200, Jeremie Courreges-Anglas wrote:
> > On Wed, Aug 10 2022, Scott Cheloha  wrote:
> > > [...]
> > >
> > > 1. Our ksh(1) already checks for stdout errors in the echo builtin.
> > 
> > So do any of the scripts in our source tree use /bin/echo for whatever
> > reason?  If so, could one of these scripts be broken if /bin/echo
> > started to report an error?  Shouldn't those scripts be reviewed?
> 
> I didn't look.
> 
> There are... hundreds files that look like shell scripts in src.
> 
> $ cd /usr/src
> $ find . -exec egrep -l '\#.*\!.*sh' > ~/src-shell-script-paths
> $ wc -l ~/src-shell-script-paths
> 1118 /home/ssc/src-shell-script-paths
> 
> A lot of them are in regress/.
> 
> I guess I better start looking.

The list is much smaller if you just search the tree for /bin/echo



Re: [v5] amd64: simplify TSC sync testing

2022-08-02 Thread Stuart Henderson
On 2022/08/02 22:28, Hrvoje Popovski wrote:
> 
> this is report from Dell R7515 with AMD EPYC 7702P 64-Core Processor
> 
> 
> r7515$ sysctl | grep tsc
> kern.timecounter.choice=i8254(0) mcx1(-100) mcx0(-100) tsc(-1000)
> acpihpet0(1000) acpitimer0(1000)
> machdep.tscfreq=1996246800
> machdep.invarianttsc=1

Just to be sure, are you able to check kern.timecounter.hardware
on this one please? With the fix in v5 this should now use
acpihpet or acpitimer (which are reasonable choices given the
sync issues with tsc on this hw).

(The kther machines you sent details for have enough to tell that
they're working as expected).

Thanks for the tests on these various interesting CPUs.



Re: bgpd force fib sync in fetchtable

2022-08-02 Thread Stuart Henderson
On 2022/08/02 12:34, Claudio Jeker wrote:
> On startup we load the routing table in bgpd and at that moment a cleanup
> of old bgpd routes should happen. I noticed this is not the case because
> fib_sync is not set and so send_rtmsg() just returns.
> I think we need to force fib_sync in fetchtable() to make sure the cleanup
> happens correctly.

How much of a problem is it that this clears any existing bgpd routes
if "fib update no" is set?

I guess in the common case there won't be any anyway, but is there
any use-case for running two copies of bgpd, one with fib update, one
without, on the same machine?

> OK?
> -- 
> :wq Claudio
> 
> Index: kroute.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/kroute.c,v
> retrieving revision 1.285
> diff -u -p -r1.285 kroute.c
> --- kroute.c  28 Jul 2022 14:05:13 -  1.285
> +++ kroute.c  2 Aug 2022 10:13:59 -
> @@ -2726,6 +2726,7 @@ fetchtable(struct ktable *kt)
>   char*buf = NULL, *next, *lim;
>   struct rt_msghdr*rtm;
>   struct kroute_full   kf;
> + int  fib_sync;
>  
>   mib[0] = CTL_NET;
>   mib[1] = PF_ROUTE;
> @@ -2754,6 +2755,10 @@ fetchtable(struct ktable *kt)
>   }
>   }
>  
> + /* force fib_sync on during fetch */
> + fib_sync = kt->fib_sync;
> + kt->fib_sync = 1;
> +
>   lim = buf + len;
>   for (next = buf; next < lim; next += rtm->rtm_msglen) {
>   rtm = (struct rt_msghdr *)next;
> @@ -2768,6 +2773,8 @@ fetchtable(struct ktable *kt)
>   else
>   kroute_insert(kt, );
>   }
> + kt->fib_sync = fib_sync;
> +
>   free(buf);
>   return (0);
>  }
> 



Re: interface media without netlock

2022-07-31 Thread Stuart Henderson
On 2022/07/28 13:30, Alexander Bluhm wrote:
> Problem is that smtpd(8) periodically checks media status.

Really?!



Re: Consistency and cleanup in /share/misc/airport

2022-07-30 Thread Stuart Henderson
On 2022/07/30 22:34, Thomas Wager wrote:
> On Fri, 2022-07-29 at 16:09 -0400, Daniel Dickman wrote:
> 
> > I think they’re called Metropolitan Area Airport Codes:
> > 
> > I found a list here:
> > Metropolitan Area Airport Codes
> > wikitravel.org
> > 
> > 
> > Do you want to submit a revised patch with all the corrections?
> > 
> 
> Thanks, I double checked with wikitravel.org as well. Here is a patch that
> also addresses changes to the Metropolitan Area Airport Codes. Some of them
> do not appear on wikitravel.org and not on iata.org but they are not reused
> either, so I left them as they are (NRW, QLA). For QSF I found its homepage
> here:
> http://www.egsa-constantine.dz/index.php/aeroports/aeroport-de-setif-08-mai-1945
> Its official name is "8 Mai 1945".
> Here is a revised patch:

Due to the rule for this file mentioned in the header, I think you'll
need to find a developer who has been to the added airports that have
replaced the metro areas, i.e. KCK MFW QDV QSF, either that or just
remove them.



Re: route(8), mention id(1)? [was Re: patch to ksh to show current rdomain]

2022-07-29 Thread Stuart Henderson
On 2022/07/29 14:01, Klemens Nanni wrote:
> retrieving revision 1.103
> diff -u -p -r1.103 route.8
> --- sbin/route/route.831 Mar 2022 17:27:20 -  1.103
> +++ sbin/route/route.829 Jul 2022 13:54:26 -
> @@ -78,6 +78,9 @@ Suppress all output.
>  .It Fl T Ar rtable
>  Select an alternate routing table to modify or query.
>  The default is to use the current routing table.
> +.Pp
> +The current routing table can be displayed with
> +.Xr id 1 .

That's a good place for it. Think it would be better without .Pp,
otherwise OK

>  .Dl # route -T4 exec /usr/sbin/sshd
>  .Pp
> -Display to which rdomain processes are assigned:
> +Display to which routing table processes are assigned:

That's hard to parse. Maybe just "Display the routing table used by each
process".

>  .Pp
>  .Dl $ ps aux -o rtable
>  .Pp
> +Display the routing table of the current process:
> +.Pp
> +.Dl $ id -R
> +.Pp
>  A
>  .Xr pf.conf 5
>  snippet to block incoming port 80,
> @@ -133,6 +137,7 @@ Delete rdomain 4 again:
>  # ifconfig lo4 destroy
>  .Ed
>  .Sh SEE ALSO
> +.Xr id 1 ,
>  .Xr netstat 1 ,
>  .Xr ps 1 ,
>  .Xr lo 4 ,
> 



Re: [v4] amd64: simplify TSC sync testing

2022-07-28 Thread Stuart Henderson
On 2022/07/28 12:57, Scott Cheloha wrote:
> On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote:
> > 
> > This is breaking timecounter selection on my x13 Ryzen 5 Pro laptop
> > running the latest kernel from snaps.
> 
> Define "breaking".

That's clear from the output:

: On 2022/07/28 07:55, Dave Voutila wrote:
: > $ sysctl -a | grep tsc
: > kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000)
: > acpitimer0(1000)
: > machdep.tscfreq=2096064730
: > machdep.invarianttsc=1
: > 
: > $ sysctl kern.timecounter
: > kern.timecounter.tick=1
: > kern.timecounter.timestepwarnings=0
: > kern.timecounter.hardware=i8254
: > kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000)
: > acpitimer0(1000)

> The code detects TSC desync and marks the timecounter non-monotonic.

That's good (and I think as would have happened before)

> So it uses the i8254 instead.

But that's not so good, there are higher prio timecounters available,
acpihpet0 and acpitimer0, which would be better choices than i8254.



route(8), mention id(1)? [was Re: patch to ksh to show current rdomain]

2022-07-26 Thread Stuart Henderson
from bugs@

On 2022/07/26 13:07, Theo Buehler wrote:
> On Tue, Jul 26, 2022 at 11:49:09AM +0100, Stuart Henderson wrote:
> > On 2022/07/25 23:41, mgra...@brainfat.net wrote:
> > > >Description:
> > > This change adds the \% argument to the ksh process of the prompt.  This 
> > > will
> > > cause the current rdomain of the shell to be displayed in the prompt.  
> > > This
> > > can be quite helpful when bouncing around between different rdomains.
> > 
> > I'm not convinced that stacking more non-standard features in shell
> > prompt handling to show the rtable (note, not rdomain) is the best idea.
> > And I don't think it's going to change during the lifetime of a shell is
> > it?
> > 
> > Could your profile/kshrc set up the prompt based on the current
> > rtable at the time PS1 is set instead? It's not entirely straightforward,
> > but these chicken scratches will show the table used by the current shell:
> > 
> > ps -o rtable= -p $$
> 
> id -R
> 

I tried looking for a command to do this and completely failed
hence the ugly ps command. Do we want something like this?

Index: route.8
===
RCS file: /cvs/src/sbin/route/route.8,v
retrieving revision 1.103
diff -u -p -r1.103 route.8
--- route.8 31 Mar 2022 17:27:20 -  1.103
+++ route.8 26 Jul 2022 11:41:41 -
@@ -102,6 +102,8 @@ Execute a command forcing the process an
 routing table and appropriate routing domain as specified with the
 .Fl T Ar rtable
 option.
+The current routing table can be displayed with
+.Xr id 1 .
 .It Xo
 .Nm route
 .Op Fl nqv
@@ -625,6 +627,7 @@ to create the new entry.
 .El
 .Sh SEE ALSO
 .Xr netstat 1 ,
+.Xr getrtable 2 ,
 .Xr gethostbyname 3 ,
 .Xr netintro 4 ,
 .Xr route 4 ,



Re:

2022-07-26 Thread Stuart Henderson
On 2022/07/25 20:08, Samuel Venable wrote:
> I have a suggestion on how to get the current executable path in OpenBSD that 
> might be reliable enough and not too costly that it might be accepted for a 
> future OpenBSD version.
> 
> Even if it won't be accepted, I need a little help completing the solution I 
> have in mind.
> 
> The current solution relies on $PWD, $PATH, and argv[0] to guess the 
> most-likely executable path if $PWD, $PATH, or arv[0] were not modified from 
> their original values.

That's the only way to do it on OpenBSD other than hard-coding the
"expected" location (which we do in some ports). btw that is what's
implemented by the permissibly-licensed "whereami" library that isolates
the OS-dependent code from the application calling it and supports a
wide range of OS.

https://github.com/gpakosz/whereami/commit/c47b123fe9d7d7a148d97151c51a9fc4c236ea83

>From past discussion (which I don't feel like looking up, but you'll
find some in the mailing list archives, maybe on ports@) don't expect
this to change.

> "I've come up with a means to get a proper error code if the executable path 
> returns a path to the wrong file. Basically if meams getting the vnode from 
> the current process id, get the stat struct from the vnode, the compare a few 
> stat structure members with the stat structure returned by opening the path 
> the function guessed points to the current executable. It involves working 
> with a lot of kernel functions which do have documentation but for one reason 
> or another I can't get any of it to compile because linking errors, and the 
> docs don't say anything about what libraries I should be linking to. It will 
> take a while, but this is a lot better."

I think you're overthinking this. The equivalent functionality on other
OS is not reliable either so a best-effort approach should be good enough
for any use to which a program might put this information. (In most cases
that I've seen it's done to find a path to other resources used by the
program without relying on a compiled-in value).

If you really want this type of checking, see how fstat(1) works and
check the inode num. But until a bug is fixed you'll crash the kernel
from time to time.



Re: include cpuid 0 string in dmesg for fw_update

2022-07-24 Thread Stuart Henderson
On 2022/07/24 10:34, Andrew Hewus Fresh wrote:
> On Sun, Jul 24, 2022 at 09:14:30AM -0700, Andrew Hewus Fresh wrote:
> > On Sun, Jul 24, 2022 at 10:01:26AM -0600, Theo de Raadt wrote:
> > > Jonathan Gray  wrote:
> > > 
> > > > On Sun, Jul 24, 2022 at 08:05:26AM -0600, Theo de Raadt wrote:
> > > > > Why not match on cpu0: .*Intel
> > > > 
> > > > I sent a diff a month ago with ^cpu0:*Intel(R)
> > > > 
> > > > semarie mentioned false positives as it could match another
> > > > Intel device on another line on a non-Intel CPU
> > > > 
> > > > https://marc.info/?l=openbsd-tech=165579653107768=2

Why bother about false positives? It doesn't really hurt, it's only 6MB.



Re: Latest sysupgrade (23/07/2022) fails SHA256 check

2022-07-24 Thread Stuart Henderson
On 2022/07/23 21:00, Chris Narkiewicz wrote:
> Hi,
> 
> I tried to sysupgade but it fails to check SHA256. Tried multiple times to 
> exclude random bit flip:
> 
> Verifying sets.
> (SHA256) bsd.mp: FAILED
> 
> Sysupgrade on 23/07/2022.
> 
> Best regards,
> Chris Narkiewicz
> 

If it persists, please let us know which mirror you are using.



Re: ifconfig description for wireguard peers

2022-07-14 Thread Stuart Henderson
On 2022/07/14 10:57, Claudio Jeker wrote:
> On Thu, Jul 14, 2022 at 10:51:42AM +0200, Stefan Sperling wrote:
> > On Wed, Jul 13, 2022 at 05:13:49PM +, Mikolaj Kucharski wrote:
> > > On Wed, Jul 13, 2022 at 05:43:59PM +0100, Stuart Henderson wrote:
> > > > > 
> > > > > Not sure how to handle long output in different way. If you don't
> > > > > specify wgdesc to the ifconfig, the diff doesn't change anything and
> > > > > ifconfig(8) output is exactly the same. If you don't find this feature
> > > > > useful, by not using it, nothing changes for you. Isn't that fair?
> > > > 
> > > > It might be better if wgpeer details would be skipped from plain
> > > > "ifconfig" and only listed if "ifconfig wg0" is used, much like
> > > > IPv4 aliases are skipped from "ifconfig" and only listed when
> > > > you use either "ifconfig -A" or "ifconfig em0" etc.
> > > > 
> > > 
> > > Ah, that helps. Thank you! Will look into it. Indeed this makes more
> > > sense. I was aware of -A, but was not aware of ifconfig  behaviour.
> > 
> > Perhaps also consider moving counters to netstat -s instead of ifconfig.
> 
> I don't think netstat -s is a good place for per peer stats (neither is
> ifconfig though). netstat -s shows global per protocol counters.

Agreed. These need to either be in ifconfig or some separate thing for
wg, and I much prefer ifconfig. (Everything which is listed there now
is IMHO required information, per-peer byte counters are useful to help
spot 1-way comms issues).



Re: ifconfig description for wireguard peers

2022-07-13 Thread Stuart Henderson
On 2022/07/13 16:18, Mikolaj Kucharski wrote:
> On Wed, Jul 13, 2022 at 10:02:30AM -0600, Theo de Raadt wrote:
> > Mikolaj Kucharski  wrote:
> > 
> > > I took the libery and refreshed the patch. What I did so far:
> > > 
> > > - compiled GENERIC.MP on amd64
> > > - compiled new ifconfig, same arch
> > > - booted up new bsd.mp with the patch
> > > - when wgdesc is not set, pre-patch ifconfig seems to work
> > > - when with new ifconfig I set wgdesc, old ifconfig wg segfaults
> > > 
> > > Example from running -current:
> > > 
> > > pce-0067# ifconfig.new wg0 
> > > wg0: flags=80c3 mtu 1420
> > > index 8 priority 0 llprio 3
> > > wgport 51820
> > > wgpubkey qcb...
> > > wgpeer klM...
> > > description: ks2
> > > wgpsk (present)
> > > wgpka 25 (sec)
> > > wgendpoint xxx.xxx.xxx.xxx 51820
> > > tx: 1932, rx: 620
> > > last handshake: 83 seconds ago
> > > wgaip fde4:f456:48c2:13c0::/64
> > > groups: wg
> > > inet6 fde4:f456:48c2:13c0::cc67 prefixlen 64
> > 
> > That seems disgustingly verbose to me.
> > 
> > Who is going to read it?
> 
> Me. I find this one additional line useful.
> 
> > Shall we put all the active counters for normal ethernet/wifi into the
> > default ifconfig output, so that the default ifconfig output scrolls and
> > scrolls and scrolls and noone actually reads it?
> > 
> > I think this has gone off the rails.
> 
> This is the nature of wg(4) interface. I have machine with 25 peers and
> each peer adds lines to the ifconfig(8) output. This is on a machine
> without patch from this thread, -stable, official kernel:
> 
> # ifconfig wg0 | wc -l
>  128
> 
> Not sure how to handle long output in different way. If you don't
> specify wgdesc to the ifconfig, the diff doesn't change anything and
> ifconfig(8) output is exactly the same. If you don't find this feature
> useful, by not using it, nothing changes for you. Isn't that fair?

It might be better if wgpeer details would be skipped from plain
"ifconfig" and only listed if "ifconfig wg0" is used, much like
IPv4 aliases are skipped from "ifconfig" and only listed when
you use either "ifconfig -A" or "ifconfig em0" etc.



Re: bgpd document add-path send

2022-07-11 Thread Stuart Henderson
On 2022/07/11 19:12, Claudio Jeker wrote:
> This is my try at documenting the just added add-path bits.
> 
> -- 
> :wq Claudio
> 
> Index: bgpd.8
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.8,v
> retrieving revision 1.74
> diff -u -p -r1.74 bgpd.8
> --- bgpd.828 Jun 2022 11:52:24 -  1.74
> +++ bgpd.811 Jul 2022 13:22:05 -
> @@ -401,6 +401,16 @@ has been started.
>  .Re
>  .Pp
>  .Rs
> +.%A D. Walton
> +.%A A. Retana
> +.%A E. Chen
> +.%A J. Scudder
> +.%D July 2016
> +.%R RFC 7911
> +.%T Advertisement of Multiple Paths in BGP
> +.Re
> +.Pp
> +.Rs
>  .%A C. Petrie
>  .%A T. King
>  .%D May 2017
> Index: bgpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
> retrieving revision 1.223
> diff -u -p -r1.223 bgpd.conf.5
> --- bgpd.conf.5   28 Jun 2022 11:52:24 -  1.223
> +++ bgpd.conf.5   11 Jul 2022 14:08:24 -
> @@ -843,6 +843,57 @@ The default is
>  .Ic no .
>  .Pp
>  .It Xo
> +.Ic announce add-path send
> +.Pq Ic no Ns | Ns Ic all
> +.Xc
> +.It Xo
> +.Ic announce add-path send
> +.Pq Ic best Ns | Ns Ic ecmp | Ns Ic as-wide-best
> +.Op Ic plus Ar num
> +.Op Ic max Ar num
> +.Xc
> +If set to
> +.Ic all ,
> +.Ic best ,
> +.Ic ecmp ,
> +or
> +.Ic as-wide-best ,
> +the send add-path capability is announced which allows to send multiple paths
> +per prefix.
> +Which paths are sent depends on the mode:
> +.Pp
> +.Bl -tag -width as-wide-best -compact
> +.It Ic all
> +send all valid prefixes

Never used add-path so I might misunderstand things, but shouldn't this
be "send all valid paths" (and same in other descriptions)?

> +.It Ic best
> +send the best prefix and maybe more

perhaps s/more/others/

this makes me wonder exactly what "best" and "more" are

> +.It Ic ecmp
> +send prefixes with equal nexthop cost
> +.It Ic as-wide-best
> +send prefixes where the fist 8 check of the decision process match

...where the first 8 checks of the decision process...

> +.El
> +.Pp
> +.Ic plus
> +allows to include additional routes and works for
> +.Ic best ,
> +.Ic ecmp ,
> +and
> +.Ic as-wide-best .
> +.Ic max
> +can be used to limit the total amount of routes announced for
> +.Ic ecmp
> +and
> +.Ic as-wide-best .
> +The default is
> +.Ic no .
> +.Pp
> +Right now
> +.Ic ecmp
> +and
> +.Ic as-wide-best
> +are equivalent.
> +.Pp
> +.It Xo
>  .Ic announce as-4byte
>  .Pq Ic yes Ns | Ns Ic no
>  .Xc
> 



ftp(1) connection timeouts and hostnames with multiple addresses

2022-07-09 Thread Stuart Henderson
I'm trying to teach ftp(1) to do something like gui web browsers do
and reduce the HTTP/HTTPS connection timeout from the default (75 seconds)
if there are multiple addresses behind a hostname.

There's an existing connection timeout mechanism that I thought it
might make sense to reuse...

 -w seconds
 For URL format connections to HTTP/HTTPS servers, abort a slow
 connection after seconds.

So, I tried

Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.208
diff -u -p -r1.208 fetch.c
--- fetch.c 10 Nov 2021 07:32:55 -  1.208
+++ fetch.c 9 Jul 2022 11:39:29 -
@@ -570,6 +570,9 @@ noslash:
if (verbose)
setvbuf(ttyout, NULL, _IOLBF, 0);
 
+   if (res0->ai_next && connect_timeout == 0)
+   connect_timeout = 10;
+
fd = -1;
for (res = res0; res; res = res->ai_next) {
if (getnameinfo(res->ai_addr, res->ai_addrlen, hbuf,

...but, what actually happens is, instead of aborting a slow connection
to a server (which is possibly one of many servers behind a hostname),
the SIGALRM handler aborts ftp(1) completely.

$ route -T 3 exec obj/ftp -o- http://firmware.openbsd.org/ 2>&1 | ts -s %.s
0.022289 Trying 145.238.169.11...
10.027972 ftp: connect taking too long

I also tried setsockopt SO_RCVTIMEO/SO_SNDTIMEO but these don't seem to do
anything for connect.

Does anyone have an idea if there's another way this might be done?
Is the inside of ftp(1) just too hairy for this?

The original problem I'm trying to mitigate is super-slow installs on
machines which have access to the install server but not most of the
internet;

| What timezone are you in? ('?' for list) [Canada/Mountain] Europe/London
| Saving configuration files... done.
| Making all device nodes... done.
| 
< 7.5 minutes delay here; or would be 12.5 minutes if the machine had a v6 
address >
| Cannot fetch http://firmware.openbsd.org/firmware/7.1/SHA256.sig (timed out)
| fw_update: added none; updated none; kept none
| Multiprocessor machine; using bsd.mp instead of bsd.
| Relinking to create unique kernel... done.

...in this particular situation I can workaround anyway ("block return"
instead of "block"), but there's still a naturally-occurring problem if
the first-returned host or hosts are temporarily unreachable; it takes
a lot longer than is reasonable to move on.



Re: [v3] amd64: simplify TSC sync testing

2022-07-05 Thread Stuart Henderson
On 2022/07/05 11:22, Scott Cheloha wrote:
> On Tue, Jul 05, 2022 at 05:47:51PM +0200, Stuart Henderson wrote:
> > On 2022/07/04 21:06, Scott Cheloha wrote:
> > > 4. OpenBSD VMs on other hypervisors.
> > 
> > KVM on proxmox VE 7.1-12
> > 
> > I force acpihpet0 on this; it defaults to pvclock which results in
> > timekeeping so bad that ntpd can't correct
> 
> That is an interesting problem.  Probably worth looking at pvclock(4)
> separately.
> 
> > $ sysctl kern.timecounter
> > kern.timecounter.tick=1
> > kern.timecounter.timestepwarnings=0
> > kern.timecounter.hardware=acpihpet0
> > kern.timecounter.choice=i8254(0) pvclock0(1500) acpihpet0(1000) 
> > acpitimer0(1000)
> > 
> > OpenBSD 7.1-current (GENERIC.MP) #45: Tue Jul  5 16:11:00 BST 2022
> > st...@bamboo.spacehopper.org:/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 8573001728 (8175MB)
> > avail mem = 8295833600 (7911MB)
> > random: good seed from bootblocks
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf58c0 (10 entries)
> > bios0: vendor SeaBIOS version 
> > "rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org" date 04/01/2014
> > bios0: QEMU Standard PC (i440FX + PIIX, 1996)
> > acpi0 at bios0: ACPI 1.0
> > acpi0: sleep states S3 S4 S5
> > acpi0: tables DSDT FACP APIC SSDT HPET WAET
> > acpi0: wakeup devices
> > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: AMD Ryzen 5 PRO 5650G with Radeon Graphics, 3893.04 MHz, 19-50-00
> > cpu0: 
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBRS,IBPB,STIBP,SSBD,IBPB,IBRS,STIBP,SSBD,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> 
> This machine doesn't have the ITSC flag, so we would never consider
> using the TSC as a timecounter.  The sync test is not run, but that
> makes sense.
> 
> ... is that expected?  Should the machine have the ITSC flag?
> 
> (I'm not familiar with Proxmox.)
> 

No idea to be honest. The cpu type is set to "host" so it should pass
things through, but perhaps it deliberately filters out ITSC. Mostly
wanted to point it out as a "doesn't make things worse" (and because
you specifically wanted tests on other VMs :)



Re: [v3] amd64: simplify TSC sync testing

2022-07-05 Thread Stuart Henderson
On 2022/07/04 21:06, Scott Cheloha wrote:
> 4. OpenBSD VMs on other hypervisors.

KVM on proxmox VE 7.1-12

I force acpihpet0 on this; it defaults to pvclock which results in
timekeeping so bad that ntpd can't correct

$ sysctl kern.timecounter
kern.timecounter.tick=1
kern.timecounter.timestepwarnings=0
kern.timecounter.hardware=acpihpet0
kern.timecounter.choice=i8254(0) pvclock0(1500) acpihpet0(1000) acpitimer0(1000)

OpenBSD 7.1-current (GENERIC.MP) #45: Tue Jul  5 16:11:00 BST 2022
st...@bamboo.spacehopper.org:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8573001728 (8175MB)
avail mem = 8295833600 (7911MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf58c0 (10 entries)
bios0: vendor SeaBIOS version "rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org" 
date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP APIC SSDT HPET WAET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 5 PRO 5650G with Radeon Graphics, 3893.04 MHz, 19-50-00
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBRS,IBPB,STIBP,SSBD,IBPB,IBRS,STIBP,SSBD,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache
cpu0: 512KB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 999MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Ryzen 5 PRO 5650G with Radeon Graphics, 3892.63 MHz, 19-50-00
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBRS,IBPB,STIBP,SSBD,IBPB,IBRS,STIBP,SSBD,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache
cpu1: 512KB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Ryzen 5 PRO 5650G with Radeon Graphics, 3892.64 MHz, 19-50-00
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBRS,IBPB,STIBP,SSBD,IBPB,IBRS,STIBP,SSBD,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache
cpu2: 512KB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD Ryzen 5 PRO 5650G with Radeon Graphics, 3892.65 MHz, 19-50-00
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBRS,IBPB,STIBP,SSBD,IBPB,IBRS,STIBP,SSBD,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu3: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache
cpu3: 512KB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 4 (application processor)
cpu4: AMD Ryzen 5 PRO 5650G with Radeon Graphics, 3892.65 MHz, 19-50-00
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBRS,IBPB,STIBP,SSBD,IBPB,IBRS,STIBP,SSBD,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu4: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache
cpu4: 512KB 64b/line 16-way L2 cache
cpu4: smt 0, core 4, package 0
cpu5 at mainbus0: apid 5 (application processor)
cpu5: AMD Ryzen 5 PRO 5650G with Radeon Graphics, 3892.68 MHz, 19-50-00
cpu5: 

Re: [v3] amd64: simplify TSC sync testing

2022-07-05 Thread Stuart Henderson
On 2022/07/04 21:06, Scott Cheloha wrote:
> 2. Other multisocket machines.

This is from the R620 where I originally discovered the problems
with SMP with the previous TSC test:

$ dmesg|grep tsc
$ sysctl kern.timecounter
kern.timecounter.tick=1
kern.timecounter.timestepwarnings=0
kern.timecounter.hardware=tsc
kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) acpitimer0(1000)

--- old Tue Jul  5 15:34:06 2022
+++ new Tue Jul  5 15:34:08 2022
@@ -1,7 +1,7 @@
-OpenBSD 7.1-current (GENERIC.MP) #582: Mon Jun 13 15:37:01 MDT 2022
-dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
+OpenBSD 7.1-current (GENERIC.MP) #45: Tue Jul  5 16:11:00 BST 2022
+st...@bamboo.spacehopper.org:/sys/arch/amd64/compile/GENERIC.MP
 real mem = 34295709696 (32706MB)
-avail mem = 33238974464 (31699MB)
+avail mem = 33238970368 (31699MB)
 random: good seed from bootblocks
 mpath0 at root
 scsibus0 at mpath0: 256 targets
@@ -16,132 +16,127 @@ acpi0: wakeup devices PCI0(S5) PCI1(S5)
 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-2630 v2 @ 2.60GHz, 2900.38 MHz, 06-3e-04
+cpu0: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz, 2900.42 MHz, 06-3e-04
 cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
-cpu0: 256KB 64b/line 8-way L2 cache
+cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
8-way L2 cache, 15MB 64b/line 20-way L3 cache
 cpu0: smt 0, core 0, package 0
 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
-cpu0: apic clock running at 99MHz
+cpu0: apic clock running at 100MHz
 cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
 cpu1 at mainbus0: apid 32 (application processor)
 cpu1: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz, 1200.01 MHz, 06-3e-04
 cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
-cpu1: 256KB 64b/line 8-way L2 cache
+cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
8-way L2 cache, 15MB 64b/line 20-way L3 cache
 cpu1: smt 0, core 0, package 1
 cpu2 at mainbus0: apid 2 (application processor)
-cpu2: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz, 2900.01 MHz, 06-3e-04
+cpu2: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz, 2900.02 MHz, 06-3e-04
 cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
-cpu2: 256KB 64b/line 8-way L2 cache
+cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
8-way L2 cache, 15MB 64b/line 20-way L3 cache
 cpu2: smt 0, core 1, package 0
 cpu3 at mainbus0: apid 34 (application processor)
-cpu3: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz, 1200.00 MHz, 06-3e-04
+cpu3: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz, 1200.01 MHz, 06-3e-04
 cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
-cpu3: 256KB 64b/line 8-way L2 cache
+cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
8-way L2 cache, 15MB 64b/line 20-way L3 cache
 cpu3: smt 0, core 1, package 1
 cpu4 at mainbus0: apid 4 (application processor)
-cpu4: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz, 2900.01 MHz, 06-3e-04
+cpu4: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz, 2900.02 MHz, 06-3e-04
 cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
-cpu4: 256KB 64b/line 8-way L2 cache
+cpu4: 32KB 64b/line 8-way D-cache, 32KB 

Re: amd64 serial console changes

2022-06-30 Thread Stuart Henderson
On 2022/06/30 16:55, Hrvoje Popovski wrote:
> On 30.6.2022. 16:48, Hrvoje Popovski wrote:
> > On 30.6.2022. 15:14, Anton Lindqvist wrote:
> >> On Thu, Jun 30, 2022 at 01:07:46PM +0200, Mark Kettenis wrote:
> >>> Ah right.  Please commit!
> >> Here's the complete diff, ok?
> > 
> > 
> > Hi,
> > 
> > with this diff :
> > 
> > dell r620 - serial console
> > com1 at acpi0 COMA addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo
> > com1: console
> > com0 at acpi0 COMB addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
> > 
> > works fast as before with first boot but second boot is slow...
> > 
> > supermicro - ipmi console
> > com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
> > com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo
> > com1: console
> > 
> > is slow as without this diff ..
> > 
> > 
> > i will try on few more machines this diff ...
> > 
> 
> after applying diff i did
> cd /sys/arch/amd64/compile/GENERIC.MP && make -j6 obj && make config &&
> make clean && time make -j6 && make install && reboot
> 
> 
> is this ok?
> 

This is in the bootloader not the kernel - "make obj/make/make install"
in sys/arch/amd64/stand and "installboot"



Re: em(4) multiqueue

2022-06-29 Thread Stuart Henderson
On 2022/06/29 13:19, Stuart Henderson wrote:
> On 2022/06/28 23:11, Jonathan Matthew wrote:
> > This adds the (not quite) final bits to em(4) to enable multiple rx/tx 
> > queues.
> > Note that desktop/laptop models (I218, I219 etc.) do not support multiple 
> > queues,
> > so this only really applies to servers and network appliances (including 
> > APU2).
> > 
> > It also removes the 'em_enable_msix' variable, in favour of using MSI-X on 
> > devices
> > that support multiple queues and MSI or INTX everywhere else.
> > 
> > I've tested this with an I350 on amd64 and arm64, where it works as 
> > expected, and
> > with the I218-LM in my laptop where it does nothing (as expected).
> > More testing is welcome, especially in forwarding environments.
> 
> Doesn't break things but doesn't do anything on i386 (I guess there's no 
> MSI-X?)

On amd64 on a similar machine, it works

I guess it maybe related to this in ppb.c


#ifdef __i386__
if (pci_intr_map(pa, ) == 0)
sc->sc_intrhand = pci_intr_establish(pc, ih, IPL_BIO,
ppb_intr, sc, self->dv_xname);
#else
if (pci_intr_map_msi(pa, ) == 0 ||
pci_intr_map(pa, ) == 0)
sc->sc_intrhand = pci_intr_establish(pc, ih, IPL_BIO,
ppb_intr, sc, self->dv_xname);
#endif



install.sub: don't ask about vlan0 unless some other interface exists

2022-06-28 Thread Stuart Henderson
The current handling of network interfaces in the installer is rather
confusing when somebody has an unsupported network device - it offers
to configure vlan0, but there is no interface on which a vlan can run
anyway.

Available network interfaces are: vlan0.
Which network interface do you wish to configure? (or 'done') [vlan0] 

This changes to only ask the question if some other network interfaces
is found.

amd64 installer iso with this at https://junkpile.org/cd71-netconf-novlan0.iso

comments? ok?

Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1201
diff -u -p -r1.1201 install.sub
--- install.sub 27 Jun 2022 13:48:38 -  1.1201
+++ install.sub 28 Jun 2022 11:37:06 -
@@ -1296,7 +1296,7 @@ ieee80211_config() {
 
 # Set up IPv4 and IPv6 interface configuration.
 configure_ifs() {
-   local _first _hn _if _name _p _vi
+   local _first _hn _if _name _p _vi _vn
 
# Always need lo0 configured.
ifconfig lo0 inet 127.0.0.1/8
@@ -1309,9 +1309,10 @@ configure_ifs() {
# minor for the next offered vlan interface.
_vi=$(get_ifs vlan | sed '$!d;s/^vlan//')
[[ -n $_vi ]] && ((_vi++))
+   [[ -n $(get_ifs) ]] && _vn="vlan${_vi:-0}"
 
ask_which "network interface" "do you wish to configure" \
-   "\$(get_ifs) vlan${_vi:-0}" \
+   "\$(get_ifs) $_vn" \
${_p:-'$( (get_ifs netboot; get_ifs) | sed q )'}
[[ $resp == done ]] && break
 



Re: acpitz(4): perform passive cooling only when perfpolicy is AUTO

2022-06-28 Thread Stuart Henderson
On 2022/06/27 17:12, Bryan Steele wrote:
> 
> Shouldn't this also take into consideration hw.power as well? If it
> doesn't make sense for perfpolicy=high then it probably doesn't for
> perfpolicy=auto when on AC power?

Why so? perfpolicy=high says to me, "I want it fast, I don't care about
fan noise etc", but perfpolicy=auto (whether on ac or not) suggests there
are considerations other than speed.



Re: allow HW_USERMEM64 in sysctl pledge

2022-06-21 Thread Stuart Henderson
On 2022/06/21 16:39, Jonathan Gray wrote:
> chromium loads vulkan when going to chrome://gpu
> on Intel Mesa uses HW_USERMEM64
> 
> chrome(44801): pledge sysctl 2: 6 20
> chrome[44801]: pledge "", syscall 202

ok with me, it's read-only and low-risk for the new functionality it
allows to other programmes using pledge sysctl already, and there seems
no reason not to have it when HW_PHYSMEM64 is available.

> Index: sys/kern/kern_pledge.c
> ===
> RCS file: /cvs/src/sys/kern/kern_pledge.c,v
> retrieving revision 1.281
> diff -u -p -r1.281 kern_pledge.c
> --- sys/kern/kern_pledge.c25 Mar 2022 17:40:59 -  1.281
> +++ sys/kern/kern_pledge.c21 Jun 2022 06:23:09 -
> @@ -977,6 +977,7 @@ pledge_sysctl(struct proc *p, int miblen
>   case HW_PHYSMEM64:  /* hw.physmem */
>   case HW_NCPU:   /* hw.ncpu */
>   case HW_NCPUONLINE: /* hw.ncpuonline */
> + case HW_USERMEM64:  /* hw.usermem */
>   return (0);
>   }
>   break;
> 



Re: netstart(8): don't lie

2022-06-21 Thread Stuart Henderson
On 2022/06/21 07:15, Jason McIntyre wrote:
> On Tue, Jun 21, 2022 at 07:07:25AM +0100, Stuart Henderson wrote:
> > any comments? does it need a "does not clear things" caveat? ok?
> > 
> 
> maybe instead of thinking about it as a caveat, we should just say what
> happens if you run the script on an interface that is already running?

that's sort-of already in my diff with "apply the configuration from
hostname.if", it could go into more details but then it gets messier.
basically it's "doesn't clear any existing configuration except for an
existing IPv4 address unless all the v4 addresses in the file have the
'alias' flag".


> > Index: netstart.8
> > ===
> > RCS file: /cvs/src/share/man/man8/netstart.8,v
> > retrieving revision 1.25
> > diff -u -p -r1.25 netstart.8
> > --- netstart.8  29 Nov 2020 20:14:06 -  1.25
> > +++ netstart.8  21 Jun 2022 06:05:51 -
> > @@ -43,8 +43,7 @@ it performs network initialization.
> >  .Pp
> >  The
> >  .Nm
> > -script can also be used to start newly created bridges or interfaces,
> > -or reset existing interfaces to their default state.
> > +script can also be used to start newly created bridges or interfaces.
> >  The behaviour of this script is (or can be) controlled to some
> >  extent by variables defined in
> >  .Xr rc.conf 8 ,
> > @@ -91,8 +90,9 @@ and
> >  After the system is completely initialized, it is possible to start a
> >  newly created interface or
> >  .Xr bridge 4 ,
> > -or reset an existing interface to its default state, by invoking
> > -the following, where
> > +or apply the configuration from a
> > +.Xr hostname.if 5
> > +file to an existing interface, by invoking the following, where
> >  .Ar foo0
> >  is the interface or bridge name:
> >  .Pp
> > 
> 



netstart(8): don't lie

2022-06-21 Thread Stuart Henderson
any comments? does it need a "does not clear things" caveat? ok?

Index: netstart.8
===
RCS file: /cvs/src/share/man/man8/netstart.8,v
retrieving revision 1.25
diff -u -p -r1.25 netstart.8
--- netstart.8  29 Nov 2020 20:14:06 -  1.25
+++ netstart.8  21 Jun 2022 06:05:51 -
@@ -43,8 +43,7 @@ it performs network initialization.
 .Pp
 The
 .Nm
-script can also be used to start newly created bridges or interfaces,
-or reset existing interfaces to their default state.
+script can also be used to start newly created bridges or interfaces.
 The behaviour of this script is (or can be) controlled to some
 extent by variables defined in
 .Xr rc.conf 8 ,
@@ -91,8 +90,9 @@ and
 After the system is completely initialized, it is possible to start a
 newly created interface or
 .Xr bridge 4 ,
-or reset an existing interface to its default state, by invoking
-the following, where
+or apply the configuration from a
+.Xr hostname.if 5
+file to an existing interface, by invoking the following, where
 .Ar foo0
 is the interface or bridge name:
 .Pp



Re: [v2] amd64: simplify TSC sync testing

2022-06-15 Thread Stuart Henderson
Hi Scott, just installing on another 2-socket machine, could you
point me at the latest version of the TSC sync testing diff please?



Re: kernel build error

2022-06-12 Thread Stuart Henderson
On 2022/06/10 18:01, ten wrote:
> Hello.
> 
> kernel build was initiated from singleuser mode.
> 
> after crash there was message to provide those files. - in archive.
> 
> thank you.

(zip file contains clang crash reproducer sh + c files, which don't fail for me)

You don't show the error message, but I suspect it was due to running out
of memory. As you were in single-user mode, you probably hadn't enabled swap
which might have helped.



Re: LDIF case sensitivity, login_ldap

2022-06-09 Thread Stuart Henderson
[moved from misc to tech]

On 2022/06/09 13:26, Martijn van Duren wrote:
> On Thu, 2022-06-09 at 07:48 +0000, Stuart Henderson wrote:
> > On 2022-06-09, David Diggles  wrote:
> > > I've just got ldap login working on OpenBSD/7.1 with accounts stored 
> > > locally in ldapd and using ypldap.
> > > 
> > > I just thought I'd share something so anyone reading this may save 
> > > wasting the time that I wasted :-)
> > > 
> > > Your LDIF entry that you read into ldap must be as follows for 
> > > userPassword
> > > 
> > > userPassword: {CRYPT}${ENCRYPTED_PASSWD}
> > > 
> > > ie uppercase CRYPT - I was stuffing around for ages with trying to 
> > > understand why login_ldap was failing to bind because I had {crypt} in 
> > > lowercase.
> > 
> > Perhaps it would make sense for ldapd to support {crypt} as well..
> 
> No personal preference, but seems easy enough at first glance.
> Only compile-tested though...
> 
> martijn@

I'm not using ldapd myself (I want replication so I'm using OpenLDAP)
but I think this is the way to go. OpenLDAP works with upper- or lower-case.
RFC2307 uses lower-case for the scheme names.

FWIW OK sthen@

The only downside I can see is that if a user's password is *not*
encrypted and starts with {crypt}, {ssha}, etc there will be a conflict.
But it already exists for the upper-case version and it seems unlikely
to be a problem in real world use.

> Index: auth.c
> ===
> RCS file: /cvs/src/usr.sbin/ldapd/auth.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 auth.c
> --- auth.c24 Oct 2019 12:39:26 -  1.14
> +++ auth.c9 Jun 2022 11:23:06 -
> @@ -220,7 +220,7 @@ check_password(struct request *req, cons
>   if (stored_passwd == NULL)
>   return -1;
>  
> - if (strncmp(stored_passwd, "{SHA}", 5) == 0) {
> + if (strncasecmp(stored_passwd, "{SHA}", 5) == 0) {
>   sz = b64_pton(stored_passwd + 5, tmp, sizeof(tmp));
>   if (sz != SHA_DIGEST_LENGTH)
>   return (-1);
> @@ -228,7 +228,7 @@ check_password(struct request *req, cons
>   SHA1_Update(, passwd, strlen(passwd));
>   SHA1_Final(md, );
>   return (bcmp(md, tmp, SHA_DIGEST_LENGTH) == 0 ? 1 : 0);
> - } else if (strncmp(stored_passwd, "{SSHA}", 6) == 0) {
> + } else if (strncasecmp(stored_passwd, "{SSHA}", 6) == 0) {
>   sz = b64_pton(stored_passwd + 6, tmp, sizeof(tmp));
>   if (sz <= SHA_DIGEST_LENGTH)
>   return (-1);
> @@ -238,12 +238,12 @@ check_password(struct request *req, cons
>   SHA1_Update(, salt, sz - SHA_DIGEST_LENGTH);
>   SHA1_Final(md, );
>   return (bcmp(md, tmp, SHA_DIGEST_LENGTH) == 0 ? 1 : 0);
> - } else if (strncmp(stored_passwd, "{CRYPT}", 7) == 0) {
> + } else if (strncasecmp(stored_passwd, "{CRYPT}", 7) == 0) {
>   encpw = crypt(passwd, stored_passwd + 7);
>   if (encpw == NULL)
>   return (-1);
>   return (strcmp(encpw, stored_passwd + 7) == 0 ? 1 : 0);
> - } else if (strncmp(stored_passwd, "{BSDAUTH}", 9) == 0) {
> + } else if (strncasecmp(stored_passwd, "{BSDAUTH}", 9) == 0) {
>   if (send_auth_request(req, stored_passwd + 9, passwd) == -1)
>   return (-1);
>   return 2;   /* Operation in progress. */
> 



Re: [PATCH] adds -t timeout to slowcgi

2022-06-09 Thread Stuart Henderson
On 2022/06/09 01:36, Alfred Morgan wrote:
> I think this got missed on misc@ when I posted on 5/24. I'm now

Diffs are definitely likely to get missed on misc@

> reposting here in tech@ with the [PATCH] subject tag.

This diff is mangled, tabs have been converted to spaces and it
doesn't apply with patch.



Re: bgpd: refactor kroute code a fair bit

2022-06-09 Thread Stuart Henderson
On 2022/06/08 22:47, Claudio Jeker wrote:
> and here is the updated diff I forgot to include 

Not sure if it's expected / not, but I lose interface information
with this:


$ diff -wu old new
--- old Thu Jun  9 09:44:37 2022
+++ new Thu Jun  9 09:44:44 2022
@@ -2,18 +2,19 @@
 Flags: * = nexthop valid
 
   Nexthop Route  Prio Gateway Iface   
-* ::2 ::2/128  1 ::2 lo1 (UP, unknown)
-* ::3 ::3/128 32 fe80::2e0:edff:fe75:a564%ixl3 ixl3 
(UP, 1000 Mbps)
-* ::4 ::4/128 32 fe80::2e0:edff:fe75:a564%ixl3 ixl3 
(UP, 1000 Mbps)
-* ::7 ::7/128 32 fe80::2e0:edff:fe75:a564%ixl3 ixl3 
(UP, 1000 Mbps)
-* ::13 ::13/128 32 fe80::2e0:edff:fe75:a564%ixl3 ixl3 
(UP, 1000 Mbps)
+* ::2 ::2/128  1 connected   lo1 (UP, unknown)
+* ::3 ::3/128 32 fe80::2e0:edff:fe75:a564%ixl3 
+* ::4 ::4/128 32 fe80::2e0:edff:fe75:a564%ixl3 
+* ::7 ::7/128 32 fe80::2e0:edff:fe75:a564%ixl3 
+* ::13 ::13/128 32 fe80::2e0:edff:fe75:a564%ixl3 
 * d::184 d::/64  4 connected   vlan701 (UP, active)
+* zz.113  zz.112/3132 yy.69  
   zz.117  zz.116/3019 connected   carp1003 (UP, backup)
-* yy.2yy.2/32   1 yy.2lo1 (UP, unknown)
-* yy.3yy.3/32  32 yy.69   ixl3 (UP, 1000 Mbps)
-* yy.4yy.4/32  32 yy.69   ixl3 (UP, 1000 Mbps)
-* yy.7yy.7/32  32 yy.69   ixl3 (UP, 1000 Mbps)
-* yy.13   yy.13/32 32 yy.69   ixl3 (UP, 1000 Mbps)
+* yy.2yy.2/32   1 connected   lo1 (UP, unknown)
+* yy.3yy.3/32  32 yy.69  
+* yy.4yy.4/32  32 yy.69  
+* yy.7yy.7/32  32 yy.69  
+* yy.13   yy.13/32 32 yy.69  
 * yy.179  yy.176/28 4 connected   vlan701 (UP, active)
 * yy.180  yy.176/28 4 connected   vlan701 (UP, active)
 * yy.183  yy.176/28 4 connected   vlan701 (UP, active)



Re: unlock pf_purge

2022-06-07 Thread Stuart Henderson
On 2022/06/07 16:58, David Gwynne wrote:
> the main change here is to move pf_purge out from under the kernel lock.
> 
> another part of the change is to limit the amount of work the state
> purging does to avoid hogging a cpu too much, and to also avoid holding
> NET_LOCK for too long.

I'm running this on a small firewall now, it doesn't have much traffic
going through it but is doing some wg and isakmpd. Might give it a try on
another one later.

good find.


> the main part is acheived by using systqmp to run the purge tasks
> instead of systq. from what i can tell, all the data structures we're
> walking over are protected by pf locks and/or the net lock. the pf
> state list in particular was recently reworked so iteration over
> the list can be done without interfering with insertions. this means we
> can scan the state list to collect expired states without affecting
> packet processing.
> 
> however, if you have a lot of states (like me) you can still spend a
> lot of time scanning. i seem to sit at around 1 to 1.2 million states,
> and i run with the default scan interval of 10 seconds. that means im
> scanning about 100 to 120k states every second, which just takes time.
> 
> doing the scan while holding the kernel lock means most other stuff
> cannot run at the same time. worse, the timeout that schedules the pf
> purge work also seems to schedule something in the softclock thread. if
> the same timeout also wakes up a process in an unlocked syscall, a
> significant amount of time in the system is spent spinning for no
> reason. significant meaning dozens of milliseconds, which is actually
> noticable if you're working interactively on the box.
> 
> before this change pf purges often took 10 to 50ms. the softclock
> thread runs next to it often took a similar amount of time, presumably
> because they ended up spinning waiting for each other. after this
> change the pf_purges are more like 6 to 12ms, and dont block softclock.
> most of the variability in the runs now seems to come from contention on
> the net lock.
> 
> the state purge task now checks the SHOULDYIELD flag, so if the
> task is taking too long it will return early and requeue itself,
> allowing the taskq machinery to yield and let other threads run.
> 
> state purging is now also limited to removing 64 states per task run to
> avoid holding locks that would block packet processing for too long. if
> there's still states to scan in the interval after these 64 packets are
> collected, the task reschedules so it can keep scanning from where it
> left off.
> 
> the other purge tasks for source nodes, rules, and fragments have been
> moved to their own timeout/task pair to simplify the time accounting.
> 
> the box feels a lot more responsive with this change. i'm still kicking
> it around, but i wanted to get it out early.
> 
> Index: pf.c
> ===
> RCS file: /cvs/src/sys/net/pf.c,v
> retrieving revision 1.1132
> diff -u -p -r1.1132 pf.c
> --- pf.c  23 May 2022 11:17:35 -  1.1132
> +++ pf.c  7 Jun 2022 06:49:51 -
> @@ -120,10 +120,6 @@ u_charpf_tcp_secret[16];
>  int   pf_tcp_secret_init;
>  int   pf_tcp_iss_off;
>  
> -int   pf_npurge;
> -struct task   pf_purge_task = TASK_INITIALIZER(pf_purge, _npurge);
> -struct timeoutpf_purge_to = TIMEOUT_INITIALIZER(pf_purge_timeout, 
> NULL);
> -
>  enum pf_test_status {
>   PF_TEST_FAIL = -1,
>   PF_TEST_OK,
> @@ -1276,49 +1272,111 @@ pf_purge_expired_rules(void)
>   }
>  }
>  
> -void
> -pf_purge_timeout(void *unused)
> -{
> - /* XXX move to systqmp to avoid KERNEL_LOCK */
> - task_add(systq, _purge_task);
> -}
> +void  pf_purge_states(void *);
> +struct task   pf_purge_states_task =
> +  TASK_INITIALIZER(pf_purge_states, NULL);
> +
> +void  pf_purge_states_tick(void *);
> +struct timeoutpf_purge_states_to =
> +  TIMEOUT_INITIALIZER(pf_purge_states_tick, NULL);
> +
> +unsigned int  pf_purge_expired_states(unsigned int, unsigned int);
> +
> +/*
> + * how many states to scan this interval.
> + *
> + * this is set when the timeout fires, and reduced by the task. the
> + * task will reschedule itself until the limit is reduced to zero,
> + * and then it adds the timeout again.
> + */
> +unsigned int pf_purge_states_limit;
> +
> +/*
> + * limit how many states are processed with locks held per run of
> + * the state purge task.
> + */
> +unsigned int pf_purge_states_collect = 64;
>  
>  void
> -pf_purge(void *xnloops)
> +pf_purge_states_tick(void *null)
>  {
> - int *nloops = xnloops;
> + unsigned int limit = pf_status.states;
> + unsigned int interval = pf_default_rule.timeout[PFTM_INTERVAL];
> +
> + if (limit == 0) {
> + timeout_add_sec(_purge_states_to, 1);
> + return;
> + }
>  
>   /*
>* process a fraction of the 

Re: @extraunexec usage in pkg_add

2022-06-07 Thread Stuart Henderson
On 2022/06/07 09:36, Marc Espie wrote:
> I propose eventually replacing them with 
> @extraglob pattern

Very definitely makes sense.

So we can avoid surprises if/when we do this, if some developer is using
packages from the wrong architecture as part of their workflow please
check if those packages include @extraunexec (pkg_info -f pkgname |
grep @extraunexec) as we could hold off on converting those particular
packages until later.



Re: pkg_add in -current

2022-06-04 Thread Stuart Henderson
On 2022/06/04 15:23, Theo de Raadt wrote:
> Stuart Henderson  wrote:
> 
> > If you are running -current and have not updated base recently, you
> > may run inTO "pkg_add: Unknown option: always-update ".
> > To fix it, just update to a newer base snapshot.
> 
> 
> 
> What happened is that a developer made a change to the pkg tools which
> creates completely incompatible package files.
> 
> Noone knew this was happening beforehands.  An email was circulated
> after-the-fact to ports@ list (which is mostly read by developers, and
> not read by users).  It has now been weeks, and it still hasn't been
> clearly communicated.

People can decide for themselves about that,

First commit enabling parsing in pkg_add
https://github.com/openbsd/src/commit/5cb7aebf4211294fd2891b0bc45c383ab7fd66af

"REMINDER: snapshots go with -current"
https://marc.info/?l=openbsd-ports=165355109123377=2

Second commit, after base is updated with this subsequent package builds
use the new annotation
https://github.com/openbsd/src/commit/c2e596a17ac45689d758df0d67597fef94480ebe

(Then it takes time for new packages to be built on the various archs
and it's not until *then* that errors would show up for people who
haven't updated base yet)



pkg_add in -current

2022-06-04 Thread Stuart Henderson
If you are running -current and have not updated base recently, you
may run inTO "pkg_add: Unknown option: always-update ".
To fix it, just update to a newer base snapshot.




Re: httpd: add include_dir keyword

2022-06-02 Thread Stuart Henderson
On 2022/06/02 12:53, qorg11 wrote:
> > I don't think we want this functionality.
> 
> Some users have been asking for it in the #openbsd IRC channel.

there are 20+ programs in base which use a config parser derived from
the same source as usr/sbin/httpd's, and generally they are kept in
sync as much as possible. having them diverge by allowing some but not
others to pull in a whole directory's worth of config files isn't
entirely ideal..

On 2022/06/02 12:04, Florian Obser wrote:
> this should be
> "include directory"
> or
> "include /etc/httpd.d/"
> should be made to work.  

or glob.. "include /etc/httpd.d/*"



Re: ix(4): Add support for TCP Large Receive Offloading

2022-05-31 Thread Stuart Henderson

Might need "make obj"

--
 Sent from a phone, apologies for poor formatting.

On 31 May 2022 10:22:46 Hrvoje Popovski  wrote:


On 27.5.2022. 18:25, Jan Klemkow wrote:

Hi,

The following diff enables the TCP Large Receive Offloading feature for
ix(4) interfaces.  It also includes a default off sysctl(2) switch.

The TCP single stream receiving performance increased from 3.6 Gbit/s to
9.4 Gbit/s.  Measured from Linux to OpenBSD with tcpbench.

I tested the diff with:
ix0 at pci3 dev 0 function 0 "Intel 82599" rev 0x01, msix, 12 queues, 
address 00:1b:21:87:fb:2c


If you want to test the diff:

 1. Apply the diff
 2. Rebuild the kernel
 3. Rebuild header files
# cd /usr/src && make includes


Hi,

I'm sorry but I' stuck here.

smc24# cd /usr/src && make includes
cd /usr/src/include &&  su build -c 'exec make prereq' &&  exec make
includes
preparing in /usr/src/include/../lib/libcrypto
cat /usr/src/lib/libcrypto/objects/obj_mac.num > obj_mac.num.tmp
/bin/sh: cannot create obj_mac.num.tmp: Permission denied
*** Error 1 in lib/libcrypto (Makefile:460 'obj_mac.h')
*** Error 2 in include (Makefile:81 'prereq': @for i in ../lib/libcrypto
../lib/librpcsvc; do  echo preparing in /usr/src/include/$i;  cd /u...)
*** Error 2 in /usr/src (Makefile:55 'includes')

I'm doing "make includes" as root ..




 4. Rebuild sysctl(8)
# cd /usr/src/sbin/sysctl && make && make install
 5. Reboot
 6. Enable the feature
# sysctl net.inet.tcp.large_recv_offload=1
# ifconfig ix0 down && ifconfig ix0 up

I tested this diff for a while in different scenarios (receiving,
routing, relaying) without noticing any problems yet.

bluhm@ already suggested that I could change the feature switch from a
global sysctl(2) to an per interface ifconfig(8) option.  This would
give the user more control.

Tests with other ix(4) NICs are welcome and needed!

bye,
Jan

Index: dev/pci/if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.185
diff -u -p -r1.185 if_ix.c
--- dev/pci/if_ix.c 15 Mar 2022 11:22:10 -  1.185
+++ dev/pci/if_ix.c 23 May 2022 14:39:45 -
@@ -2870,7 +2870,7 @@ ixgbe_initialize_receive_units(struct ix
 {
struct rx_ring  *rxr = sc->rx_rings;
struct ixgbe_hw *hw = >hw;
-   uint32_tbufsz, fctrl, srrctl, rxcsum;
+   uint32_tbufsz, fctrl, srrctl, rxcsum, rdrxctl;
uint32_thlreg;
int i;

@@ -2894,6 +2894,14 @@ ixgbe_initialize_receive_units(struct ix
hlreg |= IXGBE_HLREG0_JUMBOEN;
IXGBE_WRITE_REG(hw, IXGBE_HLREG0, hlreg);

+   if (tcp_lro) {
+   /* enable RSCACKC for RSC */
+   rdrxctl = IXGBE_READ_REG(hw, IXGBE_RDRXCTL);
+   rdrxctl |= IXGBE_RDRXCTL_RSCACKC;
+   rdrxctl |= IXGBE_RDRXCTL_FCOE_WRFIX;
+   IXGBE_WRITE_REG(hw, IXGBE_RDRXCTL, rdrxctl);
+   }
+
bufsz = (sc->rx_mbuf_sz - ETHER_ALIGN) >> IXGBE_SRRCTL_BSIZEPKT_SHIFT;

for (i = 0; i < sc->num_queues; i++, rxr++) {
@@ -2909,6 +2917,12 @@ ixgbe_initialize_receive_units(struct ix
/* Set up the SRRCTL register */
srrctl = bufsz | IXGBE_SRRCTL_DESCTYPE_ADV_ONEBUF;
IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(i), srrctl);
+
+   if (tcp_lro) {
+   /* Enable Receive Side Coalescing */
+   IXGBE_WRITE_REG(hw, IXGBE_RSCCTL(i),
+   IXGBE_RSCCTL_RSCEN|IXGBE_RSCCTL_MAXDESC_16);
+   }

/* Setup the HW Rx Head and Tail Descriptor Pointers */
IXGBE_WRITE_REG(hw, IXGBE_RDH(i), 0);
Index: dev/pci/ixgbe.h
===
RCS file: /cvs/src/sys/dev/pci/ixgbe.h,v
retrieving revision 1.33
diff -u -p -r1.33 ixgbe.h
--- dev/pci/ixgbe.h 8 Feb 2022 03:38:00 -   1.33
+++ dev/pci/ixgbe.h 23 May 2022 14:53:59 -
@@ -61,11 +61,16 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
+#include 

 #if NBPFILTER > 0
 #include 
Index: netinet/tcp_input.c
===
RCS file: /cvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.375
diff -u -p -r1.375 tcp_input.c
--- netinet/tcp_input.c 4 Jan 2022 06:32:39 -   1.375
+++ netinet/tcp_input.c 23 May 2022 14:41:59 -
@@ -126,6 +126,7 @@ struct timeval tcp_rst_ppslim_last;
 int tcp_ackdrop_ppslim = 100;  /* 100pps */
 int tcp_ackdrop_ppslim_count = 0;
 struct timeval tcp_ackdrop_ppslim_last;
+int tcp_lro = 0;   /* TCP Large Receive Offload */

 #define TCP_PAWS_IDLE  (24 * 24 * 60 * 60 * PR_SLOWHZ)

Index: netinet/tcp_usrreq.c
===
RCS file: /cvs/src/sys/netinet/tcp_usrreq.c,v
retrieving revision 1.183
diff -u -p -r1.183 tcp_usrreq.c
--- 

Re: apmd(8): reconnecting AC, not battery

2022-05-28 Thread Stuart Henderson
On 2022/05/28 06:52, Jason McIntyre wrote:
> On Fri, May 27, 2022 at 07:19:37PM +0200, Jan Stary wrote:
> > apmd says:
> > 
> >   When the power status changes (battery is connected or disconnected),
> >   apmd fetches the current status and reports it via syslog(3)
> >   with logging facility LOG_DAEMON.
> > 
> > Is "battery" really meant here?  Should that be the AC power?
> > Batteries are typically not being reconnected while running ...

They certainly can be, either while on external power, or in the case of
machines with multiple batteries (several generations of X series ThinkPads
have both internal and external batteries, so you can swap without powering
down even while on battery power). But yes the common case would be
external power.

> > (The manpage calls it "external power", "line current"
> > and "AC" interchangably.)
> > 
> > Jan
> > 
> 
> hi.
> 
> i think you're right that the text is off. the author possibly meant to
> say battery was charging or discharging.
> 
> anyway, if i don;t hear any reason not to soon, i'll commit your
> suggested diff (which i think is simpler and makes sense).

Why be inaccurate when we don't need to be - it's very uncommon to have
a machine with a battery with an AC input. "External power" would make
more sense.



Re: [PATCH] [src] share/man/man8/rc.{d,subr}.8 - normalise markup

2022-05-27 Thread Stuart Henderson
On 2022/05/27 11:43, Raf Czlonka wrote:
> Hello,
> 
> daemon_logger was the odd one out in rc.subr(8).

I think that is correct.

> While there, I did the same in rc.d(8).

But that isn't, it is talking about _execdir,
_flags, etc where you need to replace the 


> Regards,
> 
> Raf
> 
> Index: share/man/man8/rc.d.8
> ===
> RCS file: /cvs/src/share/man/man8/rc.d.8,v
> retrieving revision 1.38
> diff -u -p -r1.38 rc.d.8
> --- share/man/man8/rc.d.8 26 May 2022 11:27:03 -  1.38
> +++ share/man/man8/rc.d.8 27 May 2022 10:35:12 -
> @@ -102,27 +102,27 @@ variables when starting a daemon.
>  The following can be overridden by site-specific values provided in
>  .Xr rc.conf.local 8 :
>  .Bl -tag -width daemon_timeout -offset indent
> -.It Ar daemon Ns _execdir
> +.It Va daemon_execdir
>  Run daemon from the specified directory.
> -.It Ar daemon Ns _flags
> +.It Va daemon_flags
>  Additional arguments to call the daemon with.
>  These will be appended to any mandatory arguments already contained in the
>  .Va daemon
>  variable defined in the control script.
>  If
> -.Ar daemon Ns _flags
> +.Va daemon_flags
>  is set to
>  .Dq NO ,
>  it will prevent the daemon from starting even when listed in
>  .Va pkg_scripts .
> -.It Ar daemon Ns _logger
> +.It Va daemon_logger
>  Redirect standard output and error to
>  .Xr logger 1
>  using the configured priority (e.g. "daemon.info").
> -.It Ar daemon Ns _rtable
> +.It Va daemon_rtable
>  Routing table to run the daemon under, using
>  .Xr route 8 .
> -.It Ar daemon Ns _timeout
> +.It Va daemon_timeout
>  Maximum time in seconds to wait for the
>  .Cm start ,
>  .Cm stop
> @@ -135,7 +135,7 @@ This is only guaranteed with the default
>  and
>  .Ic rc_reload
>  functions.
> -.It Ar daemon Ns _user
> +.It Va daemon_user
>  User to run the daemon as, using
>  .Xr su 1 .
>  .El
> Index: share/man/man8/rc.subr.8
> ===
> RCS file: /cvs/src/share/man/man8/rc.subr.8,v
> retrieving revision 1.44
> diff -u -p -r1.44 rc.subr.8
> --- share/man/man8/rc.subr.8  26 May 2022 11:27:03 -  1.44
> +++ share/man/man8/rc.subr.8  27 May 2022 10:35:12 -
> @@ -262,7 +262,7 @@ Change to this directory before running
>  .Ic rc_exec .
>  .It Va daemon_flags
>  Arguments to call the daemon with.
> -.It Ar daemon Ns _logger
> +.It Va daemon_logger
>  Redirect standard output and error to
>  .Xr logger 1
>  using the configured priority (e.g. "daemon.info").
> 



Re: ntpd trusted servers

2022-05-26 Thread Stuart Henderson
Good catch!  OK sthen@

On 2022/05/27 02:20, Nathanael Rensen wrote:
> I found the trusted keyword is not respected when using the
> servers directive in ntpd.conf(5):
> 
> servers pool.trusted.local trusted
> 
> Nathanael
> 
> Index: ntp.c
> ===
> RCS file: /cvs/src/usr.sbin/ntpd/ntp.c,v
> retrieving revision 1.169
> diff -u -p -r1.169 ntp.c
> --- ntp.c 24 Mar 2022 07:37:19 -  1.169
> +++ ntp.c 26 May 2022 18:03:49 -
> @@ -628,6 +628,7 @@ ntp_dispatch_imsg_dns(void)
>   >ss), peer->addr_head.name);
>   npeer = new_peer();
>   npeer->weight = peer->weight;
> + npeer->trusted = peer->trusted;
>   npeer->query_addr4 = peer->query_addr4;
>   npeer->query_addr6 = peer->query_addr6;
>   h->next = NULL;
> 



Re: iked problems with Apple clients in 7.1

2022-05-22 Thread Stuart Henderson
On 2022/05/21 17:04, Tobias Heider wrote:
> 
> Oh, makes sense.  I think it may still be related to the IDs, so checking if
> ikev2_pld_id matches what you expect for srcid might be a good start.
> Maybe the apple client is sending something different than 
> ""
> in their dstid.

I'll try to find what they've got it set to in the week, though if they
followed my setup docs it will match what I've set in iked.conf.

iked.conf(5) just says "will be used by iked(8) as the identity of the
local peer" so it's a surprise that a mismatch would cause iked to
disallow the connection, seems like maybe a fallback would make sense if
there's no explicit match?

If anyone else reading sees this after updating to 7.1 and has direct
access to an iPhone, any chance could you help us debug please?

> If this doesn't help we could try adding a few printfs to see why the policy
> fails to match.



Re: iked problems with Apple clients in 7.1

2022-05-21 Thread Stuart Henderson
On 2022/05/21 13:44, Tobias Heider wrote:
> On Fri, May 20, 2022 at 03:41:12PM +0100, Stuart Henderson wrote:
> > I ran into problems with Apple clients failing to connect to
> > iked after updating a machine to 7.1, introduced by
> > https://github.com/openbsd/src/commit/e3f5cf2ee26929d75dc2df9e86d97c36b2a94268
> > 
> > spi=0xac3d46687441f957: recv IKE_SA_INIT req 0 peer rrr.rrr.rrr.rr:49436 
> > local lll.ll.lll.lll:500, 308 bytes, policy 'default'
> > spi=0xac3d46687441f957: send IKE_SA_INIT res 0 peer rrr.rrr.rrr.rr:49436 
> > local lll.ll.lll.lll:500, 341 bytes
> > spi=0xac3d46687441f957: recv IKE_AUTH req 1 peer rrr.rrr.rrr.rr:64892 local 
> > lll.ll.lll.lll:4500, 368 bytes, policy 'default'
> > policy_test: localid mismatch
> > spi=0xac3d46687441f957: ikev2_ike_auth_recv: no compatible policy found
> > spi=0xac3d46687441f957: ikev2_send_auth_failed: authentication failed for
> > spi=0xac3d46687441f957: send IKE_AUTH res 1 peer rrr.rrr.rrr.rr:64892 local 
> > lll.ll.lll.lll:4500, 80 bytes, NAT-T
> > spi=0xac3d46687441f957: sa_free: authentication failed
> > 
> > I don't have full details of config done on the other side nor any
> > fruit-based phones to test from myself, did anyone already run into this
> > and figure out a way around it?
> 
> Hey Stuart,
> 
> I haven't seen this before but I have a theory.
> Based on the commit you pointed out the problem is probably the
> `dstid kk.kkk.kkk.kkk` line which was ignored before this change.
> 
> This should be easy to check without access to the other device if
> you enable verbose logging on your server and look for "ikev2_pld_id"
> above the error. I suspect that the ID sent by your apple peer might
> actually be a different one than kk.kkk.kkk.kkk.
> 
> Another thing you could try is just removing the dstid part and see
> if that works.

Oh sorry I wasn't clear about which one the apple was using - the one with
"kk.kkk.kkk.kkk" is a lan-to-lan configuration (fixed IP on both endpoints) -
the apple is expected to be using the first "from 0.0.0.0/0 to dynamic" one
which doesn't have any dstid set, and that's the only one where the IP matches.


> > 
> > I'm currently running code backed out to "cvs up -D'2021/11/26 15:00'"
> > as a workaround.  My config looks like
> > 
> > -
> > set fragmentation
> > 
> > ikev2 "default" passive esp from 0.0.0.0/0 to dynamic \
> >  \
> >   local lll.ll.lll.lll \
> >   peer any \
> >  \
> >   ikesa enc aes-128-gcm group curve25519 group ecp521 group ecp256 group 
> > modp2048 \
> >   ikesa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 group 
> > curve25519 group ecp521 group ecp256 group modp2048 group modp1024 \
> >  \
> >   childsa enc aes-128-gcm group curve25519 group ecp521 group ecp256 group 
> > modp2048 \
> >   childsa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 group 
> > curve25519 group ecp521 group ecp256 group modp2048 group modp1024 \
> >  \
> >   childsa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 \
> >  \
> >   srcid "" \
> >   lifetime 3h bytes 5G \
> >   eap "mschap-v2" \
> >   config address ttt.ttt.tt.ttt/26 \
> >   config name-server lll.ll.lll.aa \
> >   config name-server lll.ll.lll.bb \
> >   tag "$name-$id"
> > 
> > ikev2 "keysim" active tunnel esp from 0.0.0.0/0 to 100.70.76.0/22 \
> > local lll.ll.lll.lll peer kk.kkk.kkk.kkk \
> > ikesa auth hmac-sha2-256 enc aes-256 group modp3072 \
> > childsa auth hmac-sha2-256 enc aes-256 group modp3072 \
> > srcid lll.ll.lll.lll dstid kk.kkk.kkk.kkk \
> > lifetime 3h bytes 20G \
> > psk  \
> > tag "keysim"
> > 
> > include "/etc/iked.users"
> > -
> > 
> 



iked problems with Apple clients in 7.1

2022-05-20 Thread Stuart Henderson
I ran into problems with Apple clients failing to connect to
iked after updating a machine to 7.1, introduced by
https://github.com/openbsd/src/commit/e3f5cf2ee26929d75dc2df9e86d97c36b2a94268

spi=0xac3d46687441f957: recv IKE_SA_INIT req 0 peer rrr.rrr.rrr.rr:49436 local 
lll.ll.lll.lll:500, 308 bytes, policy 'default'
spi=0xac3d46687441f957: send IKE_SA_INIT res 0 peer rrr.rrr.rrr.rr:49436 local 
lll.ll.lll.lll:500, 341 bytes
spi=0xac3d46687441f957: recv IKE_AUTH req 1 peer rrr.rrr.rrr.rr:64892 local 
lll.ll.lll.lll:4500, 368 bytes, policy 'default'
policy_test: localid mismatch
spi=0xac3d46687441f957: ikev2_ike_auth_recv: no compatible policy found
spi=0xac3d46687441f957: ikev2_send_auth_failed: authentication failed for
spi=0xac3d46687441f957: send IKE_AUTH res 1 peer rrr.rrr.rrr.rr:64892 local 
lll.ll.lll.lll:4500, 80 bytes, NAT-T
spi=0xac3d46687441f957: sa_free: authentication failed

I don't have full details of config done on the other side nor any
fruit-based phones to test from myself, did anyone already run into this
and figure out a way around it?

I'm currently running code backed out to "cvs up -D'2021/11/26 15:00'"
as a workaround.  My config looks like

-
set fragmentation

ikev2 "default" passive esp from 0.0.0.0/0 to dynamic \
 \
  local lll.ll.lll.lll \
  peer any \
 \
  ikesa enc aes-128-gcm group curve25519 group ecp521 group ecp256 group 
modp2048 \
  ikesa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 group 
curve25519 group ecp521 group ecp256 group modp2048 group modp1024 \
 \
  childsa enc aes-128-gcm group curve25519 group ecp521 group ecp256 group 
modp2048 \
  childsa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 group 
curve25519 group ecp521 group ecp256 group modp2048 group modp1024 \
 \
  childsa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 \
 \
  srcid "" \
  lifetime 3h bytes 5G \
  eap "mschap-v2" \
  config address ttt.ttt.tt.ttt/26 \
  config name-server lll.ll.lll.aa \
  config name-server lll.ll.lll.bb \
  tag "$name-$id"

ikev2 "keysim" active tunnel esp from 0.0.0.0/0 to 100.70.76.0/22 \
local lll.ll.lll.lll peer kk.kkk.kkk.kkk \
ikesa auth hmac-sha2-256 enc aes-256 group modp3072 \
childsa auth hmac-sha2-256 enc aes-256 group modp3072 \
srcid lll.ll.lll.lll dstid kk.kkk.kkk.kkk \
lifetime 3h bytes 20G \
psk  \
tag "keysim"

include "/etc/iked.users"
-



Re: iked(8): support for intermediate CAs and multiple CERT payloads

2022-05-20 Thread Stuart Henderson
On 2022/05/20 00:39, Loïc Revest wrote:
> ()Hello Stuart,
> 
> Thanks for giving it also a try - I was the one bothering Tobias
> earlier today with
> this use case of a Windows 10 (21H2) client trying to connect to an iked 
> server
> whose CA certificate wasn't self-signed, but signed by a root CA.

I think if it were actually signed _directly_ by a root CA then it would
have worked anyway, the issue is where it's signed by an intermediate (which
is the case for most, possibly all, CAs now in browser/OS root stores)

> > For Windows this works provided that ISRG Root X1 is already in the
> > computer trust store. It seems this is present on some but not other
> > Windows installations - if you get "IKE authentication credentials
> > are unacceptable" this is the likely failure.
> 
> Windows initiates the connection as long as, as you note, the root CA is in
> the computer trust store - along with the iked CA, otherwise I get the "IKE
> authentication credentials are unacceptable" error you were referring to.
> 
> On the other hand I initially (OpenBSD 7.1 release) got on iked side
> (iked -dv) the following "errors":
> 
> ikev2_pld_cert: multiple cert payloads not supported
> ikev2_resp_recv: failed to parse message
> 
> Leading to a timeout (sa_free: SA_INIT timeout) notified on both ends.
> 
> I did try with a "consolidated" /etc/iked/ca/ca.crt (iked cert + the one
> from the signing CA) as well as with a "lone" one (iked cert

This definitely doesn't work without the diff. If it is connecting
anyway then it is something that gets quietly fixed up on the client
side. (In the case of https webservers, it is common for gui browsers
to do that, whereas command-line clients typically don't - similar
situation with IKEv2 clients where some handle it and others don't).

> >
> >
> > I have connected successfully with Windows 20H2.
> 
> I got the same "error" after having applied Tobias' updated diff.
> 
> It's therefore likely that I did something different (wrong?) from you on
> Windows and/or iked side...

With this diff as-is, on the iked side, certs/hostname.example.org.crt
needs to contain only the server cert, and ca/ca.crt should contain either
the intermediate, or intermediate + root.

On the Windows client side, if you still see the error with the above
(I don't recall whether you need to restart iked or not to get it to take
effect) then you _may_ need to open https://valid-isrgrootsx1.letsencrypt.org/
in MSIE or perhaps some other browser to get it to update the root store.



Re: iked(8): support for intermediate CAs and multiple CERT payloads

2022-05-19 Thread Stuart Henderson
> > I haven't tested Windows yet, I'll try to locate a machine to test with
> > at the weekend.
> > 
> > The certificate arrangement is a little awkward to work with typical
> > ACME infrastructure used with standard TLS servers:
> > 
> > For a standard server the root certificate would not normally need to
> > be present at all; only server and intermediate certs are needed (though
> > possibly this may be different for IKEv2).  As such, ACME clients don't
> > normally fetch this certificate so it must be retrieved separately.
> > 
> > Also typically for a TLS server, any intermediates would be stored
> > alongside the server certificate (fullchain.pem in the usual acme-client
> > config). Storing that in a separate file isn't difficult ("chain" rather
> > than "full chain" for acme-client) but, combined with the above need
> > to store the CA in that same file, it does mean some extra fiddling is
> > required.
> > 
> > So to use this diff as-is with acme-client, something like this is needed
> > (I haven't tested the whole thing put together but I think it's right),
> > 
> > domain key "/etc/iked/private/local.key"
> > domain certificate "/etc/iked/certs/hostname.crt"
> > domain chain certificate "/etc/iked/ca/chain.crt"
> > 
> > 
> > 
> > ftp -o /etc/iked/ca/ca.p7c $(openssl x509 -in /etc/iked/ca/chain.crt -text 
> > -noout | grep 'CA Issuers' | cut -d: -f2-)
> > 
> > (cat /etc/iked/ca/chain.crt; openssl pkcs7 -inform DER -in 
> > /etc/iked/ca/ca.p7c -print_certs) > /etc/iked/ca/ca.crt

This command no longer works as-is, perhaps due to letsencrypt's (ab)use
of the old java/android bug providing a dodgy chain to let it work with
old devices.

However I have been successful in connecting with a ca.crt file with
the standard contents of "chain certificate" as fetched for a letsencrypt
cert by acme-client without the extra messing about. Also before I tried
that I had a manually generated one with just the following certificate
which also worked::

Subject: C=US, O=Let's Encrypt, CN=R3
Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1

No problem with StrongSwan on recent Android.

For Windows this works provided that ISRG Root X1 is already in the
computer trust store. It seems this is present on some but not other
Windows installations - if you get "IKE authentication credentials
are unacceptable" this is the likely failure. Or you can check in
MMC > certificates (local computer) > trusted root CAs. If you don't
have ISRG Root X1 shown there then open a browser (I have had
success with Internet Explorer and Chrome but not Edge, YMMV) and
open https://valid-isrgrootsx1.letsencrypt.org/, which will silently
add the new root CA to the store, at which point the VPN should work.

It is likely to work lower-hassle with Buypass as they are already
in the Windows CA store and don't rely on the automatic fetching.

> Here is an updated version of the diff working with -current iked since
> I was reminded of this missing feature lately.
> Stuart is probably right in that we should support fullchain.pem style
> chains in a single file, but this is something we can fix in-tree.
> 
> It would be nice if we could get someone to test if it works with
> Windows.

I have connected successfully with Windows 20H2.

OK


> Index: ca.c
> ===
> RCS file: /cvs/src/sbin/iked/ca.c,v
> retrieving revision 1.87
> diff -u -p -r1.87 ca.c
> --- ca.c  14 Dec 2021 13:44:36 -  1.87
> +++ ca.c  19 May 2022 14:28:21 -
> @@ -328,6 +328,32 @@ ca_setcert(struct iked *env, struct iked
>   return (0);
>  }
>  
> +static int
> +ca_setscert(struct iked *env, struct iked_sahdr *sh, uint8_t type, X509 
> *cert)
> +{
> + struct ioveciov[3];
> + int iovcnt = 0;
> + struct ibuf *buf;
> + int ret;
> +
> + if ((buf = ca_x509_serialize(cert)) == NULL)
> + return (-1);
> +
> + iov[iovcnt].iov_base = sh;
> + iov[iovcnt].iov_len = sizeof(*sh);
> + iovcnt++;
> + iov[iovcnt].iov_base = 
> + iov[iovcnt].iov_len = sizeof(type);
> + iovcnt++;
> + iov[iovcnt].iov_base = ibuf_data(buf);
> + iov[iovcnt].iov_len = ibuf_size(buf);
> + iovcnt++;
> +
> + ret = proc_composev(>sc_ps, PROC_IKEV2, IMSG_SCERT, iov, iovcnt);
> + ibuf_release(buf);
> + return (ret);
> +}
> +
>  int
>  ca_setreq(struct iked *env, struct iked_sa *sa,
>  struct iked_static_id *localid, uint8_t type, uint8_t more, uint8_t 
> *data,
> @@ -541,6 +567,51 @@ ca_getcert(struct iked *env, struct imsg
>   return (0);
>  }
>  
> +static unsigned int
> +ca_chain_by_issuer(struct ca_store *store, X509_NAME *subject,
> +struct iked_static_id *id, X509 **dst, size_t dstlen)
> +{
> + STACK_OF(X509_OBJECT)   *h;
> + X509_OBJECT *xo;
> + X509*cert;
> + int i;
> + 

Re: Picky, but much more efficient arc4random_uniform!

2022-05-16 Thread Stuart Henderson
On 2022/05/16 15:13, Luke Small wrote:
> If you’re not running a threaded program, my function wouldn’t be “less
> safe.”
> 
> I’d imagine that 99% of programs aren’t multithreaded.

code is reused in different places. non threaded programs are sometimes
turned into threaded programs and when that happens, sometimes
non-thread-safe calls are missed. so i'd argue that it is still less
safe.

in some cases there might be benefits that would mean it's worth it,
especially if the failure modes would be obvious such that they can
be detected. really not seeing that here. (how often are you even
calling arc4random_uniform to consider it slow?!)

if the consequence is not a crash but instead subtly broken randomness,
how long do you think it's going to take to notice and report/fix it?
even *very* broken randomness in widespread software distributions
has been known to sit around for a long time before it's noticed:

- predictable rng in a popular os. *serious* bug. introduced 2006,
discovered/reported nearly 2 years later.

- non-fork-safe rng in a popular ssl library, introduced sometime before
sept 2018, reported may 2019.



Re: Picky, but much more efficient arc4random_uniform!

2022-05-14 Thread Stuart Henderson
On 2022/05/14 06:56, Luke Small wrote:
> If I use arc4random_uniform() repeatedly to create a random distribution of
> say numbers less than 0x1000 or even something weird like 0x1300 will the
> random distribution be better with arc4random_uniform() or with mine?

there's no point to have a choice of different arc4random_uniform_xyz
with different characteristics, how is somebody going to pick the
"right" one?

the bottom of netbsd's version of the arc4random(3) manual says it well:

 One may be tempted to create new APIs to accommodate different security
 models and performance constraints without unpleasant surprises on dif-
 ferent operating systems.  This should not be done lightly, though,
 because there are already too many different choices, and too many oppor-
 tunities for programmers to reach for one and pick the wrong one.

what's the perceived problem you're wanting to solve? and does that
problem actually exist in the first place?



changelist: add /etc/login.conf.d/*

2022-05-12 Thread Stuart Henderson
changelist already has /etc/login.conf, but I think files in the .d
directory should be checked too, both so we have notification of changes
(as it can set environment variables this is a very powerful file), and
also so we keep old versions in /var/backup.

ok?

Index: changelist
===
RCS file: /cvs/src/etc/changelist,v
retrieving revision 1.130
diff -u -p -r1.130 changelist
--- changelist  11 Nov 2021 09:38:14 -  1.130
+++ changelist  12 May 2022 10:55:18 -
@@ -62,6 +62,7 @@
 /etc/ldpd.conf
 /etc/locate.rc
 /etc/login.conf
+/etc/login.conf.d/*
 /etc/login_ldap.conf
 /etc/mail.rc
 /etc/mail/aliases



Re: [External] : Re: pf.conf(5) clarify ICMP sloppy state handling

2022-05-09 Thread Stuart Henderson
On 2022/05/09 23:16, Alexandr Nedvedicky wrote:
> Hello,
> 
> I'm sorry I was too fast with commit. I've just committed
> what's been suggested by bluhm@:

That's totally ok, my diff is on top and wasn't written until you
committed yours :-)

> @@ -2186,6 +2186,7 @@ It cannot be used with
>  .Cm modulate state
>  or
>  .Cm synproxy state .
> +With this option ICMP replies can create states.
>  .It Ar timeout seconds
>  Changes the
>  .Ar timeout
> 
> 
> > This is helpful, but because it's so surprising that "pass proto icmp"
> > doesn't pass all icmp traffic, I think it would help to mention it where
> > "proto icmp" is described too.
> > 
> > Also, the top of the text about "sloppy" just talks about the sloppy
> > TCP connection tracker, I think perhaps it would be better to lead
> > with something that suggests it has multiple functions for different
> > protocols?
> 
> I don't object to any of your enhancements.
> 
> reads OK sashan

Thanks.



Re: [External] : Re: pf.conf(5) clarify ICMP sloppy state handling

2022-05-09 Thread Stuart Henderson
This is helpful, but because it's so surprising that "pass proto icmp"
doesn't pass all icmp traffic, I think it would help to mention it where
"proto icmp" is described too.

Also, the top of the text about "sloppy" just talks about the sloppy
TCP connection tracker, I think perhaps it would be better to lead
with something that suggests it has multiple functions for different
protocols?

Index: man5/pf.conf.5
===
RCS file: /cvs/src/share/man/man5/pf.conf.5,v
retrieving revision 1.594
diff -u -p -r1.594 pf.conf.5
--- man5/pf.conf.5  9 May 2022 20:29:23 -   1.594
+++ man5/pf.conf.5  9 May 2022 21:05:48 -
@@ -594,6 +594,13 @@ or
 .Pc
 must match.
 .Pp
+ICMP responses are not permitted unless they either match an
+existing request, or unless
+.Cm no state
+or
+.Cm keep state (sloppy)
+is specified.
+.Pp
 .It Cm label Ar string
 Adds a label to the rule, which can be used to identify the rule.
 For instance,
@@ -2177,7 +2184,7 @@ States created by this rule are exported
 .Xr pflow 4
 interface.
 .It Cm sloppy
-Uses a sloppy TCP connection tracker that does not check sequence
+For TCP, uses a sloppy connection tracker that does not check sequence
 numbers at all, which makes insertion and ICMP teardown attacks way
 easier.
 This is intended to be used in situations where one does not see all
@@ -2186,7 +2193,8 @@ It cannot be used with
 .Cm modulate state
 or
 .Cm synproxy state .
-With this option ICMP replies can create states.
+For ICMP, this option allows states to be created from replies,
+not just requests.
 .It Ar timeout seconds
 Changes the
 .Ar timeout



Re: allow 240/4 in various network daemons

2022-05-05 Thread Stuart Henderson
On 2022/05/05 15:28, Jeroen Massar wrote:
> Though they did it with 1.0.0.0/8 (though that is just a huge network 
> telescope).

No this still does not work reliably



Re: Reserved address behavior (alternate broadcast and 240/4)

2022-05-05 Thread Stuart Henderson
On 2022/05/05 08:36, Claudio Jeker wrote:
> 
> Agreed, there is also IN_BADCLASS() which is used by the routing daemons.
> IN_EXPERIMENTAL and IN_BADCLASS are the same definition.
> 
> Looking at debian code search IN_EXPERIMENTAL() is still referenced in a
> bunch of packages. So I wonder if your alternative to just make
> IN_EXPERIMENTAL never match is the right approach.

It looks all or nearly all guarded with ifdefs in some way or other.
I don't know what the best approach is but I will do a ports bulk with
this removed completely to collect data about how many things fail
(I think it will be at the most single-digit numbers, and quite possibly
0).



Re: NETGEAR RAX200 support

2022-05-01 Thread Stuart Henderson
On 2022/05/01 13:46, Johannes (krjdev) Krottmayer wrote:
> Yes, the information should be correct. I have extracted the vendor
> firmware image with binwalk. I have investigated the root Device-Tree
> blob. There will be also a modified Linux distribution from  OpenWrt
> used. But these modification are garbage for me.
> 
> Why?
> 
> Some NO-Go's for me:
> 
> - The router need a Android app for configuration in the default setup
> - The WebUI is NOT accessible when WAN isn't connected OR there is an
> issue. The configuration needs a specific WWW domain.
> 
> Yes, to configure the router you must use a website in the unsafe WWW
> to configure the router, WLAN, firewall, ...
> 
> So it's high priority for me to get rid of this garbage vendor
> fimware...

The simplest path using this hardware may be to build vendor firmware
from their GPL sources (_if_ they provide enough to do so) and modify it.

You might be happier selling it and buying alternative hardware though.



Re: NETGEAR RAX200 support

2022-05-01 Thread Stuart Henderson
On 2022/05/01 12:27, Mark Kettenis wrote:
> > Date: Sun, 1 May 2022 11:13:13 +0200
> > From: "Johannes (krjdev) Krottmayer" 
> > 
> > Hi,
> 
> Hi Johannes,
> 
> > 
> > Exists there an official support for this router?
> > 
> > Here the official product page:
> > https://www.netgear.com/home/wifi/routers/rax200/
> > 
> > If there is no official support for the SoC and the devices, I will
> > try to add support for it. I'm currently need only to get the Ethernet
> > ports to work for my personal new CAT8 home network. :)
> > 
> > Short technical data:
> > Base architecture: Quad core Cortex-A53 running at 1.8Ghz
> > SoC: Vendor Broadcom (Model currently unknown). Must open the
> > router and investigate all hardware components and figure out the
> > pins for the debug UART.

BCM4908:

https://wikidevi.wi-cat.ru/Netgear_RAX200_(Nighthawk_Tri-Band_AX12)
https://fcc.report/FCC-ID/PY318400434/4326262

> If that information is correct, then you'd have to basically start
> from scratch.  The only Broadcom SoC that OpenBSD supports is the one
> found in the Raspberry Pi, which is almost certainly completely
> unrelated to the Soc in your router.

And at least with Raspberry Pi, the Pi foundation did significant work
getting at least some documentation made available for the hardware
they're using.

> Broadcom doesn't publically release documentation for their SoCs.  If
> the SoC is supported in Linux you might learn enough about it to add
> support for it.  This isn't going to be an easy job.
> 
> > My first goal is to add UART support. So I can communicate via the
> > serial console.
> > 
> > 
> 

I think this is not a great target for any open source OS, let alone
one with fairly limited developer resources. With this device you'll be
lucky if you even get OpenWRT working on it (and they have much broader
hw support than OpenBSD).

Even if it can be made to work, don't expect to get anywhere
particularly close to performance seen with the vendor OS.



Re: EVFILT_USER and kevent(2)

2022-04-30 Thread Stuart Henderson
On 2022/04/30 13:51, Visa Hankala wrote:
> I am in two minds about EVFILT_USER. On the one hand, having it on
> OpenBSD might help with ports.

No opinion on the addition, but I don't think we ran into this in ports
so far. There is software in ports which can use it but it can all work
without too. (I know about zeek and asterisk's res_timing_kqueue, though
we typically don't use the latter at all anyway as it has a pluggable
timer implementation and the pthread timer seems more accurate).



bwfm(4): show modulation type for the various chipsets

2022-04-23 Thread Stuart Henderson
saves time if you want to ignore 11n-only devices. ok?

Index: share/man/man4/bwfm.4
===
RCS file: /cvs/src/share/man/man4/bwfm.4,v
retrieving revision 1.16
diff -u -p -r1.16 bwfm.4
--- share/man/man4/bwfm.4   5 Jan 2022 17:39:24 -   1.16
+++ share/man/man4/bwfm.4   23 Apr 2022 17:51:24 -
@@ -35,29 +35,29 @@ as well as the bus attachments recognize
 .Nm
 driver:
 .Bl -column "Chipset" "Spectrum" "MIMO" "Bus" -offset 6n
-.It Em Chipset Ta Em Spectrum Ta Em MIMO Ta Em Bus
-.It BCM43143 Ta 2GHz Ta 1x1 Ta SDMMC/USB
-.It BCM43236 Ta 2GHz/5GHz Ta 2x2 Ta USB
-.It BCM4324 Ta  2GHz/5GHz Ta 2x2 Ta SDMMC
-.It BCM43242 Ta 2GHz/5GHz Ta 2x2 Ta USB
-.It BCM4329 Ta  2GHz/5GHz Ta 2x2 Ta SDMMC
-.It BCM4330 Ta  2GHz/5GHz Ta 2x2 Ta SDMMC
-.It BCM4334 Ta  2GHz/5GHz Ta 2x2 Ta SDMMC
-.It BCM43340 Ta 2GHz/5GHz Ta 1x1 Ta SDMMC
-.It BCM43341 Ta 2GHz/5GHz Ta 1x1 Ta SDMMC
-.It BCM4335 Ta  2GHz/5GHz Ta 1x1 Ta SDMMC
-.It BCM43362 Ta 2GHz Ta 1x1 Ta SDMMC
-.It BCM43364 Ta 2GHz Ta 1x1 Ta SDMMC
-.It BCM4339 Ta  2GHz/5GHz Ta 1x1 Ta SDMMC
-.It BCM43430 Ta 2GHz Ta 1x1 Ta SDMMC
-.It BCM43455 Ta  2GHz/5GHz Ta 1x1 Ta SDMMC
-.It BCM43456 Ta  2GHz/5GHz Ta 2x2 Ta SDMMC
-.It BCM4350 Ta 2GHz/5GHz Ta 2x2 Ta PCI
-.It BCM4354 Ta  2GHz/5GHz Ta 2x2 Ta SDMMC
-.It BCM4356 Ta 2GHz/5GHz Ta 2x2 Ta PCI/SDMMC
-.It BCM43569 Ta 2GHz/5GHz Ta 2x2 Ta USB
-.It BCM43602 Ta 2GHz/5GHz Ta 3x3 Ta PCI
-.It BCM4371 Ta 2GHz/5GHz Ta 2x2 Ta PCI
+.It Em Chipset Ta Em Spectrum Ta Em Type Ta Em MIMO Ta Em Bus
+.It BCM43143 Ta 2GHz Ta 11n Ta 1x1 Ta SDMMC/USB
+.It BCM43236 Ta 2GHz/5GHz Ta 11n Ta 2x2 Ta USB
+.It BCM4324 Ta  2GHz/5GHz Ta 11n Ta 2x2 Ta SDMMC
+.It BCM43242 Ta 2GHz/5GHz Ta 11n Ta 2x2 Ta USB
+.It BCM4329 Ta  2GHz/5GHz Ta 11n Ta 2x2 Ta SDMMC
+.It BCM4330 Ta  2GHz/5GHz Ta 11n Ta 2x2 Ta SDMMC
+.It BCM4334 Ta  2GHz/5GHz Ta 11n Ta 2x2 Ta SDMMC
+.It BCM43340 Ta 2GHz/5GHz Ta 11n Ta 1x1 Ta SDMMC
+.It BCM43341 Ta 2GHz/5GHz Ta 11n Ta 1x1 Ta SDMMC
+.It BCM4335 Ta  2GHz/5GHz Ta 11ac Ta 1x1 Ta SDMMC
+.It BCM43362 Ta 2GHz Ta 11n Ta 1x1 Ta SDMMC
+.It BCM43364 Ta 2GHz Ta 11n Ta 1x1 Ta SDMMC
+.It BCM4339 Ta  2GHz/5GHz Ta 11ac Ta 1x1 Ta SDMMC
+.It BCM43430 Ta 2GHz Ta 11n Ta 1x1 Ta SDMMC
+.It BCM43455 Ta  2GHz/5GHz Ta 11ac Ta 1x1 Ta SDMMC
+.It BCM43456 Ta  2GHz/5GHz Ta 11ac Ta 2x2 Ta SDMMC
+.It BCM4350 Ta 2GHz/5GHz Ta 11ac Ta 2x2 Ta PCI
+.It BCM4354 Ta  2GHz/5GHz Ta 11ac Ta 2x2 Ta SDMMC
+.It BCM4356 Ta 2GHz/5GHz Ta 11ac Ta 2x2 Ta PCI/SDMMC
+.It BCM43569 Ta 2GHz/5GHz Ta 11ac Ta 2x2 Ta USB
+.It BCM43602 Ta 2GHz/5GHz Ta 11ac Ta 3x3 Ta PCI
+.It BCM4371 Ta 2GHz/5GHz Ta 11ac Ta 2x2 Ta PCI
 .El
 .Pp
 These are the modes the



Re: patch: if_iwx.c add support for ax201 with subsystem id 0x0030

2022-04-09 Thread Stuart Henderson
On 2022/04/09 12:47, Sven Wolf wrote:
> Hi Stefan,
> 
> sorry, I'm not sure how I can get the sc_hw_rev value.
> Hopefully this is the requested value:
> 
> iwx0: hw rev 0x350, fw ver 67.8f59b80b.0

hw rev in this line is masked (sc->sc_hw_rev & IWX_CSR_HW_REV_TYPE_MSK
which is 0x000FFF0), the IWX_CSR_HW_REV_TYPE_xxx use some of the masked
bits so the whole lot is probably needed. just add another bit to the
printf to print it raw?



Re: possible memory leak in ipmi get_sdr

2022-04-07 Thread Stuart Henderson
On 2022/04/07 13:31, Moritz Buhl wrote:
> Any insights?

> On Mon, Jan 10, 2022 at 03:18:47PM +0100, Moritz Buhl wrote:
> > Hi tech@,
> > 
> > The return value of add_child_sensors is returned in add_sdr_sensor,
> > which is called by get_sdr.  get_sdr mallocs psdr and only frees it
> > if add_sdr_sensor returns 0.  The assumption is that psdr is attached
> > to a list in add_child_sensors otherwise.  This is not the case if
> > the malloc for psensor fails, or read_sensor() equals 0.  In any
> > of these error cases psdr is leaked.

I think you mean "This is not the case if the malloc for psensor fails,
or read_sensor() _DOES NOT_ equal 0"?

Anyway, the diff makes sense and is ok sthen@

While I'm thinking of ipmi(4), any comments on
https://marc.info/?l=openbsd-tech=164460370813852=2?

(Return values in the ipmi.c code are pretty messy, mixture of rc and
rv variable names, and 1/-1 as well as errno values, and the existing
handling in read_sensor() seems a bit silly, though not functionally
bad).

> > Index: sys/dev/ipmi.c
> > ===
> > RCS file: /mount/openbsd/cvs/src/sys/dev/ipmi.c,v
> > retrieving revision 1.115
> > diff -u -p -r1.115 ipmi.c
> > --- sys/dev/ipmi.c  23 Jan 2021 12:10:08 -  1.115
> > +++ sys/dev/ipmi.c  10 Jan 2022 13:49:19 -
> > @@ -1374,7 +1374,7 @@ add_child_sensors(struct ipmi_softc *sc,
> >  int sensor_num, int sensor_type, int ext_type, int sensor_base,
> >  int entity, const char *name)
> >  {
> > -   int typ, idx;
> > +   int typ, idx, rc = 0;
> > struct ipmi_sensor  *psensor;
> >  #ifdef IPMI_DEBUG
> > struct sdrtype1 *s1 = (struct sdrtype1 *)psdr;
> > @@ -1415,11 +1415,12 @@ add_child_sensors(struct ipmi_softc *sc,
> > dbg_printf(5, "  reading: %lld [%s]\n",
> > psensor->i_sensor.value,
> > psensor->i_sensor.desc);
> > +   rc = 1;
> > } else
> > free(psensor, M_DEVBUF, sizeof(*psensor));
> > }
> >  
> > -   return (1);
> > +   return (rc);
> >  }
> >  
> >  /* Handle IPMI Timer - reread sensor values */
> > 
> 



Re: ure(4): add support for RTL8156B

2022-04-02 Thread Stuart Henderson
On 2022/04/02 15:47, Stuart Henderson wrote:
> It doesn't, but this fixes it:
> 
> Index: if_ure.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
> retrieving revision 1.29
> diff -u -p -r1.29 if_ure.c
> --- if_ure.c  2 Apr 2022 12:22:56 -   1.29
> +++ if_ure.c  2 Apr 2022 14:46:50 -
> @@ -2142,7 +2142,7 @@ ure_encap_txpkt(struct mbuf *m, char *bu
>  
>  #if NVLAN > 0
>   if (m->m_flags & M_VLANTAG)
> - cflags |= swap16(m->m_pkthdr.ether_vtag | URE_TXPKT_VLAN_TAG);
> + cflags |= URE_TXPKT_VLAN_TAG | swap16(m->m_pkthdr.ether_vtag);
>  #endif
>  
>   txhdr.ure_pktlen = htole32(m->m_pkthdr.len | URE_TXPKT_TX_FS |
> 

And here's equivalent code in Realtek's Linux driver:

 2059 static inline void rtl_tx_vlan_tag(struct tx_desc *desc, struct sk_buff 
*skb)
 2060 {
 2061 if (skb_vlan_tag_present(skb)) {
 2062 u32 opts2;
 2063 
 2064 opts2 = TX_VLAN_TAG | swab16(skb_vlan_tag_get(skb));
 2065 desc->opts2 |= cpu_to_le32(opts2);
 2066 }
 2067 } 



Re: ure(4): add support for RTL8156B

2022-04-02 Thread Stuart Henderson
On 2022/04/02 18:14, Kevin Lo wrote:
> On Fri, Apr 01, 2022 at 06:09:26PM +0100, Stuart Henderson wrote:
> > 
> > On 2022/04/01 17:13, Stuart Henderson wrote:
> > > On 2022/04/01 10:26, Gerhard Roth wrote:
> > > > On 4/1/22 07:41, Kevin Lo wrote:
> > > > > 
> > > > > ure0: RTL8153 (0x5c10), address 00:e0:4c:xx:xx:xx
> > > > > rgephy1 at ure0 phy 0: RTL8251 PHY, rev. 0
> > > > > 
> > > > > ure0: RTL8153B (0x6010), address f4:28:53:xx:xx:xx
> > > > > rgephy1 at ure0 phy 0: RTL8251 PHY, rev. 0
> > > > > 
> > > > > ure0 at uhub0 port 4 configuration 1 interface 0 "Planex USB 
> > > > > 10/100/1G/2.5G LAN" rev 2.10/30.00 addr 5
> > > > > ure0: RTL8156 (0x7030), address 1c:c0:35:xx:xx:xx
> > > > > 
> > > > 
> > > > 
> > > > You can add another one to the list that works just fine with your
> > > > patch:
> > > > 
> > > > ure0 at uhub1 port 1 configuration 1 interface 0 "Realtek USB 
> > > > 10/100/1000 LAN" rev 3.00/30.00 addr 2
> > > > ure0: RTL8153 (0x5c30), address 00:13:3b:xx:xx:xx
> > > > rgephy0 at ure0 phy 0: RTL8251 PHY, rev. 0
> > > 
> > > No new issues seen on RTL8153B:
> > > 
> > > ure0 at uhub0 port 15 configuration 1 interface 0 "Realtek USB 
> > > 10/100/1000 LAN" rev 3.00/31.00 addr 10
> > > ure0: RTL8153B (0x6010), address 00:e0:4c:38:2b:0f
> > > rgephy0 at ure0 phy 0: RTL8251 PHY, rev. 0
> > > 
> > > I have also tested with vlan and discovered an existing issue,
> > > it seems that vlan transmission is not working correctly: no tag
> > > is sent on the outgoing packet. Reception appears to be ok.
> > > This occurs with the previous code too so it is not a regression.
> > > 
> > 
> > Tx works ok if I disable hw tagging.
> 
> Thanks for the findings.  Does it help if you replace the line [1] with
> "reg |= URE_CPCR_RX_VLAN | 0x80;" ?
> 
> [1] https://github.com/openbsd/src/blob/master/sys/dev/usb/if_ure.c#L724
> 

It doesn't, but this fixes it:

Index: if_ure.c
===
RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
retrieving revision 1.29
diff -u -p -r1.29 if_ure.c
--- if_ure.c2 Apr 2022 12:22:56 -   1.29
+++ if_ure.c2 Apr 2022 14:46:50 -
@@ -2142,7 +2142,7 @@ ure_encap_txpkt(struct mbuf *m, char *bu
 
 #if NVLAN > 0
if (m->m_flags & M_VLANTAG)
-   cflags |= swap16(m->m_pkthdr.ether_vtag | URE_TXPKT_VLAN_TAG);
+   cflags |= URE_TXPKT_VLAN_TAG | swap16(m->m_pkthdr.ether_vtag);
 #endif
 
txhdr.ure_pktlen = htole32(m->m_pkthdr.len | URE_TXPKT_TX_FS |



  1   2   3   4   5   6   7   8   9   10   >