7.4 panic ip_output no HDR

[Kapetanakis Giannis]

Hi,

This is the 2nd panic I get on this machine after 7.4, both the same, 
ip_output() from pflow_output_process()

ddb{0}> show panic
*cpu0: ip_output no HDR

ddb{0}> trace
db_enter() at db_enter+0x14
panic(820bea35) at panic+0xc3
ip_output(fd80b320ad00,0,fd8120670c48,0,0,fd8120670bd0,5718952b04ba
576d) at ip_output+0xa26
udp_output(fd8120670bd0,fd80b320ad00,fd80bd64a600,0) at udp_output+
0x3be
sosend(fd8120671720,fd80bd64a600,0,fd80b320ad00,0,0) at sosend+0x37
f
pflow_output_process(80875000) at pflow_output_process+0x67
taskq_thread(8002e380) at taskq_thread+0x100
end trace frame: 0x0, count: -7

I couldn't continue the debug because "machine ddbcpu 1" completely hanged the 
machine.

It's strange because it's a backup router (bgpd/ospfd) and didn't have any 
traffic at that moment.
Nothing on the logs at the time of panic.

On the last panic I managed to do a ps and got the * at softnet proc 3 if I 
remember correct.

# ifconfig pflow
pflow0: flags=41 mtu 1448
    index 11 priority 0 llprio 3
    pflow: sender: xx.xx.xx.xx receiver: yy.yy.yy.yy: version: 10
    groups: pflow

OpenBSD 7.4 (GENERIC.MP) #0: Sun Oct 22 12:13:42 MDT 2023
    
