home tags events about rss login

Things happen.

horia honked 07 May 2024 06:12 -0700

Voulez-vous café avec moi ?

horia bonked 06 May 2024 13:19 -0700
original: solene@bsd.network

I'm proud and happy to announce the first release of my project openbsd-check-outdated

It is a shell script scanning your installed packages and check on repology if a newer version exists.

https://git.sr.ht/~solene/openbsd-check-outdated

You need a checkout of the ports tree, jq and curl to make it work.

I wrote it because I prefer to update packages I actually use than random packages I don't care about.

#openbsd

horia bonked 05 May 2024 22:02 -0700
original: tedu@honk.tedunangst.com

If you've ever tried using the honk admin screen, well, first of all, I'm very sorry, but it's been rewritten to maybe only half as bad, and in a state that allows for future improvement.

horia bonked 04 May 2024 03:02 -0700
original: solene@bsd.network

Vous aimez #OpenBSD et vous êtes francophone ?

Après l'arrêt de la communauté obsd4a, nous n'avions plus de lieu pour discuter de notre système favoris dans la langue de Molière.

Je vous annonce le lancement d'un forum francophone afin de nous réunir à nouveau.

https://fr.forum.puffy.cafe/

Merci l'ami @prx pour l'hébergement et pour toujours se laisser embarquer dans mes idées folles

horia bonked 03 May 2024 05:02 -0700
original: cynicalsecurity@bsd.network

OpenBSD 7.5, PF misbehaving & interfaces going mad

OpenBSD 7.5, PF misbehaving & interfaces going mad

This is a bizarre problem which I have been trying to debug since Monday.

Three firewalls in one data centre - one old (for ref. Mk.II) and two new (for ref. Mk, IV) - the main difference between Mk. II and Mk. IV is the NICs - Mk. II has 4x 1G Intel 82571EB and 4x Intel 82574L, Mk. IV has 2x 10G Intel X550T and 8x 10G Intel X710-T4.

All running OpenBSD 7.5, the Mk. IVs "fresh", the Mk.II updated over the years.

Migrated on Monday from the Mk. II to the Mk. IVs and after a few hours one of the interfaces suddenly exploded with output errors, the machine load went through the roof (imagine BIND9 receiving DNS requests over UDP and then replying but the replies never get to the machine asking… guaranteed DoS).

We went through a reboot, happened again, so suspected cable / hardware.

Remote hands, change cable and add an additional cable from a spare port to a new one.

Bring the firewall back up "clean" (i.e. reboot) - same thing happens (i.e. not the cable), so we switch port suspecting a hardware failure (note: these as 2x quad cards so we picked a spare port in the other quad card from the one failing).

Give it a bit of time (and packets) and the same things happens.

OK, decision time, we bring back the Mk. II from retirement (fortunately we had not un-racked it) on Tuesday evening (yes, it took us two days to debug, in prod. of course¹).

The Mk. IV works happily for a few days until literally an hour ago it went berserk like the Mk. IVs!

Now, a little extra detail:

* there are IPsec tunnels between various locations with GIF running "inside" them,
* there is OSPF across these links for routing.

This is where it gets weirder - looking at the PF logs I see:

May 02 14:18:19.262428 rule 7/(match) block out on em0: 10.255.180.3.500 > 10.255.200.2.500: isakmp v2.0 exchange INFORMATIONAL
cookie: 00bac996245f9c4d->f81187b0e2e427d7 msgid: 00000000 len: 57

but… PF config has (vpls is the group corresponding to em0):

pass quick on vpls

__
¹ there are another four Mk. IVs in prod elsewhere without the slightest issue, running the same configuration and PF ruleset.

horia bonked 03 May 2024 04:40 -0700
original: mpts@mastodon.social

Version 7.4.2024.01.15-p1 of #FreeBSD #relayd has just been released and is available in the FreeBSD Ports tree:

https://cgit.freebsd.org/ports/commit/?id=a66b8f6102fe56d83583db9f4041f3e7fa6c1ba9

One of the interesting changes is fix for a crash that can be triggered by a config reload. The commit message contains a nice write-up:

https://github.com/KlaraSystems/freebsd-relayd/pull/1/commits/cc381fdfa454a9b24c0a061602f2ef25472d06e2

We are working on getting the fix upstreamed to #OpenBSD. Here's the bug report if you want to take a look:

https://marc.info/?l=openbsd-bugs&m=171288115606488&w=2

#opensource #osdev #CFT #foss