We have released OpenIKED 7.0, which will be arriving in the
OpenIKED directory of your local OpenBSD mirror soon.
This release includes the following changes to the previous release:
* Added client-side support for DNS configuration via
OpenBSD resolvd(8) and systemd-resolved(8)
* Added
Remi Locherer(remi.loche...@relo.ch) on 2021.11.03 22:23:44 +0100:
> On Tue, Nov 02, 2021 at 05:27:11PM +, Stuart Henderson wrote:
> > I've recently started seeing a number of flaps with ospfd/ospf6d
> > with invalid seq nums / "seq num mismatch, bad flags" logged.
> > Not quite sure what's goi
On Tue, Nov 02, 2021 at 05:27:11PM +, Stuart Henderson wrote:
> I've recently started seeing a number of flaps with ospfd/ospf6d
> with invalid seq nums / "seq num mismatch, bad flags" logged.
> Not quite sure what's going yet as they must be occurring on
> various local switched segments on on
On Wed, Nov 03, 2021 at 12:41:52PM -0600, Theo de Raadt wrote:
> + size_t talid; /* covered by which TAL */
>
> You shouldn't use size_t
>
> It is 32bit on ILP32 systems, and 64bit on I32LP64 machines, because the
> underlying definition is:
>
> _types.h:typedefunsigned l
Some device trees such as on my Raspberry Pi 4b use the deprecated
"label" property rather than "function".
Fall back to it such that LEDs won't be skipped:
-gpioleds0 at mainbus0: no LEDs
+gpioleds0 at mainbus0: "led0", "led1"
OK?
Index: gpioleds.c
=
+ size_t talid; /* covered by which TAL */
You shouldn't use size_t
It is 32bit on ILP32 systems, and 64bit on I32LP64 machines, because the
underlying definition is:
_types.h:typedefunsigned long __size_t;
So suspect you want to use int or u_int.
This diff changes how the certs and roa track the tal that covers them.
Instead of passing strings around use ids and a simple lookup table
for the description. This will make it possible to add tal ids to more
things.
Usual test run works and the output for openbgpd and json look sane.
--
:wq Cl
On Wed, Nov 03, 2021 at 06:48:51PM +0100, Theo Buehler wrote:
> On Wed, Nov 03, 2021 at 06:34:05PM +0100, Claudio Jeker wrote:
> > Fix CRLF handling by properly setting nl to the right NUL byte.
> > In the CRLF case both \r\n are replaced by \0 and so the code
> > needs to adjust the nl pointer els
Hmm.
Stop using apmd, and run
systat sens 1
And watch to see what happens to the various sensors.
This will show you everything.
Nicola Dell'Uomo wrote:
> Battery self test is okay and my laptop has just 1 year of life (X1 carbon
> 8th gen).
> The problem replicated just now after a sy
On Wed, Nov 03, 2021 at 06:34:05PM +0100, Claudio Jeker wrote:
> Fix CRLF handling by properly setting nl to the right NUL byte.
> In the CRLF case both \r\n are replaced by \0 and so the code
> needs to adjust the nl pointer else valid_url() and the check for .cer
> endings fail.
It feels odd to
Fix CRLF handling by properly setting nl to the right NUL byte.
In the CRLF case both \r\n are replaced by \0 and so the code
needs to adjust the nl pointer else valid_url() and the check for .cer
endings fail.
This diff fixes the test.tal I added to regress.
--
:wq Claudio
Index: tal.c
It looks like your battery is failing.
Nicola Dell'Uomo wrote:
> I've been experiencing odd power management behavior since some days: my
> laptop goes to suspend and I didn't know why.
> Today I looked at /var/messages and I found this out:
> [snip]
> Nov 3 15:04:20 puffy apmd: system resumed
Don't become a fork bomb. Limit the number of processes by stopping to
poll for new jobs once the limit is reached. I set the limit to 16 which
is larger then the biggest concurrency I have seen during fetches.
OK?
--
:wq Claudio
Index: extern.h
==
On Wed, Nov 03, 2021 at 11:55:41AM +, Stuart Henderson wrote:
> On 2021/11/03 05:47, Crystal Kolipe wrote:
> > > 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), P
On Wed, Nov 03, 2021 at 04:03:08PM +0300, Sergey Ryazanov wrote:
> Hello Stefan,
>
> On Sun, Oct 31, 2021 at 9:25 PM Stefan Sperling wrote:
> > Some access points advertise BSS load information in beacons in
> > order to help clients make informed roaming decisions.
> >
> > BSS load information i
On Tue, Nov 02, 2021 at 12:26:15PM -0600, Theo de Raadt wrote:
> 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, until an interrupt happens. And thus, save
> power. That
Hello Stefan,
On Sun, Oct 31, 2021 at 9:25 PM Stefan Sperling wrote:
> Some access points advertise BSS load information in beacons in
> order to help clients make informed roaming decisions.
>
> BSS load information includes the number of associated stations,
> the channel utilization (this take
In one place this is already done but this makes sure we show the bad
attribute in all cases where a non conforming attribute is found.
OK?
--
:wq Claudio
Index: rrdp_delta.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/rrdp_delta.c,
On 2021/11/03 05:47, Crystal Kolipe wrote:
> > 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, th
Noticed by accident. The chunked encoding only works for chunks smaller
than 32k (the HTTP internal read buffer). For chunks bigger than 32k the
state machine jumps too early (after the first write of 32k) into the
STATE_RESPONSE_CHUNKED_TRAILER state and so everything gets confused.
Fix is simple
Le 03/11/2021 à 07:45, Anton Lindqvist a écrit :
Hi,
Upon uhidev detach, free the list of sub devices.
Comments? OK?
diff --git sys/dev/usb/uhidev.c sys/dev/usb/uhidev.c
index 014dc052c1c..5fe2f702e21 100644
--- sys/dev/usb/uhidev.c
+++ sys/dev/usb/uhidev.c
@@ -451,6 +451,7 @@ uhidev_detach(str
On Tue, Nov 02, 2021 at 12:30:56PM -0600, Theo de Raadt 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 significa
On Tue, Nov 02, 2021 at 11:47:33PM +, Klemens Nanni wrote:
> No idea what it was supposed to do back then; cvs blame points at
>
> revision 1.19
> date: 1998/09/03 06:24:18; author: jason; state: Exp; lines: +502
> -38;
> o OpenBSD gets if_media support (from NetBSD)
>
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 repor
On Wed, Nov 03, 2021 at 02:55:11PM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> On Tue, 2 Nov 2021 07:03:43 +
> Jason McIntyre wrote:
> > On Tue, Nov 02, 2021 at 12:02:07PM +0900, YASUOKA Masahiko wrote:
> >> I'd like to clarify "aes" in ipsec.conf accepts 128:256 bits.
> >>
> >> sbin/ipsecctl/i
On Wed, 3 Nov 2021, Stuart Henderson wrote:
> > See also https://en.wikichip.org/wiki/race-to-sleep - it's generally
> > more energy efficient to run the CPU at full speed so it can finish its
> > work faster and get back to a low-power state sooner
>
> So there's not really any point in doing th
On 2021/11/03 16:46, Damien Miller wrote:
> On Tue, 2 Nov 2021, Theo de Raadt 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 u
On 2021/11/02 23:47, Klemens Nanni wrote:
> No idea what it was supposed to do back then; cvs blame points at
ha, that's Jason's username for various places
it's obviously not needed, but it's tempting to keep it for historical
interest!
> OK?
>
> Index: ifconfig.c
> ==
On Tue, Nov 02, 2021 at 12:30:56PM -0600, Theo de Raadt 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 significa
On Wed, Nov 03, 2021 at 02:55:11PM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> On Tue, 2 Nov 2021 07:03:43 +
> Jason McIntyre wrote:
> > On Tue, Nov 02, 2021 at 12:02:07PM +0900, YASUOKA Masahiko wrote:
> >> I'd like to clarify "aes" in ipsec.conf accepts 128:256 bits.
> >>
> >> sbin/ipsecctl/i
30 matches
Mail list logo