r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4234805248 (4038MB)
avail mem = 4086726656 (3897MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xbf6c8000 (92 entries)
bios0: vendor FUJITSU // Phoenix Technologies Ltd. version "6.00 Rev. 
1.06.3031" date 12/14/2010
bios0: FUJITSU PRIMERGY RX200 S6
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP TCPA SLIT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT SSDT EINJ HEST BERT SSDT ERST SPCR MCFG HPET APIC BOOT
acpi0: wakeup devices PE0_(S4) PE1_(S4) PE3_(S4) PE7_(S4) PE9_(S4) PE1A(S4) 
USB1(S1) USB2(S1) USB3(S1) USB4(S1) USB5(S1) USB6(S1) USB7(S1) USB8(S1) COM1(S1)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-6
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 32 (boot processor)
cpu0: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.13 MHz, 06-2c-02, patch 
001f
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,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line 
8-way L2 cache, 12MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 1
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 34 (application processor)
cpu1: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.14 MHz, 06-2c-02, patch 
001f
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,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line 
8-way L2 cache, 12MB 64b/line 16-way L3 cache
cpu1: smt 0, core 1, package 1
cpu2 at mainbus0: apid 36 (application processor)
cpu2: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.18 MHz, 06-2c-02, patch 
001f
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,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line 
8-way L2 cache, 12MB 64b/line 16-way L3 cache
cpu2: smt 0, core 2, package 1
cpu3 at mainbus0: apid 48 (application processor)
cpu3: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.22 MHz, 06-2c-02, patch 
001f
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,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line 
8-way L2 cache, 12MB 64b/line 16-way L3 cache
cpu3: smt 0, core 8, package 1
cpu4 at mainbus0: apid 50 (application processor)
cpu4: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.19 MHz, 06-2c-02, patch 
001f
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX

Re: smtpd[68513]: warn: lost processor: spamassassin exited abnormally

[Giovanni Bechis]

On 11/7/23 20:16, Omar Polo wrote:

On 2023/11/07 19:30:43 +0100, Harald Dunkel  wrote:

Hi Omar,

sorry for the delay, but I have good news: The patch seems to
work. Of course I will continue to watch it.

Thanks for verifying!

Before bumping the smtp-filter protocol version I took at look at what
we had in the port tree to know what would break, but this slipped.
apologize.

If it's OK for Giovanni and Joerg I'd like to commit this and backport
to 7.4-stable (same diff tested by Harald, reattaching for convenience.)

[...]

+Index: filter-spamassassin.go
+--- filter-spamassassin.go.orig
 filter-spamassassin.go
+@@ -211,7 +211,7 @@ func run() {
+   for in.Scan() {
+   f := strings.Split(in.Text(), "|")
+   t, ver, ev, sid := f[0], f[1], f[4], f[5]
+-  if (t != "filter" && t != "report") || ver != "0.6" {
++  if (t != "filter" && t != "report") || ver != "0.7" {
+   l3.Err(fmt.Sprintln(sid, "protocol", t, ver))

does this still works with previous protocol versions ?

ok giovanni@ in any case for current and 7.4 since it will be a no-op on 
OpenBSD.
 Cheers
   Giovanni

Re: Typo in faq4.html

[Ingo Schwarze]

Hi Robin,

robin@tilde.institute wrote on Sat, Nov 04, 2023 at 01:18:47PM +:

> In faq4.html, the link to OpenBSD's firmware directory is not working.
> Indeed it is http://firmware.openbsd.org instead of 
> http://firmware.openbsd.org/firmware/ as shown in fw_update(8)'s 
> manpage.

Thank you for reporting the dead link and for mentioning that the
manual page provides a working link.

> Here is a proposed diff.

Committed with minimal tweaks.

It is online now at:

  https://www.openbsd.org/faq/faq4.html#WifiOnly

Yours,
  Ingo


> Index: faq4.html
> ===
> RCS file: /cvs/www/faq/faq4.html,v
> retrieving revision 1.555
> diff -u -p -r1.555 faq4.html
> --- faq4.html 16 Oct 2023 12:52:20 -  1.555
> +++ faq4.html 4 Nov 2023 13:02:43 -
> @@ -512,7 +512,7 @@ a bootable install image with the necess
>  If you don't have an existing OpenBSD system with internet access, use
>  another computer to download the appropriate file from
>  
> -http://firmware.openbsd.org";>firmware.openbsd.org and put
> + href="http://firmware.openbsd.org/firmware/";>firmware.openbsd.org/firmware/
>  and put
>  it on a USB drive that's readable by OpenBSD.
>  Then, on the OpenBSD machine,
>  https://man.openbsd.org/mount";>mount(8) the drive and use

Re: OnLogic Helix 330

[Stefan Sperling]

On Tue, Nov 07, 2023 at 09:17:57PM -, Stuart Henderson wrote:
> On 2023-11-07, Devin Reade  wrote:
> > I recently acquired an OnLogic Helix 330 (see [1] and [2]) and booted
> > the 7.4 install image via USB; no installation yet, no serial console
> > configured yet, no sharable dmesg yet.
> >
> > I have the version with the four network interfaces, based on the
> > J6426.  Dropping to shell from the 7.4 install image, it looks like
> > ony two of the four are detected, via em(4) as I210.  Interestingly,
> > it is the two on the add-on board rather than the two integrated
> > ports, based on the link status in ifconfig(8).
> >
> > The underlying network hardware is a Maxlinear GPY115 per [3].
> > 
> > Booting into Debian 12, all four interfaces are detected.  It looks like
> > support for the GPY115 is relatively new there.
> 
> GPY115 is a PHY, the NIC is dwqe(4), which was only recently supported
> on non-ARM. Try -current before spending any more time on it.

It seems this particular PHY is not yet supported.

At present we are only attaching dwqe to one of several possible MAC
PCI IDs because I don't have other hardware to test on. Help towards
adding support for more devices would be very welcome.

Thinkpad Gets Very Hot

[luffy20201]

Hi, I've been an OpenBSD user for a year now, but I've never been able to 
disable Acpitz. I have tried everything, and nothing has worked. I use a 
Thinkpad X220, and it gets really hot. I need some help with this, can you 
please guys lend a hand? Thank You

Re: OnLogic Helix 330

[Stuart Henderson]

On 2023-11-07, Devin Reade  wrote:
> I recently acquired an OnLogic Helix 330 (see [1] and [2]) and booted
> the 7.4 install image via USB; no installation yet, no serial console
> configured yet, no sharable dmesg yet.
>
> I have the version with the four network interfaces, based on the
> J6426.  Dropping to shell from the 7.4 install image, it looks like
> ony two of the four are detected, via em(4) as I210.  Interestingly,
> it is the two on the add-on board rather than the two integrated
> ports, based on the link status in ifconfig(8).
>
> The underlying network hardware is a Maxlinear GPY115 per [3].
> 
> Booting into Debian 12, all four interfaces are detected.  It looks like
> support for the GPY115 is relatively new there.

GPY115 is a PHY, the NIC is dwqe(4), which was only recently supported
on non-ARM. Try -current before spending any more time on it.

-- 
Please keep replies on the mailing list.

Re: What happened to art4.html

[cat]

> for now

It has been over a year

On November 3, 2023 3:07:14 PM GMT, Christian Weisgerber  
wrote:
>cat:
>
>> I tried to find OpenBSD's official branding art (not the release poster art 
>> or anything) and I couldn't find it. Wikipedia attributes the logo svg asset 
>> to http://www.openbsd.org/art4.html, but this page gives me a 404. I can 
>> access it fine using archive.org and going to last year's archive, but why 
>> is it not available now?
>
>If only changes were kept in a version control system that anybody
>could access... Oh, wait, they are!
>
>--
>Changes by: t...@cvs.openbsd.org  2022/04/28 11:01:56
>
>Removed files:
>.  : art1.html art2.html art3.html art4.html 
>
>Log message:
>almost all of the images on these pages give a 404 error since they're not
>stored in the www repo. remove them for now so people stop finding them on
>search engines.
>--
>
>-- 
>Christian "naddy" Weisgerber  na...@mips.inka.de
>

Re: smtpd[68513]: warn: lost processor: spamassassin exited abnormally

[Omar Polo]

On 2023/11/07 19:30:43 +0100, Harald Dunkel  wrote:
> Hi Omar,
> 
> sorry for the delay, but I have good news: The patch seems to
> work. Of course I will continue to watch it.

Thanks for verifying!

Before bumping the smtp-filter protocol version I took at look at what
we had in the port tree to know what would break, but this slipped.
apologize.

If it's OK for Giovanni and Joerg I'd like to commit this and backport
to 7.4-stable (same diff tested by Harald, reattaching for convenience.)

Index: Makefile
===
RCS file: /home/cvs/ports/mail/opensmtpd-filters/spamassassin/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile26 Sep 2023 12:28:14 -  1.8
+++ Makefile5 Nov 2023 09:20:27 -
@@ -4,7 +4,7 @@ V = 0.7
 FILTER_NAME =  spamassassin
 DISTNAME = filter-spamassassin-${V}
 HOMEPAGE = https://www.umaxx.net/
-REVISION = 0
+REVISION = 1
 
 CATEGORIES =   mail
 
Index: patches/patch-filter-spamassassin_go
===
RCS file: patches/patch-filter-spamassassin_go
diff -N patches/patch-filter-spamassassin_go
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-filter-spamassassin_go7 Nov 2023 19:14:58 -
@@ -0,0 +1,14 @@
+handle the smtpd filter-protocol version 0.7
+
+Index: filter-spamassassin.go
+--- filter-spamassassin.go.orig
 filter-spamassassin.go
+@@ -211,7 +211,7 @@ func run() {
+   for in.Scan() {
+   f := strings.Split(in.Text(), "|")
+   t, ver, ev, sid := f[0], f[1], f[4], f[5]
+-  if (t != "filter" && t != "report") || ver != "0.6" {
++  if (t != "filter" && t != "report") || ver != "0.7" {
+   l3.Err(fmt.Sprintln(sid, "protocol", t, ver))
+   return
+   }

Re: Jumbo frame, just a little late..

[Daniele B.]

Thnx for your reply,

I'm experimenting in a soho environment with very limited network activity 
from/to lan.
Indeed in the doubt I was leaving the setting in rc.local for now.

Can you give us more insight about the trouble?


-- Daniele Bonini

Nov 7, 2023 19:41:18 Theo de Raadt :

> Daniele B.  wrote:
> 
>> Actually i'm not sure about the real benefits of it, and for a soho
>> environment like mine but after 17 years I decided to take jumbo
>> frame seriously.. and MTU values of my network equipment to 9018.
>> I watched with happiness also to my old Mac having jumbo frame hard
>> coded with MTU 9018 like second choise in the hardware settings.
>> 
>> About OpenBSD (7.3 stable) the only thing I need to ask explanation
>> for is the reason of the error "wrong MTU value" popping up by setting
>> jumbo frame directly via hostame.mynicdevice; when the setting go
>> smoothly up via ifconfig manually or by rc.local. Is the nic device
>> initialization dependent on a sane 1500 MTU value, maybe?
> 
> You have no idea what problems you are creating for yourself.

OnLogic Helix 330

[Devin Reade]

(Returning after a long hiatus due to $DayJob$.)

I recently acquired an OnLogic Helix 330 (see [1] and [2]) and booted
the 7.4 install image via USB; no installation yet, no serial console
configured yet, no sharable dmesg yet.

I have the version with the four network interfaces, based on the
J6426.  Dropping to shell from the 7.4 install image, it looks like
ony two of the four are detected, via em(4) as I210.  Interestingly,
it is the two on the add-on board rather than the two integrated
ports, based on the link status in ifconfig(8).

The underlying network hardware is a Maxlinear GPY115 per [3].

Booting into Debian 12, all four interfaces are detected.  It looks like
support for the GPY115 is relatively new there.

I intend to add support for these network interfaces but in the
event anyone already has this or related work in progress, please
drop me a line either here or privately.

Once I get a proper install in place, I'll submit the usual dmesg
output.

Devin

[1]: 
[2]: 
[3]: 

Re: Jumbo frame, just a little late..

[Theo de Raadt]

Daniele B.  wrote:

> Actually i'm not sure about the real benefits of it, and for a soho
> environment like mine but after 17 years I decided to take jumbo
> frame seriously.. and MTU values of my network equipment to 9018.
> I watched with happiness also to my old Mac having jumbo frame hard
> coded with MTU 9018 like second choise in the hardware settings.
> 
> About OpenBSD (7.3 stable) the only thing I need to ask explanation
> for is the reason of the error "wrong MTU value" popping up by setting
> jumbo frame directly via hostame.mynicdevice; when the setting go
> smoothly up via ifconfig manually or by rc.local. Is the nic device
> initialization dependent on a sane 1500 MTU value, maybe?

You have no idea what problems you are creating for yourself.

Re: smtpd[68513]: warn: lost processor: spamassassin exited abnormally

[Harald Dunkel]

Hi Omar,

sorry for the delay, but I have good news: The patch seems to
work. Of course I will continue to watch it.

Thank you very much

Harri

Re: __dead

[Lucretia]

Sorry, I got very confused trying to read this file. C is a lot different than 
Java what we learned, and the source I've read here is a lot different from the 
few examples of C I've read in books.

I must have overlooked this comment but I did see the define for __dead

On Tue, Nov 7, 2023 at 22:16, Crystal Kolipe 
<[kolip...@exoticsilicon.com](mailto:On Tue, Nov 7, 2023 at 22:16, Crystal 
Kolipe < wrote:

> On Tue, Nov 07, 2023 at 04:01:12PM +, Lucretia wrote:
>> I read the whole file top to bottom, slowly and with care, and saw no
>> comments about __dead. Unless by chance they've been added since
>> 7.4 release.
>
> Immediately above where __dead and __pure are defined is the following
> comment:
>
> /*
> * GCC1 and some versions of GCC2 declare dead (non-returning) and
> * pure (no side effects) functions using "volatile" and "const";
> * unfortunately, these then cause warnings under "-ansi -pedantic".
> * GCC >= 2.5 uses the __attribute__((attrs)) style. All of these
> * work for GNU C++ (modulo a slight glitch in the C++ grammar in
> * the distribution version of 2.5.5).
> */
>
> This, with a few updates and changes, has been in the source code
> for > 30 years.
>
> For reference, the same comment in the same file in the NetBSD tree
> is a bit more verbose and gives some examples of what pure and const
> are used for.

Re: __dead

[Crystal Kolipe]

On Tue, Nov 07, 2023 at 04:01:12PM +, Lucretia wrote:
> I read the whole file top to bottom, slowly and with care, and saw no
> comments about __dead. Unless by chance they've been added since
> 7.4 release.

Immediately above where __dead and __pure are defined is the following
comment:

/*
 * GCC1 and some versions of GCC2 declare dead (non-returning) and
 * pure (no side effects) functions using "volatile" and "const";
 * unfortunately, these then cause warnings under "-ansi -pedantic".
 * GCC >= 2.5 uses the __attribute__((attrs)) style.  All of these
 * work for GNU C++ (modulo a slight glitch in the C++ grammar in
 * the distribution version of 2.5.5).
 */

This, with a few updates and changes, has been in the source code
for > 30 years.

For reference, the same comment in the same file in the NetBSD tree
is a bit more verbose and gives some examples of what pure and const
are used for.

Re: __dead

[Lucretia]

I didn't know there was a style man page. Thanks! I will make that my reading 
next.

On Tue, Nov 7, 2023 at 22:07, Maja Reberc <[m...@chloris.si](mailto:On Tue, Nov 
7, 2023 at 22:07, Maja Reberc < wrote:

> There's also something about it in style(9) man page.
> https://man.openbsd.org/style
>
> On Tue, 07 Nov 2023 16:01:12 +
> Lucretia  wrote:
>
>> I read the whole file top to bottom, slowly and with care, and saw no
>> comments about __dead. Unless by chance they've been added since 7.4
>> release.

Re: __dead

[Maja Reberc]

There's also something about it in style(9) man page.
https://man.openbsd.org/style

On Tue, 07 Nov 2023 16:01:12 +
Lucretia  wrote:

> I read the whole file top to bottom, slowly and with care, and saw no
> comments about __dead. Unless by chance they've been added since 7.4
> release.

Re: __dead

[Lucretia]

I read the whole file top to bottom, slowly and with care, and saw no comments 
about __dead. Unless by chance they've been added since 7.4 release.

On Tue, Nov 7, 2023 at 21:15, Crystal Kolipe 
<[kolip...@exoticsilicon.com](mailto:On Tue, Nov 7, 2023 at 21:15, Crystal 
Kolipe < wrote:

> On Tue, Nov 07, 2023 at 03:08:18PM +, Lucretia wrote:
>> I've seen __dead a few places in the source code, does this mean it isn't
>> functional anymore, or maybe just deprecated?
>
> Read the comments about it in /usr/src/sys/sys/cdefs.h.

Re: __dead

[Marc Espie]

On Tue, Nov 07, 2023 at 03:08:18PM +, Lucretia wrote:
> I've seen __dead a few places in the source code, does this mean it isn't 
> functional anymore, or maybe just deprecated?
> 

It's the old non-standard representation for  __attribute__(__noreturn__)
in code, to stop the compiler whining and unwarranted optimisations.

Re: __dead

[Crystal Kolipe]

On Tue, Nov 07, 2023 at 03:08:18PM +, Lucretia wrote:
> I've seen __dead a few places in the source code, does this mean it isn't
> functional anymore, or maybe just deprecated?

Read the comments about it in /usr/src/sys/sys/cdefs.h.

__dead

[Lucretia]

I've seen __dead a few places in the source code, does this mean it isn't 
functional anymore, or maybe just deprecated?

Re: Default Revival of a ten years old computer : how would you do it?

[Riccardo Mottola]

Hi,

h...@mailo.com wrote:

i have tested "recent" openbsd releases, since 2022, and almost all of them are 
a bit slow with xfce/firefox etc.

i was wondering, for laptops range of 2013/16 years old, what would you 
recommmend them for a common web browsing using openbsd?


I like to run BSD and Linux on a variety of older hardware, so I have 
some experience here.
First, OpenBSD is nice, but essentially, given "the same userland", that 
is the same X11, same desktop setup, same browser will be reasonably 
similar in performance to NetBSD or a good linux. Do not expect some 
"magic speed" in average user. What helps, usually is that you have a 
clean setup and install selectively what you need. So, usually, I have a 
a very clean system on NetBSD and OpenBSD, while perhaps on e.g. Debian 
you start with a big "gnome desktop setup" and then customized later, 
but removing is harder than adding. A good Devuan setup (no systemd) 
with basic X11, wm and firefox performs for me similarly to a NetBSD and 
OpenBSD system for browsing.
Other differences? Hardware support. On your system you might have the 
luck that the OpenBSD driver for some of your chips (e.g. network) works 
better than others. FFS is just faster than certan journaled file system 
you get as default elsewhere.


Also "old".. it might be a low-end system with some crippled processor 
and low on ram.. or a good i5 with 8GB of RAM (top of the line back 
then). Key for browsing is RAM in any case. Under 3/4GB you cannot often 
open more than one or two tabs nowadays!


"common web browsing" can be an incredibly demanding task. Graphic and 
intensive website can kill current and top systems. Using chrome with 10 
GitHub Tabs open and then open YouTube?
Or browse some manpages, use wikipedia and duck-duck-go... that you can 
also on an old Centrino.


Given that... on selected systems OpenBSD works just very well. My aging 
HP laptop has suspend-to-ram support, wifi support... just everything 
out of the box. Easy to configure too!


Riccardo

Re: Regression (or misconfig on my side?) after OpenOSPFd upgrade (OpenBSD 7.3 -> 7.4)

[Laurent CARON]

Le 07/11/2023 à 10:59, Claudio Jeker a écrit :

Ugh. My bad. I forgot that iface->auth_key is not really a string. So the
code setting the auth_key would copy too much if you use a password with 8
chars. Using a password with 7 or less chars works fine.

As a result of this overflow the checksum calculation in auth_validate
fails and that's what you see.

Diff below should fix this.



Thanks Claudio,

Gonna give it a try today.

Cheers,

Lauent

Re: Jumbo frame, just a little late..

[Daniele B.]

Claudio Jeker :

> This is not what hostname.if documents as a correct command line.
> 
> Best is if you put mtu 9018 as a single line.


Indeed to make things easy I prefer to keep the mtu update in rc.local for now.

I was curious to clarify the error problem indeed, thnx.

Re: Regression (or misconfig on my side?) after OpenOSPFd upgrade (OpenBSD 7.3 -> 7.4)

[Theo Buehler]

On Tue, Nov 07, 2023 at 10:59:48AM +0100, Claudio Jeker wrote:
> On Tue, Nov 07, 2023 at 08:21:16AM +0100, Laurent CARON wrote:
> > Hi,
> > 
> > After upgrading a 7.3 to 7.4 OpenBSD box, I noticed OSPF adjacencies using a
> > password are not coming up with the following in /var/log/messages:
> > 
> > ospfd[55040]: recv_packet: authentication error, neighbor ID X.X.X.X
> > interface vlanXX
> > 
> > After removing the authentication, I was able to get adjacencies to come up.
> > 
> > Config contains:
> > 
> > password=""
> > auth-key $password
> > auth-type simple
> > 
> > This config was working perfectly fine until OpenBSD 7.3 but fails with 7.4
> > 
> > The 'only' way I found to have it working is to get rid of authentication.
> > 
> 
> Ugh. My bad. I forgot that iface->auth_key is not really a string. So the
> code setting the auth_key would copy too much if you use a password with 8
> chars. Using a password with 7 or less chars works fine.
> 
> As a result of this overflow the checksum calculation in auth_validate
> fails and that's what you see.
> 
> Diff below should fix this.

ok tb

> -- 
> :wq Claudio
> 
> Index: auth.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/auth.c,v
> diff -u -p -r1.22 auth.c
> --- auth.c3 Jul 2023 09:40:47 -   1.22
> +++ auth.c7 Nov 2023 09:56:44 -
> @@ -166,7 +166,8 @@ auth_gen(struct ibuf *buf, struct iface 
>   fatalx("auth_gen: ibuf_set failed");
>  
>   if (ibuf_set(buf, offsetof(struct ospf_hdr, auth_key),
> - iface->auth_key, strlen(iface->auth_key)) == -1)
> + iface->auth_key, strnlen(iface->auth_key,
> + sizeof(iface->auth_key))) == -1)
>   fatalx("auth_gen: ibuf_set failed");
>   break;
>   case AUTH_CRYPT:
> 

Re: Jumbo frame, just a little late..

[Claudio Jeker]

On Tue, Nov 07, 2023 at 11:33:04AM +0100, Daniele B. wrote:
> 
> Sorry Claudio, my fault.
> 
> wiz# ifconfig reX hwfeatures
> hwfeatures= [*] hardmtu 9194
> 
> by hostname.reX: 
> 
>   wiz# nano /etc/hostname.reX:
>   inet 192.168.XXX.XXX 0xff00 mtu 9018

This is not what hostname.if documents as a correct command line.

Best is if you put mtu 9018 as a single line.

The using 'inet' line with options requires all of 'addr netmask
broadcast_addr' to be set. You miss the broadcast_addr.


>   ctrl+S; ctrl+X
> 
>   wiz# sh /etc/netstart
> 
>   ifconfig: mtu: bad value
> 
>   (same eventually at boot time)
> 
> by shell or rc.local:
> 
>   wiz# ifconfig reX mtu 9018
>(accepted)
>   wiz# ifconfig reX
> 
>   reX: flags=8843 mtu 9018
>  lladdr XX:XX:XX:XX:XX:XX
>  index 1 priority 0 llprio 3
>  groups: egress
>  media: Ethernet autoselect (1000baseT
>   full-duplex,master,rxpause,txpause) status: active inet
>   192.168.XXX.XXX netmask 0xff00 broadcast 192.168.XXX.XXX
> 
> 
> == Daniele Bonini
> 
> 
> Claudio Jeker  wrote:
> 
> > Sorry this bug report lacks all important information.
> > 
> > a) what is your hostame.mynicdevice contents
> > b) where does the error pop up? neither netstart nor ifconfig contain
> > the word "wrong"
> > c) what interface are you playing with?
> > 
> > So we can't help you.
> 

-- 
:wq Claudio

Re: Jumbo frame, just a little late..

[Daniele B.]

Thanks this solved..
 

Zé Loff  wrote:
 
> From man hostname.if:
> 
> Regular IPv4 network setup:
> inet [alias] addr netmask broadcast_addr options
> 
> The third argument after "inet" is the broadcast address.  You have
> "mtu", which isn't one, hence the error.  Try adding "NONE" before
> "mtu":
> 
> inet 192.168.XXX.XXX 0xff00 NONE mtu 9018

Re: Jumbo frame, just a little late..

[Daniele B.]

"Peter N. M. Hansteen"  wrote:

> try "ifconfig $device hwfeatures" and look for the "hardmtu" value.
> 
> it is possible whatever mynicdevice is does not actually support
> jumbo frames.


Thxs, received, but not this case (hardmtu=9194) and however manually
the new MTU value goes up. There is something wrong somewhere, let me
know if you need more info..


== Daniele Bonini

Re: Loongson: Version 7.3 package information in 7.4 SHA256 file

[Armin Jenewein]

There was a small discussion thread a couple of days ago already, where
people noticed. Just pointing to it so you're aware. We also noticed the
wrong 73 entries in the SHA256 file:

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

Best,

~ Armin





On 23-11-05 18:34:18, Carsten Strotmann wrote:
> Hi,
> 
> (sorry for the misdirected subscribe mail this morning - I've recognised the 
> error soon after sending, but could not cancel the message)
> 
> I found a possible issue with the SHA256 file for the Loongson architecture 
> for OpenBSD 7.4
> 
> That file contains the names and hashes of (some) 7.3 install packages (along 
> with the correct 7.4 names and hashes).
> 
> 
> "sysupgrade" will try to download the 7.3 packages from the 7.4 installurl, 
> and will fail.
> 
> Removing the wrong 7.3 references fixes the file.
> 
> Patch to create a fixed SHA256 file:
> 
> --- SHA256.old  Sun Nov  5 11:33:19 2023
> +++ SHA256.new  Sun Nov  5 11:33:42 2023
> @@ -8,11 +8,7 @@
>  SHA256 (game74.tgz) = 
> 358caf89d2a8b7d22aaa59e26ca34ad66c43e37de6e8579c64b25476b5371e59
>  SHA256 (man74.tgz) = 
> 94782f99765a612ffa6a27fb11433f53088e3ca7fb90aee19be196a35e8cb997
>  SHA256 (miniroot74.img) = 
> 749d275bc67355c742b1c25ff13508442d38fe7c2e8494bafdeff46d26025e2d
> -SHA256 (xbase73.tgz) = 
> d5844b1f2c172e10496efc1baa8eeb355940956a907a9275f1f096833e260f09
>  SHA256 (xbase74.tgz) = 
> dcaf6e3d636663319c765dae90212b9864ece9a5ad4e45656a221caf0a28a943
> -SHA256 (xfont73.tgz) = 
> 6bdf10f73be2cb2f5d83288ee882a49fa91a93244a5dfff3b6ffd77ca2650658
>  SHA256 (xfont74.tgz) = 
> 9bd11d9d1213713b5c394a7259841aef52f6d237875002fd452d4cfd84e15a81
> -SHA256 (xserv73.tgz) = 
> 7140a67c48460a148f71e20aea677e5a20e0819eccb39fbbe1884210c253ebe4
>  SHA256 (xserv74.tgz) = 
> 3cd38cd95760d71febc6c13213279081bdab2ec2facf4709f383dd6594af5c9c
> -SHA256 (xshare73.tgz) = 
> d9eedf413cfce03eafc09f4a90e4d71f511fafcd90379ac2305ac9ae350d6c43
>  SHA256 (xshare74.tgz) = 
> 014a306a6c98c6e55f682242a2ede50c3a98d2a0b426df974c3fdfae89913f1e
> 
> 
> Maybe this can be fixed on the mirror servers.
> 
> Greetings
> 
> Carsten Strotmann
> 
> P.S.: if this was an attempt to check if there is anyone still using OpenBSD 
> on Loongson, it worked. It's me ;)
> 

-- 
Armin Jenewein

Re: Jumbo frame, just a little late..

[Zé Loff]

On Tue, Nov 07, 2023 at 11:33:04AM +0100, Daniele B. wrote:
> 
> Sorry Claudio, my fault.
> 
> wiz# ifconfig reX hwfeatures
> hwfeatures= [*] hardmtu 9194
> 
> by hostname.reX: 
> 
>   wiz# nano /etc/hostname.reX:
>   inet 192.168.XXX.XXX 0xff00 mtu 9018

>From man hostname.if:

Regular IPv4 network setup:
inet [alias] addr netmask broadcast_addr options

The third argument after "inet" is the broadcast address.  You have
"mtu", which isn't one, hence the error.  Try adding "NONE" before
"mtu":

inet 192.168.XXX.XXX 0xff00 NONE mtu 9018


>   ctrl+S; ctrl+X
> 
>   wiz# sh /etc/netstart
> 
>   ifconfig: mtu: bad value
> 
>   (same eventually at boot time)
> 
> by shell or rc.local:
> 
>   wiz# ifconfig reX mtu 9018
>(accepted)
>   wiz# ifconfig reX
> 
>   reX: flags=8843 mtu 9018
>  lladdr XX:XX:XX:XX:XX:XX
>  index 1 priority 0 llprio 3
>  groups: egress
>  media: Ethernet autoselect (1000baseT
>   full-duplex,master,rxpause,txpause) status: active inet
>   192.168.XXX.XXX netmask 0xff00 broadcast 192.168.XXX.XXX
> 
> 
> == Daniele Bonini
> 
> 
> Claudio Jeker  wrote:
> 
> > Sorry this bug report lacks all important information.
> > 
> > a) what is your hostame.mynicdevice contents
> > b) where does the error pop up? neither netstart nor ifconfig contain
> > the word "wrong"
> > c) what interface are you playing with?
> > 
> > So we can't help you.
> 

-- 
 

Re: Default Revival of a ten years old computer : how would you do it?

[Zé Loff]

On Mon, Nov 06, 2023 at 11:29:22AM +0100, h...@mailo.com wrote:
> 
> 
> since few months im discovering openbsd ; as linux has been often
> recommended for windows's users with a very slow system, i guess that
> it's not that unadvised to use openbsd with a GUI for web browsing and
> little software (eg LO, gimp..)
> 
> i have tested "recent" openbsd releases, since 2022, and almost all of
> them are a bit slow with xfce/firefox etc.
> 
> i was wondering, for laptops range of 2013/16 years old, what would
> you recommmend them for a common web browsing using openbsd?
> 
> I thank you vm 
> 

My two cents, just to balance some of the "you must be out of your mind"
answers you've been getting.

You are talking about 10 year-old laptops, which are likely to be
memory-limited, and in some cases have weaker CPUs and GPUs.  Ten years
ago, Firefox 25 recommended 512MB of RAM, a reasonably good digital
camera took 12Mp images and recorded 1080p 60fps videos.  Nowadays, it
all increased fourfold: Firefox recommends 2Gb RAM, and a smartphone
will get you 48Mp images and 4K video at 60fps.  A ten year old laptop
probably will only have USB 2, now you'll get (you guessed it) four
times the bandwidth with USB 3.2, etc.

None of this has anything to do with whether you use OpenBSD.  I'm just
stating that it is not reasonable to expect that running OpenBSD (or
Linux, or whatever) will suddenly botox your aging hardware to make it
look 5 years younger.  Will it run faster than on Windows?  Almost
certainly.  Will it be capable of running Firefox with eight tabs open?
Probably, but it sure won't be "snappy" and "responsive".

In summary, manage your/the end user's expectations.  I've thought of
repurposing an old laptop for my 10yo kid, but I known that within a
week or two I'd be hearing complains about the videos on the n-th
firefox tab not playing properly, or how nothing happens when you click
on some link.  I'd be able to live with that machine, my kid probably
wouldn't.

You can probably guess from what I wrote above that, in *my* experience,
the main frustrations with running older machines -- and by older I mean
at least 10 years old -- is web browsing (most browsers are bloated
memory-hogs, and the sites have followed suit), manipulating my own
photos and videos (and I mean just moving them around, not editing)
because of file size, and transfer rates to/from USB devices.  That
being said, I've used a ThinkPad X201 for many many happy years, after
getting as much RAM as possible into it.  But admittedly, I work mostly
on the terminal, with a lightweight WM (dwm, but there are many more
options), mutt for email, vim for work (statistical programming with R +
LaTeX), the ocasional, inkscape-ing and minor gimp-ing, and some usage
of LibreOffice.  It was certainly faster than Windows, and I don't think
it was much slower than Linux, if at all.

OpenBSD doesn't target speed (even if it runs pretty lean, compared to
most Linux distros I've come across), it targets security and
consistency.  If speed is all you're after, maybe other OSs will better
suit your needs.  Otherwise its a trade-off, and only you will know if
its worth it or not.

I am using OpenBSD like I said above for about 15 years now, the machine
I'm writing this in about five years old, and I've been doing fine.
You'll probably do too.  Just stay clear of NVIDIA hardware, which can't
be properly supported.  Oh, and forget about bluetooth.

In the end, the proof is in the pudding.  If you have a spare HDD around
just install OpenBSD (not onto a USB device if the machine only has
USB2!), which is pleasantly quick, pkg_add firefox and browse about a
bit.  I won't take you long, and you'll get a good feel of how the
machine will behave.  Then, you can do some customizing
(https://www.openbsd.org/faq/faq11.html), add LibreOffice and Gimp, move
around a bit more, and then decide whether you find it worth it or not.

It all depends on the kind of usage you are planning, it depends on the
hardware, it depends on the your (or the machine's final user's)
expectations, and on how much you value security, stability and
consistency over "performance" (however *you* define it).

Cheers
Zé

-- 
 

Re: Jumbo frame, just a little late..

[Daniele B.]

Sorry Claudio, my fault.

wiz# ifconfig reX hwfeatures
hwfeatures= [*] hardmtu 9194

by hostname.reX: 

  wiz# nano /etc/hostname.reX:
  inet 192.168.XXX.XXX 0xff00 mtu 9018
  ctrl+S; ctrl+X

  wiz# sh /etc/netstart

  ifconfig: mtu: bad value

  (same eventually at boot time)

by shell or rc.local:

  wiz# ifconfig reX mtu 9018
   (accepted)
  wiz# ifconfig reX

  reX: flags=8843 mtu 9018
 lladdr XX:XX:XX:XX:XX:XX
 index 1 priority 0 llprio 3
 groups: egress
 media: Ethernet autoselect (1000baseT
  full-duplex,master,rxpause,txpause) status: active inet
  192.168.XXX.XXX netmask 0xff00 broadcast 192.168.XXX.XXX


== Daniele Bonini


Claudio Jeker  wrote:

> Sorry this bug report lacks all important information.
> 
> a) what is your hostame.mynicdevice contents
> b) where does the error pop up? neither netstart nor ifconfig contain
> the word "wrong"
> c) what interface are you playing with?
> 
> So we can't help you.

Re: Jumbo frame, just a little late..

[Peter N. M. Hansteen]

On Tue, Nov 07, 2023 at 10:21:35AM +0100, Daniele B. wrote:
> About OpenBSD (7.3 stable) the only thing I need to ask explanation
> for is the reason of the error "wrong MTU value" popping up by setting
> jumbo frame directly via hostame.mynicdevice; when the setting go
> smoothly up via ifconfig manually or by rc.local. Is the nic device
> initialization dependent on a sane 1500 MTU value, maybe?

try "ifconfig $device hwfeatures" and look for the "hardmtu" value.

On the systems I sampled randomly here, it looks like the em device
on this box has "hardmtu 9216" so it should handle jumbo frames just
fine. On the other hand the iwx in the laptop over there has "hardmtu 1500",
so setting the MTU to anything higher than that would simply fail.

it is possible whatever mynicdevice is does not actually support jumbo frames. 

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: Jumbo frame, just a little late..

[Claudio Jeker]

On Tue, Nov 07, 2023 at 10:21:35AM +0100, Daniele B. wrote:
> Hello,
> 
> Actually i'm not sure about the real benefits of it, and for a soho
> environment like mine but after 17 years I decided to take jumbo
> frame seriously.. and MTU values of my network equipment to 9018.
> I watched with happiness also to my old Mac having jumbo frame hard
> coded with MTU 9018 like second choise in the hardware settings.
> 
> About OpenBSD (7.3 stable) the only thing I need to ask explanation
> for is the reason of the error "wrong MTU value" popping up by setting
> jumbo frame directly via hostame.mynicdevice; when the setting go
> smoothly up via ifconfig manually or by rc.local. Is the nic device
> initialization dependent on a sane 1500 MTU value, maybe?

Sorry this bug report lacks all important information.

a) what is your hostame.mynicdevice contents
b) where does the error pop up? neither netstart nor ifconfig contain the
word "wrong"
c) what interface are you playing with?

