Re: sppp(4)/pppoe(4) - DNS configuration via resolvd(8)

2021-11-09 Thread Sebastien Marie 
On Wed, Nov 10, 2021 at 07:35:26AM +0100, Bjorn Ketelaars wrote:
> On Mon 08/11/2021 11:52, Bjorn Ketelaars wrote:
> > Diff below does two things:
> > 1. add PPP IPCP extensions for name server addresses (rfc1877) to
> >sppp(4)
> > 2. propose negotiated name servers from sppp(4) to resolvd(8) using
> >RTM_PROPOSAL_STATIC route messages.
> 
> 
> Updated diff below, based on feedback from kn@ and claudio@:
> 
> - fix forgotten parentheses with `sizeof`
> - instead of using `u_int32_t` use `struct in_addr` for holding dns
>   addresses. Makes it more clear what the data is
> - decouple `IPCP_OPT` definitions from the bitmask values to
>   enable/disable an option. Makes the code look a bit better
> - use `memcpy`
> - fit code within 80 columns
> 
> While here add RFC to sppp(4)'s STANDARDS section.
> 
> @kn, is this still OK for you?
> 
> Other OK's?

There is one point which bother me a bit: you are using
RTP_PROPOSAL_STATIC for sending the proposal, whereas all others
sources (dhcpleased/dhclient, slaacd, umb) are using a specific value.

By using RTP_PROPOSAL_STATIC, it means also that route(8) nameserver
subcommand might interfere with it.

Using a new specific value (like RTP_PROPOSAL_SPPP) would make sense
to me. But no objection if RTM_PROPOSAL_STATIC is preferred.

> +void
> +sppp_update_dns(struct ifnet *ifp)
> +{
> + struct rt_addrinfo info;
> + struct sockaddr_rtdns rtdns;
> + struct sppp *sp = ifp->if_softc;
> + size_t sz = 0;
> + int i, flag = 0;
> +
> + memset(&rtdns, 0, sizeof(rtdns));
> + memset(&info, 0, sizeof(info));
> +
> + for (i = 0; i < IPCP_MAX_DNSSRV; i++) {
> + if (sp->ipcp.dns[i].s_addr == INADDR_ANY)
> + break;
> + sz = sizeof(sp->ipcp.dns[i].s_addr);
> + memcpy(rtdns.sr_dns + i * sz, &sp->ipcp.dns[i].s_addr, sz);
> + flag = RTF_UP;
> + }
> +
> + rtdns.sr_family = AF_INET;
> + rtdns.sr_len = 2 + i * sz;
> + info.rti_info[RTAX_DNS] = srtdnstosa(&rtdns);
> +
> + rtm_proposal(ifp, &info, flag, RTP_PROPOSAL_STATIC);
> +}

Thanks.
-- 
Sebastien Marie

Re: sppp(4)/pppoe(4) - DNS configuration via resolvd(8)

2021-11-09 Thread Bjorn Ketelaars 
On Mon 08/11/2021 11:52, Bjorn Ketelaars wrote:
> Diff below does two things:
> 1. add PPP IPCP extensions for name server addresses (rfc1877) to
>sppp(4)
> 2. propose negotiated name servers from sppp(4) to resolvd(8) using
>RTM_PROPOSAL_STATIC route messages.


Updated diff below, based on feedback from kn@ and claudio@:

- fix forgotten parentheses with `sizeof`
- instead of using `u_int32_t` use `struct in_addr` for holding dns
  addresses. Makes it more clear what the data is
- decouple `IPCP_OPT` definitions from the bitmask values to
  enable/disable an option. Makes the code look a bit better
- use `memcpy`
- fit code within 80 columns

While here add RFC to sppp(4)'s STANDARDS section.

@kn, is this still OK for you?

Other OK's?


diff --git share/man/man4/sppp.4 share/man/man4/sppp.4
index 5ca10285953..bccb41eec15 100644
--- share/man/man4/sppp.4
+++ share/man/man4/sppp.4
@@ -230,6 +230,13 @@ take place.
 .Re
 .Pp
 .Rs
+.%A S. Cobb
+.%D December 1995
+.%R RFC 1877
+.%T PPP Internet Protocol Control Protocol Extensions for Name Server Addresses
+.Re
+.Pp
+.Rs
 .%A W. Simpson
 .%D August 1996
 .%R RFC 1994
