On Fri, Mar 08, 2024 at 02:47:44PM +1100, Jonathan Gray wrote:
> On Fri, Mar 08, 2024 at 03:35:31PM +1300, Avon Robertson wrote:
> > Theo
> >
> > Alas your suggestion failed as show below.
> >
> > >From a cold boot using:
> >
> > * using a USB keyboard the machine responds to:
> > boot> boot
On Fri, Mar 08, 2024 at 03:35:31PM +1300, Avon Robertson wrote:
> Theo
>
> Alas your suggestion failed as show below.
>
> >From a cold boot using:
>
> * using a USB keyboard the machine responds to:
> boot> boot -c
> and then at
> UKC> there is no displayed response to any keypress and
Theo
Alas your suggestion failed as show below.
>From a cold boot using:
* using a USB keyboard the machine responds to:
boot> boot -c
and then at
UKC> there is no displayed response to any keypress and the machine
appears to have hung.
Timed roughly with a wristwatch, >10
Moin,
On Sat, 2024-01-27 at 16:54 +0100, Theo Buehler wrote:
> This should be fixed with
>
> https://cvsweb.openbsd.org/src/lib/libssl/tls13_legacy.c#rev1.43
>
> which you should be able to backport to 7.4 without issues if you
> don't want to use current.
Took me longer than i wanted to to
Moin,
ok, had a hunch, and i think i got closer to this. I can now semi-
reproduce this in a lab environment. with six OpenBSD 7.4. I guess the
last missing component is bringing in a Linux router, i.e., in a pure
openbsd setup it is not that bad because openbsd does not send type 2
ad infinum
I have a new install on a Rock5b (Rockchip RK3588 based) where the disk
subsystem appears to be unstable and locking up. Under heavy load using
dpb(1) building ports, I have had the storage appear to get stuck on inode
locks. It takes about an hour or two to reproduce but is reproduceable.
When
On Wed, Mar 06, 2024 at 11:29:52PM -0700, Theo de Raadt wrote:
> You can try booting with:
>
> boot -c
>
> > disable amdgpu0
> > quit
>
> That will probably put you into boring vga graphics, you can compile, and
> test quickly.
>
>
> Avon Robertson wrote:
>
> > On Thu, Mar 07, 2024 at
Moin
> How does the route look like where the path MTU is saved?
> netstat -rn has a Mtu column.
Just noticed i sent route -n -T0 get instead of netstat -rn;
gw02.dus01.as59645.net ~ # route -T0 exec netstat -rn | grep
2a06:d1c0::b
2a06:d1c0::b/128
Moin,
> Note that I have also written some scapy script to test path MTU
> discovery. /usr/src/regress/sys/netinet/pmtu/tcp_connect.py
> and tcp_connect6.py
> Sometimes these tests fail, so PMTU may have bugs. Or my tests are
> just unreliable.
Awesome, thanks!
> How does the route look like
Hi,
Thanks for the detailed bug report.
Note that I have also written some scapy script to test path MTU
discovery. /usr/src/regress/sys/netinet/pmtu/tcp_connect.py
and tcp_connect6.py
Sometimes these tests fail, so PMTU may have bugs. Or my tests are
just unreliable.
How does the route look
Moin,
I have run into some issues with v6 PMTUD on OpenBSD 7.4, and am
somewhat at a loss on how to proceed finding a proper reproducer.
I first brushed into MTU issues when some of my mailers suddenly
started to put out ~50mbit of traffic with no apparent reason. Back
then further debugging
Hi Vitaliy
We still didn't have opportunity to test this. As soon as we can we will test
it and let you know.
Srdačan pozdrav / Best regards
--
Nemanja Domazetović
Senior IT Network inženjer
Kappa Star Group,
Bulevar kneza Aleksandra Karađorđevića 36,
11000 Beograd,
Srbija
e-mail:
On Tue, Mar 05, 2024 at 11:31:40AM +0300, Vitaliy Makkoveev wrote:
>
> I suspect the races with wg_peer_destroy().
>
Does this diff help?
Index: sys/dev/dt/dt_prov_static.c
===
RCS file: /cvs/src/sys/dev/dt/dt_prov_static.c,v
13 matches
Mail list logo