So we can't help you.
-- 
:wq Claudio

Re: Regression (or misconfig on my side?) after OpenOSPFd upgrade (OpenBSD 7.3 -> 7.4)

[Claudio Jeker]

On Tue, Nov 07, 2023 at 08:21:16AM +0100, Laurent CARON wrote:
> Hi,
> 
> After upgrading a 7.3 to 7.4 OpenBSD box, I noticed OSPF adjacencies using a
> password are not coming up with the following in /var/log/messages:
> 
> ospfd[55040]: recv_packet: authentication error, neighbor ID X.X.X.X
> interface vlanXX
> 
> After removing the authentication, I was able to get adjacencies to come up.
> 
> Config contains:
> 
> password=""
> auth-key $password
> auth-type simple
> 
> This config was working perfectly fine until OpenBSD 7.3 but fails with 7.4
> 
> The 'only' way I found to have it working is to get rid of authentication.
> 

Ugh. My bad. I forgot that iface->auth_key is not really a string. So the
code setting the auth_key would copy too much if you use a password with 8
chars. Using a password with 7 or less chars works fine.

As a result of this overflow the checksum calculation in auth_validate
fails and that's what you see.

Diff below should fix this.
-- 
:wq Claudio

Index: auth.c
===
RCS file: /cvs/src/usr.sbin/ospfd/auth.c,v
diff -u -p -r1.22 auth.c
--- auth.c  3 Jul 2023 09:40:47 -   1.22
+++ auth.c  7 Nov 2023 09:56:44 -
@@ -166,7 +166,8 @@ auth_gen(struct ibuf *buf, struct iface 
fatalx("auth_gen: ibuf_set failed");
 
if (ibuf_set(buf, offsetof(struct ospf_hdr, auth_key),
-   iface->auth_key, strlen(iface->auth_key)) == -1)
+   iface->auth_key, strnlen(iface->auth_key,
+   sizeof(iface->auth_key))) == -1)
fatalx("auth_gen: ibuf_set failed");
break;
case AUTH_CRYPT:

Jumbo frame, just a little late..

[Daniele B.]

Hello,

Actually i'm not sure about the real benefits of it, and for a soho
environment like mine but after 17 years I decided to take jumbo
frame seriously.. and MTU values of my network equipment to 9018.
I watched with happiness also to my old Mac having jumbo frame hard
coded with MTU 9018 like second choise in the hardware settings.

About OpenBSD (7.3 stable) the only thing I need to ask explanation
for is the reason of the error "wrong MTU value" popping up by setting
jumbo frame directly via hostame.mynicdevice; when the setting go
smoothly up via ifconfig manually or by rc.local. Is the nic device
initialization dependent on a sane 1500 MTU value, maybe?

Thxs!
-- Daniele Bonini

Regression (or misconfig on my side?) after OpenOSPFd upgrade (OpenBSD 7.3 -> 7.4)

[Laurent CARON]

Hi,

After upgrading a 7.3 to 7.4 OpenBSD box, I noticed OSPF adjacencies 
using a password are not coming up with the following in /var/log/messages:


ospfd[55040]: recv_packet: authentication error, neighbor ID X.X.X.X 
interface vlanXX


After removing the authentication, I was able to get adjacencies to come up.

Config contains:

password=""
auth-key $password
auth-type simple

This config was working perfectly fine until OpenBSD 7.3 but fails with 7.4

The 'only' way I found to have it working is to get rid of authentication.

Thanks

Laurent