diff --git sys/net/if_sppp.h sys/net/if_sppp.h
index ff559fcc369..5850a6da963 100644
--- sys/net/if_sppp.h
+++ sys/net/if_sppp.h
@@ -132,6 +132,8 @@ struct sipcp {
  * original one here, in network byte order */
u_int32_t req_hisaddr;  /* remote address requested (IPv4) */
u_int32_t req_myaddr;   /* local address requested (IPv4) */
+#define IPCP_MAX_DNSSRV2
+   struct in_addr dns[IPCP_MAX_DNSSRV]; /* IPv4  DNS servers (RFC 1877) */
 #ifdef INET6
struct in6_aliasreq req_ifid;   /* local ifid requested (IPv6) */
 #endif
diff --git sys/net/if_spppsubr.c sys/net/if_spppsubr.c
index ac1dc9a709d..e460703c089 100644
--- sys/net/if_spppsubr.c
+++ sys/net/if_spppsubr.c
@@ -132,6 +132,14 @@
 #define IPCP_OPT_ADDRESSES 1   /* both IP addresses; deprecated */
 #define IPCP_OPT_COMPRESSION   2   /* IP compression protocol (VJ) */
 #define IPCP_OPT_ADDRESS   3   /* local IP address */
+#define IPCP_OPT_PRIMDNS   129 /* primary remote dns address */
+#define IPCP_OPT_SECDNS131 /* secondary remote dns address 
*/
+
+#define SPPP_IPCP_OPT_ADDRESSES1   /* bitmask value */
+#define SPPP_IPCP_OPT_COMPRESSION  2   /* bitmask value */
+#define SPPP_IPCP_OPT_ADDRESS  3   /* bitmask value */
+#define SPPP_IPCP_OPT_PRIMDNS  4   /* bitmask value */
+#define SPPP_IPCP_OPT_SECDNS   5   /* bitmask value */
 
 #define IPV6CP_OPT_IFID1   /* interface identifier */
 #define IPV6CP_OPT_COMPRESSION 2   /* IPv6 compression protocol */
@@ -338,6 +346,8 @@ void sppp_update_gw(struct ifnet *ifp);
 void sppp_set_ip_addrs(void *);
 void sppp_clear_ip_addrs(void *);
 void sppp_set_phase(struct sppp *sp);
+void sppp_update_dns(struct ifnet *ifp);
+void sppp_rtrequest(struct ifnet *ifp, int req, struct rtentry *rt);
 
 /* our control protocol descriptors */
 static const struct cp lcp = {
@@ -701,6 +711,7 @@ sppp_attach(struct ifnet *ifp)
 
sp->pp_if.if_type = IFT_PPP;
sp->pp_if.if_output = sppp_output;
+   sp->pp_if.if_rtrequest = sppp_rtrequest;
ifq_set_maxlen(&sp->pp_if.if_snd, 50);
mq_init(&sp->pp_cpq, 50, IPL_NET);
sp->pp_loopcnt = 0;
@@ -2512,13 +2523,19 @@ sppp_ipcp_RCN_rej(struct sppp *sp, struct lcp_header 
*h, int len)
 * Peer doesn't grok address option.  This is
 * bad.  XXX  Should we better give up here?
 */
-   sp->ipcp.opts &= ~(1 << IPCP_OPT_ADDRESS);
+   sp->ipcp.opts &= ~(1 << SPPP_IPCP_OPT_ADDRESS);
break;
 #ifdef notyet
case IPCP_OPT_COMPRESS:
-   sp->ipcp.opts &= ~(1 << IPCP_OPT_COMPRESS);
+   sp->ipcp.opts &= ~(1 << SPPP_IPCP_OPT_COMPRESS);
break;
 #endif
+   case IPCP_OPT_PRIMDNS:
+   sp->ipcp.opts &= ~(1 << SPPP_IPCP_OPT_PRIMDNS);
+   break;
+   case IPCP_OPT_SECDNS:
+   sp->ipcp.opts &= ~(1 << SPPP_IPCP_OPT_SECDNS);
+   break;
}
}
if (debug)
@@ -2559,7 +2576,7 @@ sppp_ipcp_RCN_nak(struct sppp *sp, struct lcp_header *h, 
int len)
if (len >= 6 && p[1] == 6) {
wantaddr = p[2] << 24 | p[3] << 16 |
p[4] << 8 | p[5];
-   sp->ipcp.opts |= (1 << IPCP_OPT_ADDRESS);
+   sp->ipcp.opts |= (1 << SPPP_IPCP_OPT_ADDRESS);
if (debug)
addlog("[wantaddr %s] ",
   sppp_do

Re: uhidev: claim multiple report ids

2021-11-09 Thread Anton Lindqvist 
On Wed, Nov 03, 2021 at 09:43:54AM +0100, Damien Couderc wrote:
> Le 03/11/2021 à 07:44, Anton Lindqvist a écrit :
> > Hi,
> > In an attempt to fix a bug related to upd(4) I discovered that the
> > pseudo report id UHIDEV_CLAIM_MULTIPLE_REPORTID is conflicting with an
> > actual report id. The previous fix, reverted by now, avoided the
> > conflict by incrementing the pseudo report id was not a good idea
> > since a report id is expected to be represented using a single unsigned
> > byte elsewhere in the usb stack.
> > 
> > Here's a second attempt. Report id zero is according to the USB HID
> > specification reserved and should not be used. We can define
> > UHIDEV_CLAIM_MULTIPLE_REPORTID as zero removing the need to use a larger
> > integer type than the existing uint8_t for the report id. Another
> > correction is also needed. Some descriptors only supports a single
> > report and the report id is in this case optional. Internally, uhidev
> > uses report id zero for such devices. It's therefore of importance to
> > not perform a claim multiple report ids attachment on such devices as
> > there's only one report id to claim.
> > 
> > Testing would be much appreciated.
> > 
> > Comments? OK?
> > 
> > diff --git sys/dev/usb/uhidev.c sys/dev/usb/uhidev.c
> > index 5fe2f702e21..f5cc5984b59 100644
> > --- sys/dev/usb/uhidev.c
> > +++ sys/dev/usb/uhidev.c
> > @@ -247,29 +247,36 @@ uhidev_attach(struct device *parent, struct device 
> > *self, void *aux)
> > sc->sc_isize += (nrepid != 1);  /* one byte for the report ID */
> > DPRINTF(("uhidev_attach: isize=%d\n", sc->sc_isize));
> > +   memset(&uha, 0, sizeof(uha));
> > uha.uaa = uaa;
> > uha.parent = sc;
> > -   uha.reportid = UHIDEV_CLAIM_MULTIPLE_REPORTID;
> > -   uha.nreports = nrepid;
> > -   uha.claimed = malloc(nrepid, M_TEMP, M_WAITOK|M_ZERO);
> > /* Look for a driver claiming multiple report IDs first. */
> > -   dev = config_found_sm(self, &uha, NULL, uhidevsubmatch);
> > -   if (dev != NULL) {
> > -   for (repid = 0; repid < nrepid; repid++) {
> > -   /*
> > -* Could already be assigned by uhidev_set_report_dev().
> > -*/
> > -   if (sc->sc_subdevs[repid] != NULL)
> > -   continue;
> > -
> > -   if (uha.claimed[repid])
> > +   if (nrepid > 1) {
> > +   uha.reportid = UHIDEV_CLAIM_MULTIPLE_REPORTID;
> > +   uha.nreports = nrepid;
> > +   uha.claimed = malloc(nrepid, M_TEMP, M_WAITOK|M_ZERO);
> > +
> > +   dev = config_found_sm(self, &uha, NULL, uhidevsubmatch);
> > +   if (dev != NULL) {
> > +   for (repid = 0; repid < nrepid; repid++) {
> > +   /*
> > +* Could already be assigned by
> > +* uhidev_set_report_dev().
> > +*/
> > +   if (sc->sc_subdevs[repid] != NULL)
> > +   continue;
> > +
> > +   if (!uha.claimed[repid])
> > +   continue;
> > sc->sc_subdevs[repid] = (struct uhidev *)dev;
> > +   }
> > }
> > -   }
> > -   free(uha.claimed, M_TEMP, nrepid);
> > -   uha.claimed = NULL;
> > +   free(uha.claimed, M_TEMP, nrepid);
> > +   uha.nreports = 0;
> > +   uha.claimed = NULL;
> > +   }
> > for (repid = 0; repid < nrepid; repid++) {
> > DPRINTF(("%s: try repid=%d\n", __func__, repid));
> > diff --git sys/dev/usb/uhidev.h sys/dev/usb/uhidev.h
> > index 6ce75b1f49d..9ae85e1ab9f 100644
> > --- sys/dev/usb/uhidev.h
> > +++ sys/dev/usb/uhidev.h
> > @@ -81,8 +81,8 @@ struct uhidev_attach_arg {
> > struct usb_attach_arg   *uaa;
> > struct uhidev_softc *parent;
> > uint8_t  reportid;
> > -#defineUHIDEV_CLAIM_MULTIPLE_REPORTID  255
> > -   uint8_t  nreports;
> > +#defineUHIDEV_CLAIM_MULTIPLE_REPORTID  0
> > +   u_intnreports;
> > uint8_t *claimed;
> >   };
> 
> Hi,
> 
> It works flawlessly for me and unplugging is fine too.

Thanks, committed.

uvm_swap: a simple LIST_FOREACH conversion

2021-11-09 Thread Theo Buehler 
I'd like to commit a few easy diffs to reduce differences to NetBSD in
UVM. This makes code comparison easier and also reduces the amount of
noise in WIP diffs I have for ongoing work on locking in UVM.

Here's a first one that converts a for loop to LIST_FOREACH:

Index: uvm/uvm_swap.c
===
RCS file: /cvs/src/sys/uvm/uvm_swap.c,v
retrieving revision 1.150
diff -u -p -r1.150 uvm_swap.c
--- uvm/uvm_swap.c  26 Mar 2021 13:40:05 -  1.150
+++ uvm/uvm_swap.c  10 Nov 2021 04:51:38 -
@@ -455,8 +455,8 @@ swaplist_insert(struct swapdev *sdp, str
/*
 * find entry at or after which to insert the new device.
 */
-   for (pspp = NULL, spp = LIST_FIRST(&swap_priority); spp != NULL;
-spp = LIST_NEXT(spp, spi_swappri)) {
+   pspp = NULL;
+   LIST_FOREACH(spp, &swap_priority, spi_swappri) {
if (priority <= spp->spi_priority)
break;
pspp = spp;

Re: New hw.perfpolicy behavior

2021-11-09 Thread Philip Guenther 
On Tue, Nov 9, 2021 at 3:29 PM Jan Stary  wrote:

> On Nov 10 00:21:59, h...@stare.cz wrote:
> > Regarding C states, this machine has
> >
> > acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10),
> C1(1000@1 mwait.1), PSS
> >
> > I suppose the cpu supports C1, C2, C3, but can someone please kindly
> > explain (or point to an explanation of) what the whole line says?
>
> For comparison, my Thinkpad T400 has
> acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10),
> C1(1000@1 mwait.1), PSS
> What does the ! mean?
>

This is generated by sys/dev/acpi/acpicpu.c:acpicpu_print_one_cst() and at
this point should either be suppressed by default or documented in the
manpage; I'm not sure which.

To enumerate it from right to left:

 !C3(100@57 mwait.3@0x30)
 ^  ^   ^   ^ ^ ^   ^
 |   ||| |  |   |
 |   ||| |  |   \-- 'hints' passed to the actual
MWAIT instruction, or address for 'io' method
 |   ||| |  \-- fixed-function level bit flags: 1="HW
coordinated" 2="bus-master avoidance required"
 |   ||| |   OR '!' if this is a faked-up fallback
to the pre-CST C1-via-HALT (bios is broken)
 |   ||| \-- sleep method, one of mwait, io, or halt
 |   ||\-- advertised latency when exiting the state
 |   |\-- advertised power-consumption
 |   \-- the C state, duh
 \-- '!' to indicate this state is disabled because the CPU's LAPIC stops
in C2 or deeper (no ARAT)

Re: New hw.perfpolicy behavior

2021-11-09 Thread Jan Stary 
On Nov 10 00:21:59, h...@stare.cz wrote:
> Regarding C states, this machine has
> 
> acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> 
> I suppose the cpu supports C1, C2, C3, but can someone please kindly
> explain (or point to an explanation of) what the whole line says?

For comparison, my Thinkpad T400 has
acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
What does the ! mean?

Re: New hw.perfpolicy behavior

2021-11-09 Thread Jan Stary 
On Nov 02 12:30:56, dera...@openbsd.org wrote:
> Paul de Weerd  wrote:
> 
> > A recent commit by Theo changed the hw.perfpolicy behavior to always
> > run at full speed when AC power is on.  This means that my workstation
> > (and servers, once I upgrade them) now consumes significantly more
> > power, even though they usually idle.
> 
> Did you measure how much more power?
> 
> You must measure, to make such a claim.
> 
> Your OptiPlex 9020 is probably a modern i5/i7, which probably contains
> C states similar to this:
> 
> acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
> 
> Which means when the idle loop calls the "mwait" instruction, the cpu
> will 'instantly' slow down to a lower clock and make other power use
> reductions, until an interrupt happens and requires labour again.
> 
> Most modern cpus dynamically downscale in such way, which mostly
> obliterates the requirement to manually control things, or even handle
> it in a slow-paced data-weak way in the scheduler.

Measuring on this PC running current/amd64 (dmesg below),
with a Sep 26 snapshot and the latest snapshot.

As a naive test, I am measuring the power consumption
of compiling the kernel (is that too small?).

The numbers are mostly the same on both of these systems,
with each of apmd with apm -A, -H, -L respectively,
or without running apmd at all. Namely, it takes
about 04:30 to make, and it consumes about 0.007 kWh.
Then again, doing nothing for 04:30 consumes about 0.004.
(Are these too small to be a measurement?)

Regarding C states, this machine has

acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 
mwait.1), PSS

I suppose the cpu supports C1, C2, C3, but can someone please kindly
explain (or point to an explanation of) what the whole line says?

Thank you

Jan

OpenBSD 7.0-current (GENERIC.MP) #85: Tue Nov  9 13:24:56 MST 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17009606656 (16221MB)
avail mem = 16478068736 (15714MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries)
bios0: vendor Award Software International, Inc. version "F3" date 03/31/2011
bios0: Gigabyte Technology Co., Ltd. H67MA-USB3-B3
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT
acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) 
PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xf400, bus 0-63
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.74 MHz, 06-2a-07
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.30 MHz, 06-2a-07
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.30 MHz, 06-2a-07
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.30 MHz, 06-2a-07
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 2

Re: arm64: new gpiokeys(4)

2021-11-09 Thread Jan Stary 
On Nov 09 15:43:04, k...@openbsd.org wrote:
> This populates `systat sensors' with the correct lid status on my
> Pinebook Pro:
> 
>   -gpio-key-lid at mainbus0 not configured
>   -gpio-key-power at mainbus0 not configured
>   +gpiokeys0 at mainbus0: "Lid"
>   +gpiokeys0 at mainbus0: "Power"


This is what the diff added on RPI4 (dmesg below).

-gpioleds0 at mainbus0: no LEDs
+gpioleds0 at mainbus0: "led0", "led1"

(Nothing new in systat sens,
as leds are not sensors.)

Jan


OpenBSD 7.0-current (GENERIC.MP) #0: Tue Nov  9 21:52:42 CET 2021
h...@pi.stare.cz:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 8419885056 (8029MB)
avail mem = 8128704512 (7752MB)
random: good seed from bootblocks
mainbus0 at root: Raspberry Pi 4 Model B Rev 1.4
cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3
cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu0: 1024KB 64b/line 16-way L2 cache
cpu0: CRC32,ASID16
cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3
cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu1: 1024KB 64b/line 16-way L2 cache
cpu1: CRC32,ASID16
cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3
cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu2: 1024KB 64b/line 16-way L2 cache
cpu2: CRC32,ASID16
cpu3 at mainbus0 mpidr 3: ARM Cortex-A72 r0p3
cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu3: 1024KB 64b/line 16-way L2 cache
cpu3: CRC32,ASID16
efi0 at mainbus0: UEFI 2.8
efi0: Das U-Boot rev 0x20210100
apm0 at mainbus0
"system" at mainbus0 not configured
"axi" at mainbus0 not configured
simplebus0 at mainbus0: "soc"
bcmclock0 at simplebus0
bcmmbox0 at simplebus0
bcmgpio0 at simplebus0
bcmaux0 at simplebus0
ampintc0 at simplebus0 nirq 256, ncpu 4 ipi: 0, 1: "interrupt-controller"
bcmtmon0 at simplebus0
bcmdmac0 at simplebus0: DMA0 DMA2 DMA4 DMA5 DMA6 DMA7 DMA8 DMA9
"timer" at simplebus0 not configured
pluart0 at simplebus0: console
"local_intc" at simplebus0 not configured
bcmdog0 at simplebus0
bcmirng0 at simplebus0
"firmware" at simplebus0 not configured
"power" at simplebus0 not configured
"mailbox" at simplebus0 not configured
sdhc0 at simplebus0
sdhc0: SDHC 3.0, 250 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
"gpiomem" at simplebus0 not configured
"fb" at simplebus0 not configured
"vcsm" at simplebus0 not configured
"clocks" at mainbus0 not configured
"phy" at mainbus0 not configured
"clk-27M" at mainbus0 not configured
"clk-108M" at mainbus0 not configured
simplebus1 at mainbus0: "emmc2bus"
sdhc1 at simplebus1
sdhc1: SDHC 3.0, 100 MHz base clock
sdmmc1 at sdhc1: 8-bit, sd high-speed, mmc high-speed, ddr52, dma
"arm-pmu" at mainbus0 not configured
agtimer0 at mainbus0: 54000 kHz
simplebus2 at mainbus0: "scb"
bcmpcie0 at simplebus2
pci0 at bcmpcie0
ppb0 at pci0 dev 0 function 0 "Broadcom BCM2711" rev 0x10
pci1 at ppb0 bus 1
xhci0 at pci1 dev 0 function 0 "VIA VL805 xHCI" rev 0x01: intx, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "VIA xHCI root hub" rev 3.00/1.00 
addr 1
bse0 at simplebus2: address dc:a6:32:e0:50:d3
brgphy0 at bse0 phy 1: BCM54210E 10/100/1000baseT PHY, rev. 2
"dma" at simplebus2 not configured
"hevc-decoder" at simplebus2 not configured
"rpivid-local-intc" at simplebus2 not configured
"h264-decoder" at simplebus2 not configured
"vp9-decoder" at simplebus2 not configured
gpioleds0 at mainbus0: "led0", "led1"
"sd_io_1v8_reg" at mainbus0 not configured
"sd_vcc_reg" at mainbus0 not configured
"fixedregulator_3v3" at mainbus0 not configured
"fixedregulator_5v0" at mainbus0 not configured
simplebus3 at mainbus0: "v3dbus"
"bootloader" at mainbus0 not configured
dt: 445 probes
scsibus0 at sdmmc1: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  removable
sd0: 30436MB, 512 bytes/sector, 62333952 sectors
uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs USB2.0 Hub" rev 
2.10/4.21 addr 2
bwfm0 at sdmmc0 function 1
manufacturer 0x02d0, product 0xa9a6 at sdmmc0 function 2 not configured
manufacturer 0x02d0, product 0xa9a6 at sdmmc0 function 3 not configured
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on sd0a (d1a7e0233ab9545d.a) swap on sd0b dump on sd0b
WARNING: CHECK AND RESET THE DATE!
gpio0 at bcmgpio0: 58 pins
bwfm0: address dc:a6:32:e0:50:d4

Re: add 802.11n 40MHz support to iwn(4)

2021-11-09 Thread Stuart Henderson 
On 2021/11/09 20:38, Jan Stary wrote:
> On Nov 09 00:36:03, h...@stare.cz wrote:
> > As a naive test of speed, I am downloading a 100MB file
> > from a http server just behind the AP with
> > ftp -o /dev/null http://stare.cz/.tmp/file
> > An average of ten runs is 5.31 MB/s without the diff
> > and 3.37 MB/s with the (updated) diff.
> 
> Any idea how enabling 40 MHz could slow it down?
> 
>   Jan
> 

One possibility is interference in the extended part of the channel
that isn't present in the basic 20MHz.

Re: add 802.11n 40MHz support to iwn(4)

2021-11-09 Thread Stefan Sperling 
On Tue, Nov 09, 2021 at 08:38:11PM +0100, Jan Stary wrote:
> On Nov 09 00:36:03, h...@stare.cz wrote:
> > As a naive test of speed, I am downloading a 100MB file
> > from a http server just behind the AP with
> > ftp -o /dev/null http://stare.cz/.tmp/file
> > An average of ten runs is 5.31 MB/s without the diff
> > and 3.37 MB/s with the (updated) diff.
> 
> Any idea how enabling 40 MHz could slow it down?
> 
>   Jan

No idea. On my 5300 it is much faster, but I have tested it on 5 GHz.
Try a 5 GHz channel instead of a 2GHz channel.

Re: add 802.11n 40MHz support to iwn(4)

2021-11-09 Thread Jan Stary 
On Nov 09 00:36:03, h...@stare.cz wrote:
> As a naive test of speed, I am downloading a 100MB file
> from a http server just behind the AP with
> ftp -o /dev/null http://stare.cz/.tmp/file
> An average of ten runs is 5.31 MB/s without the diff
> and 3.37 MB/s with the (updated) diff.

Any idea how enabling 40 MHz could slow it down?

Jan

Re: rpki-client ip_addr_print cleanup

2021-11-09 Thread Klemens Nanni 
On Tue, Nov 09, 2021 at 08:05:10PM +0100, Claudio Jeker wrote:
> On Tue, Nov 09, 2021 at 07:44:41PM +0100, Claudio Jeker wrote:
> > ip_addr_print() can be simplified. ip4_addr2str() and ip6_addr2str() are
> > the same apart from the different AF argument to inet_ntop(). Just collaps
> > all into ip_addr_print().
> 
> This version is using a switch statement and fails hard for unknown AFIs.
> Suggested by Theo.

OK kn, one thing.

> @@ -277,11 +242,25 @@ void
>  ip_addr_print(const struct ip_addr *addr,
>  enum afi afi, char *buf, size_t bufsz)
>  {
> + char ipbuf[44];

Why not INET6_ADDRSTRLEN?

> + int ret, af;
> +
> + switch (afi) {
> + case AFI_IPV4:
> + af = AF_INET;
> + break;
> + case AFI_IPV6:
> + af = AF_INET6;
> + break;
> + default:
> + errx(1, "unsupported address family identifier");
> + }
>  
> - if (afi == AFI_IPV4)
> - ip4_addr2str(addr, buf, bufsz);
> - else
> - ip6_addr2str(addr, buf, bufsz);
> + if (inet_ntop(af, addr->addr, ipbuf, sizeof(ipbuf)) == NULL)
> + err(1, "inet_ntop");
> + ret = snprintf(buf, bufsz, "%s/%hhu", ipbuf, addr->prefixlen);
> + if (ret < 0 || (size_t)ret >= bufsz)
> + err(1, "malformed IP address");
>  }
>  
>  /*
>

Re: rpki-client sync http escape handling with ftp(1)

2021-11-09 Thread Klemens Nanni 
On Tue, Nov 09, 2021 at 07:52:06PM +0100, Claudio Jeker wrote:
> kn@ removed '~' from unsafe_chars but also changed the code at the same
> time. This tries to bring the version in rpki-client back in sync with the
> code in ftp(1).

Didn't know there was such a copy.

OK kn

Re: relayd regress tcp performance

2021-11-09 Thread Stuart Henderson 
What's the status of this diff?

On 2021/09/21 17:30, Alexander Bluhm wrote:
> On Sat, Sep 18, 2021 at 02:35:20PM +0200, Jan Klemkow wrote:
> > The following diff removes the every 2nd ACK feature again and ensures
> > that we send out an ACK if soreceive() empties the receive buffer.
> 
> Looks good in my perform tests, 22% tcp throughput increase.
> 
> http://bluhm.genua.de/perform/results/2021-09-20T11:05:31Z/perform.html
> http://bluhm.genua.de/perform/results/2021-09-20T11:05:31Z/gnuplot/tcp.html
> 
> > We are so close to 7.0, that I would suggest to commit this after the
> > release.  Thus, we don't risk another last minute regression.
> > 
> > OK?
> 
> OK bluhm@ post 7.0
> 
> > Index: netinet/tcp_input.c
> > ===
> > RCS file: /cvs/src/sys/netinet/tcp_input.c,v
> > retrieving revision 1.370
> > diff -u -p -r1.370 tcp_input.c
> > --- netinet/tcp_input.c 9 Aug 2021 17:03:08 -   1.370
> > +++ netinet/tcp_input.c 18 Sep 2021 07:53:45 -
> > @@ -176,8 +176,7 @@ do { \
> > struct ifnet *ifp = NULL; \
> > if (m && (m->m_flags & M_PKTHDR)) \
> > ifp = if_get(m->m_pkthdr.ph_ifidx); \
> > -   if (TCP_TIMER_ISARMED(tp, TCPT_DELACK) || \
> > -   (tcp_ack_on_push && (tiflags) & TH_PUSH) || \
> > +   if ((tcp_ack_on_push && (tiflags) & TH_PUSH) || \
> > (ifp && (ifp->if_flags & IFF_LOOPBACK))) \
> > tp->t_flags |= TF_ACKNOW; \
> > else \
> > Index: netinet/tcp_usrreq.c
> > ===
> > RCS file: /cvs/src/sys/netinet/tcp_usrreq.c,v
> > retrieving revision 1.181
> > diff -u -p -r1.181 tcp_usrreq.c
> > --- netinet/tcp_usrreq.c30 Apr 2021 13:52:48 -  1.181
> > +++ netinet/tcp_usrreq.c18 Sep 2021 07:53:45 -
> > @@ -329,8 +329,15 @@ tcp_usrreq(struct socket *so, int req, s
> >  * template for a listening socket and hence the kernel
> >  * will panic.
> >  */
> > -   if ((so->so_state & (SS_ISCONNECTED|SS_ISCONNECTING)) != 0)
> > +   if ((so->so_state & (SS_ISCONNECTED|SS_ISCONNECTING)) != 0) {
> > +   /*
> > +* If soreceive() empty the receive buffer, we have to
> > +* send a window update.
> > +*/
> > +   if (so->so_rcv.sb_cc == 0)
> > +   tp->t_flags |= TF_ACKNOW;
> > (void) tcp_output(tp);
> > +   }
> > break;
> >  
> > /*
>

Re: rpki-client ip_addr_print cleanup

2021-11-09 Thread Claudio Jeker 
On Tue, Nov 09, 2021 at 07:44:41PM +0100, Claudio Jeker wrote:
> ip_addr_print() can be simplified. ip4_addr2str() and ip6_addr2str() are
> the same apart from the different AF argument to inet_ntop(). Just collaps
> all into ip_addr_print().

This version is using a switch statement and fails hard for unknown AFIs.
Suggested by Theo.

-- 
:wq Claudio

Index: ip.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/ip.c,v
retrieving revision 1.19
diff -u -p -r1.19 ip.c
--- ip.c5 Nov 2021 10:50:41 -   1.19
+++ ip.c9 Nov 2021 18:59:34 -
@@ -234,41 +234,6 @@ ip_addr_parse(const ASN1_BIT_STRING *p,
 }
 
 /*
- * Convert the IPv4 address into CIDR notation conforming to RFC 4632.
- * Buffer should be able to hold xxx.yyy.zzz.www/nn.
- */
-static void
-ip4_addr2str(const struct ip_addr *addr, char *b, size_t bsz)
-{
-   char buf[16];
-   int ret;
-
-   if (inet_ntop(AF_INET, addr->addr, buf, sizeof(buf)) == NULL)
-   err(1, "inet_ntop");
-   ret = snprintf(b, bsz, "%s/%hhu", buf, addr->prefixlen);
-   if (ret < 0 || (size_t)ret >= bsz)
-   err(1, "malformed IPV4 address");
-}
-
-/*
- * Convert the IPv6 address into CIDR notation conforming to RFC 4291.
- * See also RFC 5952.
- * Must hold :::::::/nn.
- */
-static void
-ip6_addr2str(const struct ip_addr *addr, char *b, size_t bsz)
-{
-   char buf[44];
-   int ret;
-
-   if (inet_ntop(AF_INET6, addr->addr, buf, sizeof(buf)) == NULL)
-   err(1, "inet_ntop");
-   ret = snprintf(b, bsz, "%s/%hhu", buf, addr->prefixlen);
-   if (ret < 0 || (size_t)ret >= bsz)
-   err(1, "malformed IPV6 address");
-}
-
-/*
  * Convert a ip_addr into a NUL-terminated CIDR notation string
  * conforming to RFC 4632 or 4291.
  * The size of the buffer must be at least 64 (inclusive).
@@ -277,11 +242,25 @@ void
 ip_addr_print(const struct ip_addr *addr,
 enum afi afi, char *buf, size_t bufsz)
 {
+   char ipbuf[44];
+   int ret, af;
+
+   switch (afi) {
+   case AFI_IPV4:
+   af = AF_INET;
+   break;
+   case AFI_IPV6:
+   af = AF_INET6;
+   break;
+   default:
+   errx(1, "unsupported address family identifier");
+   }
 
-   if (afi == AFI_IPV4)
-   ip4_addr2str(addr, buf, bufsz);
-   else
-   ip6_addr2str(addr, buf, bufsz);
+   if (inet_ntop(af, addr->addr, ipbuf, sizeof(ipbuf)) == NULL)
+   err(1, "inet_ntop");
+   ret = snprintf(buf, bufsz, "%s/%hhu", ipbuf, addr->prefixlen);
+   if (ret < 0 || (size_t)ret >= bufsz)
+   err(1, "malformed IP address");
 }
 
 /*

rpki-client sync http escape handling with ftp(1)

2021-11-09 Thread Claudio Jeker 
kn@ removed '~' from unsafe_chars but also changed the code at the same
time. This tries to bring the version in rpki-client back in sync with the
code in ftp(1).

-- 
:wq Claudio

Index: http.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/http.c,v
retrieving revision 1.49
diff -u -p -r1.49 http.c
--- http.c  9 Nov 2021 11:00:43 -   1.49
+++ http.c  9 Nov 2021 18:49:27 -
@@ -211,14 +211,17 @@ http_info(const char *uri)
 }
 
 /*
- * Determine whether the character needs encoding, per RFC1738:
- * - No corresponding graphic US-ASCII.
- * - Unsafe characters.
+ * Determine whether the character needs encoding, per RFC2396.
  */
 static int
-unsafe_char(const char *c0)
+to_encode(const char *c0)
 {
-   const char *unsafe_chars = " <>\"#{}|\\^~[]`";
+   /* 2.4.3. Excluded US-ASCII Characters */
+   const char *excluded_chars =
+   " " /* space */
+   "<>#\"" /* delims (modulo "%", see below) */
+   "{}|\\^[]`" /* unwise */
+   ;
const unsigned char *c = (const unsigned char *)c0;
 
/*
@@ -228,16 +231,15 @@ unsafe_char(const char *c0)
return (iscntrl(*c) || !isascii(*c) ||
 
/*
-* Unsafe characters.
-* '%' is also unsafe, if is not followed by two
+* '%' is also reserved, if is not followed by two
 * hexadecimal digits.
 */
-   strchr(unsafe_chars, *c) != NULL ||
+   strchr(excluded_chars, *c) != NULL ||
(*c == '%' && (!isxdigit(c[1]) || !isxdigit(c[2];
 }
 
 /*
- * Encode given URL, per RFC1738.
+ * Encode given URL, per RFC2396.
  * Allocate and return string to the caller.
  */
 static char *
@@ -254,7 +256,7 @@ url_encode(const char *path)
 * final URL.
 */
for (i = 0; i < length; i++)
-   if (unsafe_char(path + i))
+   if (to_encode(path + i))
new_length += 2;
 
epath = epathp = malloc(new_length + 1);/* One more for '\0'. */
@@ -266,7 +268,7 @@ url_encode(const char *path)
 * Encode, and copy final URL.
 */
for (i = 0; i < length; i++)
-   if (unsafe_char(path + i)) {
+   if (to_encode(path + i)) {
snprintf(epathp, 4, "%%" "%02x",
(unsigned char)path[i]);
epathp += 3;

Re: rpki-client ip_addr_print cleanup

2021-11-09 Thread Denis Fondras 
Le Tue, Nov 09, 2021 at 07:44:41PM +0100, Claudio Jeker a écrit :
> ip_addr_print() can be simplified. ip4_addr2str() and ip6_addr2str() are
> the same apart from the different AF argument to inet_ntop(). Just collaps
> all into ip_addr_print().
> 

OK denis@

> -- 
> :wq Claudio
> 
> Index: ip.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/ip.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 ip.c
> --- ip.c  5 Nov 2021 10:50:41 -   1.19
> +++ ip.c  9 Nov 2021 15:16:57 -
> @@ -234,41 +234,6 @@ ip_addr_parse(const ASN1_BIT_STRING *p,
>  }
>  
>  /*
> - * Convert the IPv4 address into CIDR notation conforming to RFC 4632.
> - * Buffer should be able to hold xxx.yyy.zzz.www/nn.
> - */
> -static void
> -ip4_addr2str(const struct ip_addr *addr, char *b, size_t bsz)
> -{
> - char buf[16];
> - int ret;
> -
> - if (inet_ntop(AF_INET, addr->addr, buf, sizeof(buf)) == NULL)
> - err(1, "inet_ntop");
> - ret = snprintf(b, bsz, "%s/%hhu", buf, addr->prefixlen);
> - if (ret < 0 || (size_t)ret >= bsz)
> - err(1, "malformed IPV4 address");
> -}
> -
> -/*
> - * Convert the IPv6 address into CIDR notation conforming to RFC 4291.
> - * See also RFC 5952.
> - * Must hold :::::::/nn.
> - */
> -static void
> -ip6_addr2str(const struct ip_addr *addr, char *b, size_t bsz)
> -{
> - char buf[44];
> - int ret;
> -
> - if (inet_ntop(AF_INET6, addr->addr, buf, sizeof(buf)) == NULL)
> - err(1, "inet_ntop");
> - ret = snprintf(b, bsz, "%s/%hhu", buf, addr->prefixlen);
> - if (ret < 0 || (size_t)ret >= bsz)
> - err(1, "malformed IPV6 address");
> -}
> -
> -/*
>   * Convert a ip_addr into a NUL-terminated CIDR notation string
>   * conforming to RFC 4632 or 4291.
>   * The size of the buffer must be at least 64 (inclusive).
> @@ -277,11 +242,17 @@ void
>  ip_addr_print(const struct ip_addr *addr,
>  enum afi afi, char *buf, size_t bufsz)
>  {
> + char ipbuf[44];
> + int ret, af = AF_INET;
> +
> + if (afi == AFI_IPV6)
> + af = AF_INET6;
>  
> - if (afi == AFI_IPV4)
> - ip4_addr2str(addr, buf, bufsz);
> - else
> - ip6_addr2str(addr, buf, bufsz);
> + if (inet_ntop(af, addr->addr, ipbuf, sizeof(ipbuf)) == NULL)
> + err(1, "inet_ntop");
> + ret = snprintf(buf, bufsz, "%s/%hhu", ipbuf, addr->prefixlen);
> + if (ret < 0 || (size_t)ret >= bufsz)
> + err(1, "malformed IP address");
>  }
>  
>  /*
>

rpki-client ip_addr_print cleanup

2021-11-09 Thread Claudio Jeker 
ip_addr_print() can be simplified. ip4_addr2str() and ip6_addr2str() are
the same apart from the different AF argument to inet_ntop(). Just collaps
all into ip_addr_print().

-- 
:wq Claudio

Index: ip.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/ip.c,v
retrieving revision 1.19
diff -u -p -r1.19 ip.c
--- ip.c5 Nov 2021 10:50:41 -   1.19
+++ ip.c9 Nov 2021 15:16:57 -
@@ -234,41 +234,6 @@ ip_addr_parse(const ASN1_BIT_STRING *p,
 }
 
 /*
- * Convert the IPv4 address into CIDR notation conforming to RFC 4632.
- * Buffer should be able to hold xxx.yyy.zzz.www/nn.
- */
-static void
-ip4_addr2str(const struct ip_addr *addr, char *b, size_t bsz)
-{
-   char buf[16];
-   int ret;
-
-   if (inet_ntop(AF_INET, addr->addr, buf, sizeof(buf)) == NULL)
-   err(1, "inet_ntop");
-   ret = snprintf(b, bsz, "%s/%hhu", buf, addr->prefixlen);
-   if (ret < 0 || (size_t)ret >= bsz)
-   err(1, "malformed IPV4 address");
-}
-
-/*
- * Convert the IPv6 address into CIDR notation conforming to RFC 4291.
- * See also RFC 5952.
- * Must hold :::::::/nn.
- */
-static void
-ip6_addr2str(const struct ip_addr *addr, char *b, size_t bsz)
-{
-   char buf[44];
-   int ret;
-
-   if (inet_ntop(AF_INET6, addr->addr, buf, sizeof(buf)) == NULL)
-   err(1, "inet_ntop");
-   ret = snprintf(b, bsz, "%s/%hhu", buf, addr->prefixlen);
-   if (ret < 0 || (size_t)ret >= bsz)
-   err(1, "malformed IPV6 address");
-}
-
-/*
  * Convert a ip_addr into a NUL-terminated CIDR notation string
  * conforming to RFC 4632 or 4291.
  * The size of the buffer must be at least 64 (inclusive).
@@ -277,11 +242,17 @@ void
 ip_addr_print(const struct ip_addr *addr,
 enum afi afi, char *buf, size_t bufsz)
 {
+   char ipbuf[44];
+   int ret, af = AF_INET;
+
+   if (afi == AFI_IPV6)
+   af = AF_INET6;
 
-   if (afi == AFI_IPV4)
-   ip4_addr2str(addr, buf, bufsz);
-   else
-   ip6_addr2str(addr, buf, bufsz);
+   if (inet_ntop(af, addr->addr, ipbuf, sizeof(ipbuf)) == NULL)
+   err(1, "inet_ntop");
+   ret = snprintf(buf, bufsz, "%s/%hhu", ipbuf, addr->prefixlen);
+   if (ret < 0 || (size_t)ret >= bufsz)
+   err(1, "malformed IP address");
 }
 
 /*

Re: ipsec ip deliver

2021-11-09 Thread Alexander Bluhm 
On Tue, Nov 09, 2021 at 02:00:01PM +0100, Denis Fondras wrote:
> > @@ -352,19 +343,19 @@ ipsec_common_input(struct mbuf **mp, int
> >  * Call appropriate transform and return -- callback takes care of
> >  * everything else.
> >  */
> > -   error = (*(tdbp->tdb_xform->xf_input))(mp, tdbp, skip, protoff);
> > -   if (error) {
> > +   prot = (*(tdbp->tdb_xform->xf_input))(mp, tdbp, skip, protoff);
> > +   if (prot == IPPROTO_DONE) {
> > ipsecstat_inc(ipsec_idrops);
> > tdbp->tdb_idrops++;
> > }
> > -   return error;
> > +   return prot;
> >  
> 
> As I read & understand, prot is always IPPROTO_DONE and ipsec_idrops is always
> incremented. Can you explain in which case it is not ?

For ESP it works this way.

esp_input()
/* Save the last three bytes of decrypted data */
m_copydata(m, m->m_pkthdr.len - 3, 3, lastthree);
...
/* Restore the Next Protocol field */
m_copyback(m, protoff, sizeof(u_int8_t), lastthree + 2, M_NOWAIT);
ipsec_common_input_cb()
prot = ip->ip_p;
...
/* Save protocol */
m_copydata(m, protoff, 1, (caddr_t) &prot);
...
/* Return to the appropriate protocol handler in deliver loop. */
return prot;
esp_input()
/* Back to generic IPsec input processing */
return ipsec_common_input_cb(mp, tdb, skip, protoff);

The protocol is stored in the mbuf to print it correctly in tcpdump -i enc0 .

I just realized that I forgot to include the bridge(4) part in my diff.
As I have no IPsec bridge(4) setup, could someone test this?

New diff.  ok?

bluhm

Index: net/if_bridge.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.357
diff -u -p -r1.357 if_bridge.c
--- net/if_bridge.c 23 Oct 2021 22:19:37 -  1.357
+++ net/if_bridge.c 1 Nov 2021 09:21:14 -
@@ -1487,7 +1487,7 @@ bridge_ipsec(struct ifnet *ifp, struct e
struct tdb *tdb;
u_int32_t spi;
u_int16_t cpi;
-   int error, off;
+   int error, off, prot;
u_int8_t proto = 0;
struct ip *ip;
 #ifdef INET6
@@ -1575,7 +1575,10 @@ bridge_ipsec(struct ifnet *ifp, struct e
tdb->tdb_soft_first_use);
}
 
-   (*(tdb->tdb_xform->xf_input))(&m, tdb, hlen, off);
+   prot = (*(tdb->tdb_xform->xf_input))(&m, tdb, hlen,
+   off);
+   if (prot != IPPROTO_DONE)
+   ip_deliver(&m, &hlen, prot, af);
return (1);
} else {
  skiplookup:
Index: netinet/ip_ah.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_ah.c,v
retrieving revision 1.165
diff -u -p -r1.165 ip_ah.c
--- netinet/ip_ah.c 25 Oct 2021 09:47:02 -  1.165
+++ netinet/ip_ah.c 1 Nov 2021 09:21:14 -
@@ -563,21 +563,18 @@ ah_input(struct mbuf **mp, struct tdb *t
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_wrap);
-   error = ENOBUFS;
goto drop;
case 2:
DPRINTF("old packet received in SA %s/%08x",
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_replay);
-   error = ENOBUFS;
goto drop;
case 3:
DPRINTF("duplicate packet received in SA %s/%08x",
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_replay);
-   error = ENOBUFS;
goto drop;
default:
DPRINTF("bogus value from checkreplaywindow() "
@@ -585,7 +582,6 @@ ah_input(struct mbuf **mp, struct tdb *t
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_replay);
-   error = ENOBUFS;
goto drop;
}
}
@@ -597,7 +593,6 @@ ah_input(struct mbuf **mp, struct tdb *t
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_badauthl);
-   error = EACCES;
goto drop;
}
if (skip + ahx->authsize + rplen > m->m_pkthdr.len) {
@@ -607,7 +602,6 @@ ah_input(struct mbuf **mp, struct tdb *t
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),

Re: Switch LibreSSL to use

2021-11-09 Thread Theo Buehler 
On Tue, Nov 09, 2021 at 07:54:51AM -0600, Brent Cook wrote:
> This switches libcrypto and libssl to use endian.h over
> machine/endian.h, easing some portability contortions. The Austin group
> works in mysterious ways, but endian.h also might be a POSIX
> standard in the wings, whatever 'Applied' means.
> https://www.austingroupbugs.net/view.php?id=162
> 
> ok?

ok tb

> 
> diff --git a/src/lib/libcrypto/bn/bn_nist.c b/src/lib/libcrypto/bn/bn_nist.c
> index b16584d6b9..4e98adfc8e 100644
> --- a/src/lib/libcrypto/bn/bn_nist.c
> +++ b/src/lib/libcrypto/bn/bn_nist.c
> @@ -56,8 +56,7 @@
>   *
>   */
>  
> -#include 
> -
> +#include 
>  #include 
>  #include 
>  
> diff --git a/src/lib/libcrypto/des/cfb_enc.c b/src/lib/libcrypto/des/cfb_enc.c
> index 59a3e71862..84a71bf52e 100644
> --- a/src/lib/libcrypto/des/cfb_enc.c
> +++ b/src/lib/libcrypto/des/cfb_enc.c
> @@ -57,7 +57,7 @@
>   */
>  
>  #include "des_locl.h"
> -#include 
> +#include 
>  
>  /* The input and output are loaded in multiples of 8 bits.
>   * What this means is that if you hame numbits=12 and length=2
> diff --git a/src/lib/libcrypto/gost/gost2814789.c 
> b/src/lib/libcrypto/gost/gost2814789.c
> index f1066f2467..c3d0754339 100644
> --- a/src/lib/libcrypto/gost/gost2814789.c
> +++ b/src/lib/libcrypto/gost/gost2814789.c
> @@ -49,8 +49,7 @@
>   * 
>   */
>  
> -#include 
> -
> +#include 
>  #include 
>  
>  #include 
> diff --git a/src/lib/libcrypto/gost/streebog.c 
> b/src/lib/libcrypto/gost/streebog.c
> index 61bce0e32c..c0b2006cd4 100644
> --- a/src/lib/libcrypto/gost/streebog.c
> +++ b/src/lib/libcrypto/gost/streebog.c
> @@ -49,8 +49,7 @@
>   * 
>   */
>  
> -#include 
> -
> +#include 
>  #include 
>  #include 
>  
> diff --git a/src/lib/libcrypto/modes/modes_lcl.h 
> b/src/lib/libcrypto/modes/modes_lcl.h
> index f8830e4deb..0d2541c49f 100644
> --- a/src/lib/libcrypto/modes/modes_lcl.h
> +++ b/src/lib/libcrypto/modes/modes_lcl.h
> @@ -6,7 +6,7 @@
>   * 
>   */
>  
> -#include 
> +#include 
>  
>  #include 
>  
> diff --git a/src/lib/libcrypto/modes/xts128.c 
> b/src/lib/libcrypto/modes/xts128.c
> index 0be23d4ea9..e4a89dc77b 100644
> --- a/src/lib/libcrypto/modes/xts128.c
> +++ b/src/lib/libcrypto/modes/xts128.c
> @@ -48,9 +48,10 @@
>   * 
>   */
>  
> -#include 
>  #include 
>  #include "modes_lcl.h"
> +
> +#include 
>  #include 
>  
>  #ifndef MODES_DEBUG
> diff --git a/src/lib/libcrypto/rc4/rc4_enc.c b/src/lib/libcrypto/rc4/rc4_enc.c
> index bd928b58c9..87223140bc 100644
> --- a/src/lib/libcrypto/rc4/rc4_enc.c
> +++ b/src/lib/libcrypto/rc4/rc4_enc.c
> @@ -56,7 +56,8 @@
>   * [including the GNU Public Licence.]
>   */
>  
> -#include 
> +#include 
> +
>  #include 
>  #include "rc4_locl.h"
>  
> diff --git a/src/lib/libcrypto/sha/sha256.c b/src/lib/libcrypto/sha/sha256.c
> index 9c05d3b0f8..632ebb9070 100644
> --- a/src/lib/libcrypto/sha/sha256.c
> +++ b/src/lib/libcrypto/sha/sha256.c
> @@ -9,8 +9,7 @@
>  
>  #if !defined(OPENSSL_NO_SHA) && !defined(OPENSSL_NO_SHA256)
>  
> -#include 
> -
> +#include 
>  #include 
>  #include 
>  
> diff --git a/src/lib/libcrypto/sha/sha512.c b/src/lib/libcrypto/sha/sha512.c
> index 6b95cfa72e..3752aa02fe 100644
> --- a/src/lib/libcrypto/sha/sha512.c
> +++ b/src/lib/libcrypto/sha/sha512.c
> @@ -5,8 +5,7 @@
>   * 
>   */
>  
> -#include 
> -
> +#include 
>  #include 
>  #include 
>  
> diff --git a/src/lib/libcrypto/sha/sha_locl.h 
> b/src/lib/libcrypto/sha/sha_locl.h
> index 46c9a39be2..07d4d2d39a 100644
> --- a/src/lib/libcrypto/sha/sha_locl.h
> +++ b/src/lib/libcrypto/sha/sha_locl.h
> @@ -186,7 +186,7 @@ int SHA1_Init(SHA_CTX *c)
>  #endif
>  
>  #if !defined(SHA1_ASM)
> -#include 
> +#include 
>  static void HASH_BLOCK_DATA_ORDER (SHA_CTX *c, const void *p, size_t num)
>   {
>   const unsigned char *data=p;
> diff --git a/src/lib/libcrypto/whrlpool/wp_block.c 
> b/src/lib/libcrypto/whrlpool/wp_block.c
> index 1e00a01330..1ab8630ecd 100644
> --- a/src/lib/libcrypto/whrlpool/wp_block.c
> +++ b/src/lib/libcrypto/whrlpool/wp_block.c
> @@ -36,9 +36,9 @@
>   *
>   */
>  
> +#include 
>  #include 
>  #include 
> -#include 
>  
>  #include "wp_locl.h"
>  
> diff --git a/src/lib/libssl/d1_pkt.c b/src/lib/libssl/d1_pkt.c
> index f0f393b0fd..98353e7a1a 100644
> --- a/src/lib/libssl/d1_pkt.c
> +++ b/src/lib/libssl/d1_pkt.c
> @@ -113,8 +113,7 @@
>   * [including the GNU Public Licence.]
>   */
>  
> -#include 
> -
> +#include 
>  #include 
>  #include 
>  
>

Re: Add missing .Dv in termios(4)

2021-11-09 Thread Jason McIntyre 
On Tue, Nov 09, 2021 at 06:55:07AM -0800, Simon Branch wrote:
> Simple change to format this sentence correctly in non-terminal
> environments.
> 

fixed, thanks.
jmc

> diff --git share/man/man4/termios.4 share/man/man4/termios.4
> index dfb7609dd6f..89818ca46c2 100644
> --- share/man/man4/termios.4
> +++ share/man/man4/termios.4
> @@ -1011,7 +1011,7 @@ overflowing the input queue.
>  The precise conditions under which
>  .Dv STOP
>  and
> -START
> +.Dv START
>  characters are transmitted are implementation defined.
>  .Pp
>  If
>

Re: arm64: new gpiokeys(4)

2021-11-09 Thread Mark Kettenis 
> Date: Tue,  9 Nov 2021 15:43:04 +
> From: Klemens Nanni 
> 
> This populates `systat sensors' with the correct lid status on my
> Pinebook Pro:
> 
>   -gpio-key-lid at mainbus0 not configured
>   -gpio-key-power at mainbus0 not configured
>   +gpiokeys0 at mainbus0: "Lid"
>   +gpiokeys0 at mainbus0: "Power"
> 
> 0/1 <-> closed/open is mapped exactly like acpibtn(4) already does on
> other machines, to maintain consistent user experience across devices.
> 
> Next steps are:
> - hook up lid status with `machdep.lidaction', see acpibtn(4)
> - handle power button -> hook up machdep.pwraction, see acpibtn(4)
> 
> 
> Sort gpio{led,charger,keys} while here.
> 
> Feedback? OK?

ok kettenis@

> diff 83b213946bcaccd148d4a46b6ebda89b120fc778 refs/heads/master
> blob - ab52b74cf7e9895cbcb29532b9898cdaf33e89f3
> blob + 0891a80caf135b983dea282f281d7f6089b52e30
> --- distrib/sets/lists/man/mi
> +++ distrib/sets/lists/man/mi
> @@ -1423,6 +1423,7 @@
>  ./usr/share/man/man4/gpiocharger.4
>  ./usr/share/man/man4/gpiodcf.4
>  ./usr/share/man/man4/gpioiic.4
> +./usr/share/man/man4/gpiokeys.4
>  ./usr/share/man/man4/gpioleds.4
>  ./usr/share/man/man4/gpioow.4
>  ./usr/share/man/man4/graphaudio.4
> blob - c32bc8962cd103da4ed17ad63a2162f63a16e639
> blob + 6057d2a559120ada9f43ae0f5e5e6eb63a514be8
> --- share/man/man4/Makefile
> +++ share/man/man4/Makefile
> @@ -37,7 +37,7 @@ MAN=aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \
>   fuse.4 fxp.4 \
>   gdt.4 gentbi.4 gem.4 gfrtc.4 gif.4 glenv.4 glkgpio.4 gpio.4 \
>   gpiocharger.4 gpiodcf.4 \
> - gpioiic.4 gpioleds.4 gpioow.4 graphaudio.4 gre.4 gscsio.4 \
> + gpioiic.4 gpiokeys.4 gpioleds.4 gpioow.4 graphaudio.4 gre.4 gscsio.4 \
>   hds.4 hiclock.4 hidwusb.4 hil.4 hilid.4 hilkbd.4 hilms.4 \
>   hireset.4 hitemp.4 hme.4 hotplug.4 hsq.4 \
>   hvn.4 hvs.4 hyperv.4 \
> blob - /dev/null
> blob + 44c147f04672fa1b72820ebd7692d7efbe17ceae (mode 644)
> --- /dev/null
> +++ share/man/man4/gpiokeys.4
> @@ -0,0 +1,50 @@
> +.\"  $OpenBSD: $
> +.\"
> +.\" Copyright (c) 2021 Klemens Nanni 
> +.\"
> +.\" Permission to use, copy, modify, and distribute this software for any
> +.\" purpose with or without fee is hereby granted, provided that the above
> +.\" copyright notice and this permission notice appear in all copies.
> +.\"
> +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> +.\"
> +.Dd $Mdocdate: September 02 2021 $
> +.Dt GPIOKEYS 4
> +.Os
> +.Sh NAME
> +.Nm gpiokeys
> +.Nd GPIO keys
> +.Sh SYNOPSIS
> +.Cd "gpiokeys* at fdt?"
> +.Sh DESCRIPTION
> +The
> +.Nm
> +driver handles events triggered by GPIO keys.
> +Currently, only lid status events are supported.
> +.Pp
> +The lid status is set up as a sensor and can be monitored using
> +.Xr sysctl 8
> +or
> +.Xr sensorsd 8 .
> +.Sh SEE ALSO
> +.Xr gpio 4 ,
> +.Xr intro 4 ,
> +.Xr sensorsd 8 ,
> +.Xr sysctl 8
> +.Sh HISTORY
> +The
> +.Nm
> +driver first appeared in
> +.Ox 7.1 .
> +.Sh AUTHORS
> +.An -nosplit
> +The
> +.Nm
> +driver was written by
> +.An Klemens Nanni Aq Mt k...@openbsd.org .
> blob - 809ece860c07df596da208638f2f3facc829cb72
> blob + 0ceac9b6159e5cfe43fc4e601274100df1c40ffa
> --- sys/arch/arm64/conf/GENERIC
> +++ sys/arch/arm64/conf/GENERIC
> @@ -131,8 +131,9 @@ amdgpu*   at pci?
>  drm* at amdgpu?
>  wsdisplay*   at amdgpu?
>  
> -gpioleds*at fdt?
>  gpiocharger* at fdt?
> +gpiokeys*at fdt?
> +gpioleds*at fdt?
>  
>  # Apple
>  apldart* at fdt?
> blob - 301500e9b0c6501be4d55feb5135ca223d6337cc
> blob + 3d73e22edf7802172b29a26cb8b503eaeb8f3aa9
> --- sys/dev/fdt/files.fdt
> +++ sys/dev/fdt/files.fdt
> @@ -589,10 +589,14 @@ device  dapmic
>  attach   dapmic at i2c
>  file dev/fdt/dapmic.cdapmic
>  
> -device   gpioleds
> -attach   gpioleds at fdt
> -file dev/fdt/gpioleds.c  gpioleds
> -
>  device   gpiocharger
>  attach   gpiocharger at fdt
>  file dev/fdt/gpiocharger.c   gpiocharger
> +
> +device   gpioleds
> +attach   gpioleds at fdt
> +file dev/fdt/gpioleds.c  gpioleds
> +
> +device   gpiokeys
> +attach   gpiokeys at fdt
> +file dev/fdt/gpiokeys.c  gpiokeys
> blob - /dev/null
> blob + 4b4ca55a5c825ad8d66fbc8ec198bbcd13352b7c (mode 644)
> --- /dev/null
> +++ sys/dev/fdt/gpiokeys.c
> @@ -0,0 +1,179 @@
> +/*   $OpenBSD: $ */
> +/*
> + * Copyright (c) 2021 Klemens Nanni 
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or

arm64: new gpiokeys(4)

2021-11-09 Thread Klemens Nanni 
This populates `systat sensors' with the correct lid status on my
Pinebook Pro:

-gpio-key-lid at mainbus0 not configured
-gpio-key-power at mainbus0 not configured
+gpiokeys0 at mainbus0: "Lid"
+gpiokeys0 at mainbus0: "Power"

0/1 <-> closed/open is mapped exactly like acpibtn(4) already does on
other machines, to maintain consistent user experience across devices.

Next steps are:
- hook up lid status with `machdep.lidaction', see acpibtn(4)
- handle power button -> hook up machdep.pwraction, see acpibtn(4)


Sort gpio{led,charger,keys} while here.

Feedback? OK?


diff 83b213946bcaccd148d4a46b6ebda89b120fc778 refs/heads/master
blob - ab52b74cf7e9895cbcb29532b9898cdaf33e89f3
blob + 0891a80caf135b983dea282f281d7f6089b52e30
--- distrib/sets/lists/man/mi
+++ distrib/sets/lists/man/mi
@@ -1423,6 +1423,7 @@
 ./usr/share/man/man4/gpiocharger.4
 ./usr/share/man/man4/gpiodcf.4
 ./usr/share/man/man4/gpioiic.4
+./usr/share/man/man4/gpiokeys.4
 ./usr/share/man/man4/gpioleds.4
 ./usr/share/man/man4/gpioow.4
 ./usr/share/man/man4/graphaudio.4
blob - c32bc8962cd103da4ed17ad63a2162f63a16e639
blob + 6057d2a559120ada9f43ae0f5e5e6eb63a514be8
--- share/man/man4/Makefile
+++ share/man/man4/Makefile
@@ -37,7 +37,7 @@ MAN=  aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \
fuse.4 fxp.4 \
gdt.4 gentbi.4 gem.4 gfrtc.4 gif.4 glenv.4 glkgpio.4 gpio.4 \
gpiocharger.4 gpiodcf.4 \
-   gpioiic.4 gpioleds.4 gpioow.4 graphaudio.4 gre.4 gscsio.4 \
+   gpioiic.4 gpiokeys.4 gpioleds.4 gpioow.4 graphaudio.4 gre.4 gscsio.4 \
hds.4 hiclock.4 hidwusb.4 hil.4 hilid.4 hilkbd.4 hilms.4 \
hireset.4 hitemp.4 hme.4 hotplug.4 hsq.4 \
hvn.4 hvs.4 hyperv.4 \
blob - /dev/null
blob + 44c147f04672fa1b72820ebd7692d7efbe17ceae (mode 644)
--- /dev/null
+++ share/man/man4/gpiokeys.4
@@ -0,0 +1,50 @@
+.\"$OpenBSD: $
+.\"
+.\" Copyright (c) 2021 Klemens Nanni 
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.Dd $Mdocdate: September 02 2021 $
+.Dt GPIOKEYS 4
+.Os
+.Sh NAME
+.Nm gpiokeys
+.Nd GPIO keys
+.Sh SYNOPSIS
+.Cd "gpiokeys* at fdt?"
+.Sh DESCRIPTION
+The
+.Nm
+driver handles events triggered by GPIO keys.
+Currently, only lid status events are supported.
+.Pp
+The lid status is set up as a sensor and can be monitored using
+.Xr sysctl 8
+or
+.Xr sensorsd 8 .
+.Sh SEE ALSO
+.Xr gpio 4 ,
+.Xr intro 4 ,
+.Xr sensorsd 8 ,
+.Xr sysctl 8
+.Sh HISTORY
+The
+.Nm
+driver first appeared in
+.Ox 7.1 .
+.Sh AUTHORS
+.An -nosplit
+The
+.Nm
+driver was written by
+.An Klemens Nanni Aq Mt k...@openbsd.org .
blob - 809ece860c07df596da208638f2f3facc829cb72
blob + 0ceac9b6159e5cfe43fc4e601274100df1c40ffa
--- sys/arch/arm64/conf/GENERIC
+++ sys/arch/arm64/conf/GENERIC
@@ -131,8 +131,9 @@ amdgpu* at pci?
 drm*   at amdgpu?
 wsdisplay* at amdgpu?
 
-gpioleds*  at fdt?
 gpiocharger*   at fdt?
+gpiokeys*  at fdt?
+gpioleds*  at fdt?
 
 # Apple
 apldart*   at fdt?
blob - 301500e9b0c6501be4d55feb5135ca223d6337cc
blob + 3d73e22edf7802172b29a26cb8b503eaeb8f3aa9
--- sys/dev/fdt/files.fdt
+++ sys/dev/fdt/files.fdt
@@ -589,10 +589,14 @@ devicedapmic
 attach dapmic at i2c
 file   dev/fdt/dapmic.cdapmic
 
-device gpioleds
-attach gpioleds at fdt
-file   dev/fdt/gpioleds.c  gpioleds
-
 device gpiocharger
 attach gpiocharger at fdt
 file   dev/fdt/gpiocharger.c   gpiocharger
+
+device gpioleds
+attach gpioleds at fdt
+file   dev/fdt/gpioleds.c  gpioleds
+
+device gpiokeys
+attach gpiokeys at fdt
+file   dev/fdt/gpiokeys.c  gpiokeys
blob - /dev/null
blob + 4b4ca55a5c825ad8d66fbc8ec198bbcd13352b7c (mode 644)
--- /dev/null
+++ sys/dev/fdt/gpiokeys.c
@@ -0,0 +1,179 @@
+/* $OpenBSD: $ */
+/*
+ * Copyright (c) 2021 Klemens Nanni 
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIR

libcrypto: add OID for RPKI ASPA objects

2021-11-09 Thread Job Snijders 
IANA made a permanent registration in the SMI Security for S/MIME CMS
Content Type registry at
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-1
for signed objects conforming to draft-ietf-sidrops-aspa-profile

OK?

Kind regards,

Job

Index: obj_mac.num
===
RCS file: /cvs/src/lib/libcrypto/objects/obj_mac.num,v
retrieving revision 1.27
diff -u -p -r1.27 obj_mac.num
--- obj_mac.num 26 Oct 2021 17:35:38 -  1.27
+++ obj_mac.num 9 Nov 2021 15:33:09 -
@@ -1014,3 +1014,4 @@ id_ct_geofeedCSVwithCRLF  1013
 id_ct_signedChecklist  1014
 id_kp_bgpsec_router1015
 tlsfeature 1016
+id_ct_ASPA 1017
Index: objects.txt
===
RCS file: /cvs/src/lib/libcrypto/objects/objects.txt,v
retrieving revision 1.33
diff -u -p -r1.33 objects.txt
--- objects.txt 26 Oct 2021 17:35:38 -  1.33
+++ objects.txt 9 Nov 2021 15:33:09 -
@@ -264,6 +264,7 @@ id-smime-ct 35  : id-ct-rpkiGhostbusters
 id-smime-ct 36 : id-ct-resourceTaggedAttest
 id-smime-ct 47 : id-ct-geofeedCSVwithCRLF
 id-smime-ct 48 : id-ct-signedChecklist
+id-smime-ct 49 : id-ct-ASPA
 
 # S/MIME Attributes
 id-smime-aa 1  : id-smime-aa-receiptRequest

Add missing .Dv in termios(4)

2021-11-09 Thread Simon Branch 
Simple change to format this sentence correctly in non-terminal
environments.

diff --git share/man/man4/termios.4 share/man/man4/termios.4
index dfb7609dd6f..89818ca46c2 100644
--- share/man/man4/termios.4
+++ share/man/man4/termios.4
@@ -1011,7 +1011,7 @@ overflowing the input queue.
 The precise conditions under which
 .Dv STOP
 and
-START
+.Dv START
 characters are transmitted are implementation defined.
 .Pp
 If

Re: net80211: use BSS load information when choosing access point

2021-11-09 Thread Sergey Ryazanov 
Hello Stefan,

sorry for the late reply, find my comments below.

On Wed, Nov 3, 2021 at 4:47 PM Stefan Sperling  wrote:
> On Wed, Nov 03, 2021 at 04:03:08PM +0300, Sergey Ryazanov wrote:
>> This topic was discussed a couple of weeks ago on the hostapd mailing
>> list (http://lists.infradead.org/pipermail/hostap/2021-October/039961.html).
>> And Jouni Malinen provide a few concerns about switching to the QBSS
>> load IE usage. I would like to quote him:
>>
>>> I would also point out that at least the last time I did some testing
>>> between vendor implementations, the reported values were completely
>>> different between two APs on the same channel in more or less the same
>>> location in the test setup.. In other words, I would not place much, if
>>> any, trust in this value being something that could be compared between
>>> two different APs. The only thing that seemed to be more or less
>>> comparable was the values from the same AP device in a sense that the
>>> channel load value increased when there was more traffic on the
>>> channel..
>>
>> So I do not think that the complete switching to the BSS load metric
>> is a good idea. But utilizing the AP assistance in the BSS selection
>> procedure sounds nice.
>
> My patch ignores RSSI on purpose in case BSS load is advertised precisely
> because we need to figure out whether "channel load" is indicated reliably.
> The standard doesn't really go into much detail about how to decide whether
> a channel is "busy". It suggests that either virtual or physical carrier
> sense could be used. I guess just letting any faint but valid wifi signal
> block the channel would be a bad idea. So vendors may need to use some
> threshold to decide whether a given signal is actually keeping the channel
> busy in the vicinity of the AP. As with RSSI, measurements of such physical
> quantities could differ between any two given APs and between moments in
> time for a single AP.
>
> If channel load is not a reliable indicator I would hope vendors are at
> least able to reliably count and report the number of associated stations?

The number of associated stations is a comparable metric. But it
provides no information about the channel utilization. Consider two
APs: one with 10 associated but idle smartphones and one with two
laptops that receive a 20 mbit/s video stream each. It is better to
connect to the first AP with the idle channel, but the stations number
metric directs us to quite loaded AP.

--
Sergey

rpki-client 7.5 has just been released

2021-11-09 Thread Sebastian Benoit 
rpki-client 7.5 has just been released and will be available in the
rpki-client directory of any OpenBSD mirror soon.

rpki-client is a FREE, easy-to-use implementation of the Resource
Public Key Infrastructure (RPKI) for Relying Parties (RP) to
facilitate validation of a BGP announcement. The program queries the
global RPKI repository system and outputs validated ROA payloads in
the configuration format of OpenBGPD, BIRD, and also as CSV or JSON
objects for consumption by other routing stacks.

See RFC 6811 for a description of how BGP Prefix Origin Validation
secures the Internet's global routing system.

rpki-client was primarily developed by Kristaps Dzonsons, Claudio
Jeker, Job Snijders, Theo Buehler, Theo de Raadt and Sebastian Benoit
as part of the OpenBSD Project.

This release includes the following changes to the previous release:

* Make rpki-client more resilient regarding untrusted input:
  - fail repository synchronisation after 15min runtime
  - limit the number of repositories per TAL
  - don't allow DOCTYPE definitions in RRDP XML files
  - fix detection of HTTP redirect loops.
* limit the number of concurrent rsync processes.
* fix CRLF in tal files.

rpki-client works on all operating systems with a libcrypto library
based on OpenSSL 1.1 or LibreSSL 3.3, and a libtls library compatible
with LibreSSL 3.3 or later.

rpki-client is known to compile and run on at least the following
operating systems: Alpine, CentOS, Debian, Fedora, FreeBSD, Red Hat,
Rocky, Ubuntu, macOS, and of course OpenBSD!

It is our hope that packagers take interest and help adapt
rpki-client-portable to more distributions.

The mirrors where rpki-client can be found are on
https://www.rpki-client.org/portable.html

Reporting Bugs:
===

General bugs may be reported to tech@openbsd.org

Portable bugs may be filed at
https://github.com/rpki-client/rpki-client-portable

We welcome feedback and improvements from the broader community.
Thanks to all of the contributors who helped make this release
possible.

Assistance to coordinate security issues is available via
secur...@openbsd.org.

OpenBSD Errata: November 9, 2021 (rpki-client)

2021-11-09 Thread Sebastian Benoit 
An errata patch for rpki-client has been released for OpenBSD 6.9 and
OpenBSD 7.0.

rpki-client(8) should handle CA misbehaviours as soft-errors.

Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility.  Source code patches can be found on the
respective errata page:

  https://www.openbsd.org/errata69.html
  https://www.openbsd.org/errata70.html

Switch LibreSSL to use

2021-11-09 Thread Brent Cook 
This switches libcrypto and libssl to use endian.h over
machine/endian.h, easing some portability contortions. The Austin group
works in mysterious ways, but endian.h also might be a POSIX
standard in the wings, whatever 'Applied' means.
https://www.austingroupbugs.net/view.php?id=162

ok?

diff --git a/src/lib/libcrypto/bn/bn_nist.c b/src/lib/libcrypto/bn/bn_nist.c
index b16584d6b9..4e98adfc8e 100644
--- a/src/lib/libcrypto/bn/bn_nist.c
+++ b/src/lib/libcrypto/bn/bn_nist.c
@@ -56,8 +56,7 @@
  *
  */
 
-#include 
-
+#include 
 #include 
 #include 
 
diff --git a/src/lib/libcrypto/des/cfb_enc.c b/src/lib/libcrypto/des/cfb_enc.c
index 59a3e71862..84a71bf52e 100644
--- a/src/lib/libcrypto/des/cfb_enc.c
+++ b/src/lib/libcrypto/des/cfb_enc.c
@@ -57,7 +57,7 @@
  */
 
 #include "des_locl.h"
-#include 
+#include 
 
 /* The input and output are loaded in multiples of 8 bits.
  * What this means is that if you hame numbits=12 and length=2
diff --git a/src/lib/libcrypto/gost/gost2814789.c 
b/src/lib/libcrypto/gost/gost2814789.c
index f1066f2467..c3d0754339 100644
--- a/src/lib/libcrypto/gost/gost2814789.c
+++ b/src/lib/libcrypto/gost/gost2814789.c
@@ -49,8 +49,7 @@
  * 
  */
 
-#include 
-
+#include 
 #include 
 
 #include 
diff --git a/src/lib/libcrypto/gost/streebog.c 
b/src/lib/libcrypto/gost/streebog.c
index 61bce0e32c..c0b2006cd4 100644
--- a/src/lib/libcrypto/gost/streebog.c
+++ b/src/lib/libcrypto/gost/streebog.c
@@ -49,8 +49,7 @@
  * 
  */
 
-#include 
-
+#include 
 #include 
 #include 
 
diff --git a/src/lib/libcrypto/modes/modes_lcl.h 
b/src/lib/libcrypto/modes/modes_lcl.h
index f8830e4deb..0d2541c49f 100644
--- a/src/lib/libcrypto/modes/modes_lcl.h
+++ b/src/lib/libcrypto/modes/modes_lcl.h
@@ -6,7 +6,7 @@
  * 
  */
 
-#include 
+#include 
 
 #include 
 
diff --git a/src/lib/libcrypto/modes/xts128.c b/src/lib/libcrypto/modes/xts128.c
index 0be23d4ea9..e4a89dc77b 100644
--- a/src/lib/libcrypto/modes/xts128.c
+++ b/src/lib/libcrypto/modes/xts128.c
@@ -48,9 +48,10 @@
  * 
  */
 
-#include 
 #include 
 #include "modes_lcl.h"
+
+#include 
 #include 
 
 #ifndef MODES_DEBUG
diff --git a/src/lib/libcrypto/rc4/rc4_enc.c b/src/lib/libcrypto/rc4/rc4_enc.c
index bd928b58c9..87223140bc 100644
--- a/src/lib/libcrypto/rc4/rc4_enc.c
+++ b/src/lib/libcrypto/rc4/rc4_enc.c
@@ -56,7 +56,8 @@
  * [including the GNU Public Licence.]
  */
 
-#include 
+#include 
+
 #include 
 #include "rc4_locl.h"
 
diff --git a/src/lib/libcrypto/sha/sha256.c b/src/lib/libcrypto/sha/sha256.c
index 9c05d3b0f8..632ebb9070 100644
--- a/src/lib/libcrypto/sha/sha256.c
+++ b/src/lib/libcrypto/sha/sha256.c
@@ -9,8 +9,7 @@
 
 #if !defined(OPENSSL_NO_SHA) && !defined(OPENSSL_NO_SHA256)
 
-#include 
-
+#include 
 #include 
 #include 
 
diff --git a/src/lib/libcrypto/sha/sha512.c b/src/lib/libcrypto/sha/sha512.c
index 6b95cfa72e..3752aa02fe 100644
--- a/src/lib/libcrypto/sha/sha512.c
+++ b/src/lib/libcrypto/sha/sha512.c
@@ -5,8 +5,7 @@
  * 
  */
 
-#include 
-
+#include 
 #include 
 #include 
 
diff --git a/src/lib/libcrypto/sha/sha_locl.h b/src/lib/libcrypto/sha/sha_locl.h
index 46c9a39be2..07d4d2d39a 100644
--- a/src/lib/libcrypto/sha/sha_locl.h
+++ b/src/lib/libcrypto/sha/sha_locl.h
@@ -186,7 +186,7 @@ int SHA1_Init(SHA_CTX *c)
 #endif
 
 #if !defined(SHA1_ASM)
-#include 
+#include 
 static void HASH_BLOCK_DATA_ORDER (SHA_CTX *c, const void *p, size_t num)
{
const unsigned char *data=p;
diff --git a/src/lib/libcrypto/whrlpool/wp_block.c 
b/src/lib/libcrypto/whrlpool/wp_block.c
index 1e00a01330..1ab8630ecd 100644
--- a/src/lib/libcrypto/whrlpool/wp_block.c
+++ b/src/lib/libcrypto/whrlpool/wp_block.c
@@ -36,9 +36,9 @@
  *
  */
 
+#include 
 #include 
 #include 
-#include 
 
 #include "wp_locl.h"
 
diff --git a/src/lib/libssl/d1_pkt.c b/src/lib/libssl/d1_pkt.c
index f0f393b0fd..98353e7a1a 100644
--- a/src/lib/libssl/d1_pkt.c
+++ b/src/lib/libssl/d1_pkt.c
@@ -113,8 +113,7 @@
  * [including the GNU Public Licence.]
  */
 
-#include 
-
+#include 
 #include 
 #include

Re: add 802.11n 40MHz support to iwn(4)

2021-11-09 Thread Stefan Sperling 
On Mon, Nov 01, 2021 at 12:56:26PM +0100, Stefan Sperling wrote:
> I have tested on a 6205 device. More tests are needed, especially on
> the old 4965AGN generation because those chips require the driver to
> do specific calibration work which newer chips perform in firmware.
> I suspect you will find 4965 devices in older thinkpads which first
> introduced 11n wifi to these laptops (the x60/x61 generation probably).

Does nobody have a 4965AGN device anymore?

The patch is in snaps, so a simple upgrade to the latest snapshot
would be sufficient to test this. Thanks!

ipsec ip deliver

2021-11-09 Thread Alexander Bluhm 
Hi,

Do not call ip_deliver() recursively.  As we have no crypto task
anymore, we can return the next protocol.  Then ip_deliver() will
walk the header chain in its loop.

ok?

bluhm

Index: netinet/ip_ah.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_ah.c,v
retrieving revision 1.165
diff -u -p -r1.165 ip_ah.c
--- netinet/ip_ah.c 25 Oct 2021 09:47:02 -  1.165
+++ netinet/ip_ah.c 1 Nov 2021 09:21:14 -
@@ -563,21 +563,18 @@ ah_input(struct mbuf **mp, struct tdb *t
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_wrap);
-   error = ENOBUFS;
goto drop;
case 2:
DPRINTF("old packet received in SA %s/%08x",
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_replay);
-   error = ENOBUFS;
goto drop;
case 3:
DPRINTF("duplicate packet received in SA %s/%08x",
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_replay);
-   error = ENOBUFS;
goto drop;
default:
DPRINTF("bogus value from checkreplaywindow() "
@@ -585,7 +582,6 @@ ah_input(struct mbuf **mp, struct tdb *t
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_replay);
-   error = ENOBUFS;
goto drop;
}
}
@@ -597,7 +593,6 @@ ah_input(struct mbuf **mp, struct tdb *t
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_badauthl);
-   error = EACCES;
goto drop;
}
if (skip + ahx->authsize + rplen > m->m_pkthdr.len) {
@@ -607,7 +602,6 @@ ah_input(struct mbuf **mp, struct tdb *t
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_badauthl);
-   error = EACCES;
goto drop;
}
 
@@ -622,7 +616,6 @@ ah_input(struct mbuf **mp, struct tdb *t
tdb->tdb_cur_bytes >= tdb->tdb_exp_bytes) {
pfkeyv2_expire(tdb, SADB_EXT_LIFETIME_HARD);
tdb_delete(tdb);
-   error = ENXIO;
goto drop;
}
 
@@ -638,7 +631,6 @@ ah_input(struct mbuf **mp, struct tdb *t
if (crp == NULL) {
DPRINTF("failed to acquire crypto descriptors");
ahstat_inc(ahs_crypto);
-   error = ENOBUFS;
goto drop;
}
 
@@ -664,7 +656,6 @@ ah_input(struct mbuf **mp, struct tdb *t
if (ptr == NULL) {
DPRINTF("failed to allocate buffer");
ahstat_inc(ahs_crypto);
-   error = ENOBUFS;
goto drop;
}
 
@@ -720,7 +711,6 @@ ah_input(struct mbuf **mp, struct tdb *t
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_badauth);
-   error = -1;
goto drop;
}
 
@@ -750,21 +740,18 @@ ah_input(struct mbuf **mp, struct tdb *t
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_wrap);
-   error = -1;
goto drop;
case 2:
DPRINTF("old packet received in SA %s/%08x",
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_replay);
-   error = -1;
goto drop;
case 3:
DPRINTF("duplicate packet received in SA %s/%08x",
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_replay);
-   error = -1;
goto drop;
default:
DPRINTF("bogus value from checkreplaywindow() "
@@ -772,7 +759,6 @@ ah_input(struct mbuf **mp, struct tdb *t
ipsp_address(&tdb->tdb_dst, buf, sizeof(buf)),
ntohl(tdb->tdb_spi));
ahstat_inc(ahs_replay);
-   error = -1;

Re: rpki-client: increase MAX_FILE_SIZE to accommodate key rollovers

2021-11-09 Thread Job Snijders 
On Tue, Nov 09, 2021 at 12:12:42PM +0100, Theo Buehler wrote:
> I'm ok with that. Maybe we should bump even higher, say 8M? Isn't the
> main point to have a limit at all? I don't think it needs to be very
> tight.

I think it is best to bump the limits to accommodate real world
observations. 8 MB objects are likely to require multiple minutes of
compute time to decode and marshall around. I'm inclined towards
frugality :-) 

Kind regards,

Job

Re: rpki-client: increase MAX_FILE_SIZE to accommodate key rollovers

2021-11-09 Thread Theo Buehler 
On Tue, Nov 09, 2021 at 11:03:14AM +, Job Snijders wrote:
> Hi all,
> 
> Ties de Kock reported that the RIPE NCC Production CA's manifest is
> likely to double in size during RFC 6489 key rollover events. Both old
> and new entries will be listed. KpSo3VVK5wEHIJnHC2QHVV3d5mk.mft
> currently is 1.1 MB.
> 
> OK?

I'm ok with that. Maybe we should bump even higher, say 8M? Isn't the
main point to have a limit at all? I don't think it needs to be very
tight.

> 
> Kind regards,
> 
> Job
> 
> Index: extern.h
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
> retrieving revision 1.94
> diff -u -p -r1.94 extern.h
> --- extern.h  5 Nov 2021 10:50:41 -   1.94
> +++ extern.h  9 Nov 2021 10:55:40 -
> @@ -609,7 +609,7 @@ int   mkpath(const char *);
>  #define MAX_URI_LENGTH   2048
>  
>  /* Maximum acceptable file size */
> -#define MAX_FILE_SIZE200
> +#define MAX_FILE_SIZE400
>  
>  /* Maximum number of FileAndHash entries per manifest. */
>  #define MAX_MANIFEST_ENTRIES 10
>

rpki-client: increase MAX_FILE_SIZE to accommodate key rollovers

2021-11-09 Thread Job Snijders 
Hi all,

Ties de Kock reported that the RIPE NCC Production CA's manifest is
likely to double in size during RFC 6489 key rollover events. Both old
and new entries will be listed. KpSo3VVK5wEHIJnHC2QHVV3d5mk.mft
currently is 1.1 MB.

OK?

Kind regards,

Job

Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.94
diff -u -p -r1.94 extern.h
--- extern.h5 Nov 2021 10:50:41 -   1.94
+++ extern.h9 Nov 2021 10:55:40 -
@@ -609,7 +609,7 @@ int mkpath(const char *);
 #define MAX_URI_LENGTH 2048
 
 /* Maximum acceptable file size */
-#define MAX_FILE_SIZE  200
+#define MAX_FILE_SIZE  400
 
 /* Maximum number of FileAndHash entries per manifest. */
 #define MAX_MANIFEST_ENTRIES   10