Re: dmesg memory not match spdmem and bios
On Thu, Jun 11, 2020 at 12:57:24PM +, man Chan wrote: I just want to know why OpenBSD/i386 have the memory limit to 4G. Thanks for your reply. It is the design of OpenBSD/i386 is 32 bits OS not the hardware limitation. It is ok for me to run OpenBSD/amd64 on a i5 machine. Thanks The 4GB limit is not specific to OpenBSD/i386. It's a hardware limitation specific to the x86 platform (also known as i386). Use the OpenBSD/amd64 installer on your Intel i5 hardware, it will run better, without being limited to 4GB of RAM, among others. Trivia fact: all recent Intel processors use the amd64 architecture, licensed from AMD. Unfortunately, Intel's marketing conceals this as much as possible, thus the confusion from the less tech-inclined people. But you could have easily found all this online, especially after been pointed repeatedly on this list. So please consider not wasting other people's time with such basic questions. OpenBSD developers are few and far between, and two of the most senior ones have already spent time explaining you these basics. Otherwise you risk being ignored even when raising issues actually related to OpenBSD.
Re: Not correctly supported on OpenBSD 6.7: HPE 10/25Gb 2p 640FLR-SFP28 network adapter on HPE DL380 Gen10 servers
On Fri, Jun 12, 2020 at 12:13:42AM +0200, Mark Schneider wrote: > Hello > > > Even the 640FLR-SFP28 network adapter is listed in the "pcidump -v" output > on OpenBSD 6.7 there are no entries for it's interfaces in the output of > "ifconfig -a" > > # - > obsd67a1# grep "^ [0-9]" OBSD67-pcidump-v.txt | grep -v Intel > 1:0:0: Hewlett-Packard iLO3 Slave > 1:0:1: Matrox unknown > 1:0:2: Hewlett-Packard iLO3 Management > 1:0:4: Hewlett-Packard unknown > 2:0:0: Broadcom BCM5719 > 2:0:1: Broadcom BCM5719 > 2:0:2: Broadcom BCM5719 > 2:0:3: Broadcom BCM5719 > 18:0:0: Adaptec unknown > 177:0:0: Adaptec unknown > 178:0:0: Mellanox ConnectX-4 Lx > 178:0:1: Mellanox ConnectX-4 Lx > # - Can you try -current please? This system will likely work better with support for acpi pci host bridges, which was not enabled in 6.7.
Re: __printflike macro on OpenBSD
sensiblehue wrote: > I asked about __printflike because I found it unusual that other major > BSDs have it and OpenBSD doesn't, despite using macros like __dead, > __unused, etc. Systems adopt private solutions, half the time without limiting the scope to indicate it is private. The assumption the should be adopted GLOBALLY requires strong justification. > If I understood correctly, the existence of those macros is merely a > convenience and not an intentional effort for portability with the other > BSDs. In that case it was wrong to assume OpenBSD should have it. I declare the idea inconvenient. A portability collision. Unhelpful.
Re: __printflike macro on OpenBSD
On Thu, Jun 11, 2020 at 01:03:46PM -0600, Theo de Raadt wrote: > Theo de Raadt wrote: > > > sensiblehue wrote: > > > > > On Thu, Jun 11, 2020 at 03:08:01PM +0200, Marc Espie wrote: > > > > On Thu, Jun 11, 2020 at 04:37:34AM +, sensiblehue wrote: > > > > > Hello, > > > > > I was wondering why OpenBSD doesn't have a `__printflike' macro in > > > > > ? FreeBSD, NetBSD, and DragonflyBSD have it and it's also > > > > > available from libbsd on Linux. > > > > > Personally I think it's cleaner and just as portable if not more > > > > > portable, because some compilers don't support `__attribute__'. > > > > > > > > > > > > What compilers ? > > > > > > GCC < v2.5 and non GNU C compilers, though I see now that OpenBSD > > > defines it to nothing in that case. > > > > Ah, so it does actually work fine, unlike what you originally claimed. Yes, I should've done more research beforehand. > > > > > > > To be honest I'm mostly suggesting __printflike because I want to use it > > > in my own code and still have it compile on OpenBSD without an #ifdef, > > > but it would also make software from other BSDs easier to port. > > > > We are using the attribute mechanism directly in a way that works on > > all modern (10 years?). > > > > Intentionally. > > Let me reiterate why it is used directly. You probably understand, but > I'm not sure you see the value. > > 1. If the compiler supports attributes but does not know this one, the >code compiles, the special handling isn't done, and everything works. > > 2. If the compiler supports attributes but and knows it, the special handling >is performed, and everything works. > > 3. If the compiler is so old that it doesn't handle unsupported attributes, >go use a different (new) compiler. > Fair enough, if __attribute__ has worked for so many years I agree portability isn't a concern. I asked about __printflike because I found it unusual that other major BSDs have it and OpenBSD doesn't, despite using macros like __dead, __unused, etc. If I understood correctly, the existence of those macros is merely a convenience and not an intentional effort for portability with the other BSDs. In that case it was wrong to assume OpenBSD should have it. > You say you want to use an old compiler which doesn't handle unknown > attributes? No, just pointing out an edge case. > How will you cope with all the operating systems which lack the #define > you request? *BSD is the only operating system worth writing code for. :)
Re: OpenBSD Readonly File System
I guess it boils down to a matter of preference and business requirements. "slow writes" vs "no writes". -Original Message- From: Strahil Nikolov Sent: Friday, 12 June 2020 12:08 AM To: Dirk Coetzee ; Joe Barnett ; Vertigo Altair Cc: Misc Subject: Re: OpenBSD Readonly File System I always thought that 'sync' mount option is enough to avoid corruption of the FS. Am I just "fooling" myself ? Best Regards, Strahil Nikolov На 10 юни 2020 г. 7:46:48 GMT+03:00, Dirk Coetzee написа: >I have been in a similar situation of power being unreliable and no >UPS, so I sympathize. > >This is how I have achieved RO filesystem (default partitions) > >1. Add to /etc/fstab > swap /dev mfs rw,-P=/dev,-s=32m 0 0 > >2. Create RO Script > #!/bin/sh > > UP=$(( $(date +%s) - $(sysctl -n kern.boottime) )) ## Date in >Seconds subtracted from OS boot time > > if [ $UP -lt 3600 ]; then ## > If less than 1 hour - >leave system as is. No modification of FS. You can add crontab for this >script to run every hour. > exit 1 > else > mount -uvr / > mount -uvr /usr > mount -uvr /usr/X11R6 > mount -uvr /usr/local > mount -uvr /usr/obj > mount -uvr /usr/src > fi > > exit 1 > > >Obviously this is a last resort. Default partitions, etc should remain >as devs intended. The Developers also assume a work (RW) filesystem. > >I have a RW script that I run before doing sysupgrade / syspatch etc. >Also make the Filesystems RW before rebooting. > > > > >-Original Message- >From: owner-m...@openbsd.org On Behalf Of Joe >Barnett >Sent: Wednesday, 10 June 2020 8:02 AM >To: Vertigo Altair >Cc: Misc >Subject: Re: OpenBSD Readonly File System > >On 2020-06-09 00:59, Vertigo Altair wrote: >> Hi Misc, >> I have a firewall device and I'm using OpenBSD on it. There is an >> electricity problem where the device runs. Therefore, I have to run >> the "fsck -y" command regularly at startup due to the electricity >problem. >> To >> overcome this, I want to use readonly file system. >> I know there are some projects like "resflash", but I want to do >that >> manually. > >I have hacked and slashed my way to this kind of configuration for my >firewall/gateway and a few other machines -- and with what appears to >be good results. Please understand this is almost certainly not >supported by the project. I have outlined this at the following URL: > >https://www.mr72.com/readonlyfs.html > >I hope this helps. Any feedback will be greatly appreciated. > >Good luck! > >Joe > >> My partitions like this; >> >> vertigo# df -h >> Filesystem SizeUsed Avail Capacity Mounted on >> /dev/sd0a 3.9G489M3.2G13%/ >> /dev/sd0g 91.8G1.0G 86.2G 1%/mypartition >> /dev/sd0d 989M 12.0K940M 0%/tmp >> /dev/sd0f 3.9G1.7G2.0G46%/usr >> /dev/sd0e 3.9G 46.9M3.6G 1%/var >> >> I want to / and /usr as readonly, I updated /etc/fstab and I made / >> and /usr readonly; >> >> vertigo# cat /etc/fstab >> ec347fefe8d05509.b none swap sw >> ec347fefe8d05509.a / ffs ro 1 1 >> ec347fefe8d05509.g /mypartition ffs rw,nodev,nosuid 1 2 >> ec347fefe8d05509.d /tmp ffs rw,nodev,nosuid 1 2 ec347fefe8d05509.f >> /usr ffs ro,wxallowed,nodev 1 2 ec347fefe8d05509.e /var ffs >> rw,nodev,nosuid 1 2 >> >> >> On startup following errors comming from /etc/rc; I think errors >about >> /etc/motd are not so important, but are the errors coming from >> /etc/tty* >> can cause any problems? If my method is not correct, what is the best > >> way to do this? >> OpenBSD/amd64 BOOTX64 3.50 >> boot> >> booting hd0a:/bsd: 12957000+2753552+327712+0+708608 >> [807408+128+1024872+749630]=0x1271a18 >> entry point at 0x1001000 >> [ using 2583064 bytes of bsd ELF symbol table ] Copyright (c) 1982, >> 1986, 1989, 1991, 1993 >> The Regents of the University of California. All rights >> reserved. >> Copyright (c) 1995-2020 OpenBSD. All rights reserved. >> https://www.OpenBSD.org >> >> OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun 4 09:55:08 MDT 2020 >> >> >r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GEN >> ERIC.MP >> real mem = 4151607296 (3959MB) >> avail mem = 4013170688 (3827MB) >> mpath0 at root >> scsibus0 at mpath0: 256 targets >> mainbus0 at root >> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf10 (14 entries) >> bios0: vendor American Megatrends Inc. version "BAR3NA05" date >> 07/23/2018 >> bios0: NF533 NF533 >> acpi0 at bios0: ACPI 5.0 >> acpi0: sleep states S0 S3 S4 S5 >> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG LPIT HPET SSDT SSDT SSDT >> UEFI >> acpi0: wakeup devices XHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) >> acpitimer0 at acpi0: 3579545 Hz, 24 bits >> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat >> cpu0 at mainbus0: apid 0 (boot processor) >> cpu0: Intel(R) Celeron(R) CPU
Re: iked keeps reconnecting every 8 minutes
On Thu, Jun 11, 2020 at 02:36:53PM +, Leclerc, Sebastien wrote:
> > I seems I got it wrong before. Even when there was ESP traffic, iked is
> > going
> > to start DPD when there hasn't been any incoming IKE message in the last
> > 5 minutes.
> >
> > My advice would be to just disable DPD in iked for this specific case.
> > To do this you will have to patch it and build it from the sources.
> > Below is a diff that should do the trick.
> >
> > Index: ikev2.c
> > ===
> > RCS file: /cvs/src/sbin/iked/ikev2.c,v
> > retrieving revision 1.231
> > diff -u -p -r1.231 ikev2.c
> > --- ikev2.c 9 Jun 2020 21:53:26 - 1.231
> > +++ ikev2.c 10 Jun 2020 11:02:39 -
> > @@ -4391,7 +4391,7 @@ ikev2_ike_sa_alive(struct iked *env, voi
> > * SA, or if we haven't received an IKE message. but only if we
> > * are not already waiting for an answer.
> > */
> > - if (((!foundin && foundout) || ikeidle) &&
> > + if ((!foundin && foundout) &&
> > (sa->sa_stateflags & (IKED_REQ_CHILDSA|IKED_REQ_INF)) == 0) {
> > log_debug("%s: sending alive check", __func__);
> > ikev2_send_ike_e(env, sa, NULL, IKEV2_PAYLOAD_NONE,
>
> Thank you very much, the patch did the trick. No reconnection since yesterday.
> As it is in production, this system is following syspatches only. If there
> ever is a syspatch on iked for another problem, I assume I would have to
> reapply this patch, right?
>
Correct. In that case you would do a cvs update to get the errata patch
and then reapply this diff.
Relayd with TLS and non-TLS backends - bug
Hello Misc,
Full config at end of email.
I've discussed the below in #openbsd on freenode, and was told to come
here. At present, I have a setup where I need multiple unrelated
servers under a single IP address. I used relayd to do https
interception, read the Host header, and make decisions.
The very relevant part of my config is this:
forward to port 80
forward with tls to port 443
The order here does not matter (unlike most relayd configs, I know,
but I've tested in my configuration and it works).
When I have "with tls" on that second line, I see error lines like:
relay web, session 3 (1 active), 0, [redacted] -> 10.0.0.102:80, TLS
handshake error: handshake failed: error:14FFF3E7:SSL
routines:(UNKNOWN)SSL_internal:unknown failure occurred, GET:
Undefined error: 0
and, unhelpfully, relayd responds with no response. There is no
return. Or, as curl puts it: curl: (52) Empty reply from server
When I remove "with tls" then I successfully reach the http backend,
but since the https backend requires ssl, that connection no longer
works. So it seems that 'with tls" affects all "forward" clauses, not
just the one to which it's attached.
I believe this to be a bug.
cat >/etc/relayd.conf < { "10.0.0.101" }
table { "10.0.0.102" }
# obviously obfuscated some values
interval 5
timeout 1000
log connection
http protocol web {
return error
match header set "X-Client-IP" value "$REMOTE_ADDR:$REMOTE_PORT"
match header set "X-Forwarded-For" value "$REMOTE_ADDR"
match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
http websockets
pass request quick header "Host" value "myhost.example.com" path
"/Client/*" forward to
pass request quick header "Host" value "otherhost.example.com" forward
to
block
}
relay web {
listen on 10.0.0.100 port 443 tls
protocol web
forward to port 80 check http "/webservice.asmx" code 405
forward with tls to port 443 check https
"/Client/SupportedBrowsers.html" host "myhost.example.com" code 200
}
EOF
Re: OpenBSD Readonly File System
I always thought that 'sync' mount option is enough to avoid corruption of the FS. Am I just "fooling" myself ? Best Regards, Strahil Nikolov На 10 юни 2020 г. 7:46:48 GMT+03:00, Dirk Coetzee написа: >I have been in a similar situation of power being unreliable and no >UPS, so I sympathize. > >This is how I have achieved RO filesystem (default partitions) > >1. Add to /etc/fstab > swap /dev mfs rw,-P=/dev,-s=32m 0 0 > >2. Create RO Script > #!/bin/sh > > UP=$(( $(date +%s) - $(sysctl -n kern.boottime) )) ## Date in >Seconds subtracted from OS boot time > > if [ $UP -lt 3600 ]; then ## > If less than 1 hour - >leave system as is. No modification of FS. You can add crontab for this >script to run every hour. > exit 1 > else > mount -uvr / > mount -uvr /usr > mount -uvr /usr/X11R6 > mount -uvr /usr/local > mount -uvr /usr/obj > mount -uvr /usr/src > fi > > exit 1 > > >Obviously this is a last resort. Default partitions, etc should remain >as devs intended. The Developers also assume a work (RW) filesystem. > >I have a RW script that I run before doing sysupgrade / syspatch etc. >Also make the Filesystems RW before rebooting. > > > > >-Original Message- >From: owner-m...@openbsd.org On Behalf Of Joe >Barnett >Sent: Wednesday, 10 June 2020 8:02 AM >To: Vertigo Altair >Cc: Misc >Subject: Re: OpenBSD Readonly File System > >On 2020-06-09 00:59, Vertigo Altair wrote: >> Hi Misc, >> I have a firewall device and I'm using OpenBSD on it. There is an >> electricity problem where the device runs. Therefore, I have to run >> the "fsck -y" command regularly at startup due to the electricity >problem. >> To >> overcome this, I want to use readonly file system. >> I know there are some projects like "resflash", but I want to do >that >> manually. > >I have hacked and slashed my way to this kind of configuration for my >firewall/gateway and a few other machines -- and with what appears to >be good results. Please understand this is almost certainly not >supported by the project. I have outlined this at the following URL: > >https://www.mr72.com/readonlyfs.html > >I hope this helps. Any feedback will be greatly appreciated. > >Good luck! > >Joe > >> My partitions like this; >> >> vertigo# df -h >> Filesystem SizeUsed Avail Capacity Mounted on >> /dev/sd0a 3.9G489M3.2G13%/ >> /dev/sd0g 91.8G1.0G 86.2G 1%/mypartition >> /dev/sd0d 989M 12.0K940M 0%/tmp >> /dev/sd0f 3.9G1.7G2.0G46%/usr >> /dev/sd0e 3.9G 46.9M3.6G 1%/var >> >> I want to / and /usr as readonly, I updated /etc/fstab and I made / >> and /usr readonly; >> >> vertigo# cat /etc/fstab >> ec347fefe8d05509.b none swap sw >> ec347fefe8d05509.a / ffs ro 1 1 >> ec347fefe8d05509.g /mypartition ffs rw,nodev,nosuid 1 2 >> ec347fefe8d05509.d /tmp ffs rw,nodev,nosuid 1 2 ec347fefe8d05509.f >> /usr ffs ro,wxallowed,nodev 1 2 ec347fefe8d05509.e /var ffs >> rw,nodev,nosuid 1 2 >> >> >> On startup following errors comming from /etc/rc; I think errors >about >> /etc/motd are not so important, but are the errors coming from >> /etc/tty* >> can cause any problems? If my method is not correct, what is the best > >> way to do this? >> OpenBSD/amd64 BOOTX64 3.50 >> boot> >> booting hd0a:/bsd: 12957000+2753552+327712+0+708608 >> [807408+128+1024872+749630]=0x1271a18 >> entry point at 0x1001000 >> [ using 2583064 bytes of bsd ELF symbol table ] Copyright (c) 1982, >> 1986, 1989, 1991, 1993 >> The Regents of the University of California. All rights >> reserved. >> Copyright (c) 1995-2020 OpenBSD. All rights reserved. >> https://www.OpenBSD.org >> >> OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun 4 09:55:08 MDT 2020 >> >> >r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GEN >> ERIC.MP >> real mem = 4151607296 (3959MB) >> avail mem = 4013170688 (3827MB) >> mpath0 at root >> scsibus0 at mpath0: 256 targets >> mainbus0 at root >> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf10 (14 entries) >> bios0: vendor American Megatrends Inc. version "BAR3NA05" date >> 07/23/2018 >> bios0: NF533 NF533 >> acpi0 at bios0: ACPI 5.0 >> acpi0: sleep states S0 S3 S4 S5 >> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG LPIT HPET SSDT SSDT SSDT >> UEFI >> acpi0: wakeup devices XHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) >> acpitimer0 at acpi0: 3579545 Hz, 24 bits >> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat >> cpu0 at mainbus0: apid 0 (boot processor) >> cpu0: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.37 MHz, 06-37-09 >> cpu0: >> >FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3 >> >6,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MW >> >AIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT >>
Re: __printflike macro on OpenBSD
Theo de Raadt wrote: > sensiblehue wrote: > > > On Thu, Jun 11, 2020 at 03:08:01PM +0200, Marc Espie wrote: > > > On Thu, Jun 11, 2020 at 04:37:34AM +, sensiblehue wrote: > > > > Hello, > > > > I was wondering why OpenBSD doesn't have a `__printflike' macro in > > > > ? FreeBSD, NetBSD, and DragonflyBSD have it and it's also > > > > available from libbsd on Linux. > > > > Personally I think it's cleaner and just as portable if not more > > > > portable, because some compilers don't support `__attribute__'. > > > > > > > > > What compilers ? > > > > GCC < v2.5 and non GNU C compilers, though I see now that OpenBSD > > defines it to nothing in that case. > > Ah, so it does actually work fine, unlike what you originally claimed. > > > > To be honest I'm mostly suggesting __printflike because I want to use it > > in my own code and still have it compile on OpenBSD without an #ifdef, > > but it would also make software from other BSDs easier to port. > > We are using the attribute mechanism directly in a way that works on > all modern (10 years?). > > Intentionally. Let me reiterate why it is used directly. You probably understand, but I'm not sure you see the value. 1. If the compiler supports attributes but does not know this one, the code compiles, the special handling isn't done, and everything works. 2. If the compiler supports attributes but and knows it, the special handling is performed, and everything works. 3. If the compiler is so old that it doesn't handle unsupported attributes, go use a different (new) compiler. You say you want to use an old compiler which doesn't handle unknown attributes? How will you cope with all the operating systems which lack the #define you request?
Re: __printflike macro on OpenBSD
sensiblehue wrote: > On Thu, Jun 11, 2020 at 03:08:01PM +0200, Marc Espie wrote: > > On Thu, Jun 11, 2020 at 04:37:34AM +, sensiblehue wrote: > > > Hello, > > > I was wondering why OpenBSD doesn't have a `__printflike' macro in > > > ? FreeBSD, NetBSD, and DragonflyBSD have it and it's also > > > available from libbsd on Linux. > > > Personally I think it's cleaner and just as portable if not more > > > portable, because some compilers don't support `__attribute__'. > > > > > > What compilers ? > > GCC < v2.5 and non GNU C compilers, though I see now that OpenBSD > defines it to nothing in that case. Ah, so it does actually work fine, unlike what you originally claimed. > To be honest I'm mostly suggesting __printflike because I want to use it > in my own code and still have it compile on OpenBSD without an #ifdef, > but it would also make software from other BSDs easier to port. We are using the attribute mechanism directly in a way that works on all modern (10 years?). Intentionally. Your proposal requires everyone to eventually have a new cpp symbol. You start by requiring us to have the symbol, then you'll go after the next people? Why are you asking us before you ask Microsoft?
Re: __printflike macro on OpenBSD
On Thu, Jun 11, 2020 at 03:08:01PM +0200, Marc Espie wrote: > On Thu, Jun 11, 2020 at 04:37:34AM +, sensiblehue wrote: > > Hello, > > I was wondering why OpenBSD doesn't have a `__printflike' macro in > > ? FreeBSD, NetBSD, and DragonflyBSD have it and it's also > > available from libbsd on Linux. > > Personally I think it's cleaner and just as portable if not more > > portable, because some compilers don't support `__attribute__'. > > > What compilers ? GCC < v2.5 and non GNU C compilers, though I see now that OpenBSD defines it to nothing in that case. What could be an issue is that the `format' attribute appeared in GCC v2.7, and invalid attributes generate a warning. To be honest I'm mostly suggesting __printflike because I want to use it in my own code and still have it compile on OpenBSD without an #ifdef, but it would also make software from other BSDs easier to port.
Re: __printflike macro on OpenBSD
On Thu, Jun 11, 2020 at 06:22:55PM +, sensiblehue wrote: > On Thu, Jun 11, 2020 at 03:08:01PM +0200, Marc Espie wrote: > > On Thu, Jun 11, 2020 at 04:37:34AM +, sensiblehue wrote: > > > Hello, > > > I was wondering why OpenBSD doesn't have a `__printflike' macro in > > > ? FreeBSD, NetBSD, and DragonflyBSD have it and it's also > > > available from libbsd on Linux. > > > Personally I think it's cleaner and just as portable if not more > > > portable, because some compilers don't support `__attribute__'. > > > > > > What compilers ? > > GCC < v2.5 and non GNU C compilers, though I see now that OpenBSD > defines it to nothing in that case. What could be an issue is that the > `format' attribute appeared in GCC v2.7, and invalid attributes > generate a warning. clang has full support for attributes, so your statement is somewhat false.
Re: 6.7 trouble reaching ipmi on supermicro atom
> On May 31, 2020, at 6:07 PM, obs...@loopw.com wrote: > > ipmitool is timing out on my system with the kernel driver loaded, where I > havent seen this in previous releases. > > I looked at the changes in 6.7 for ipmi.c, there's a number of them (thank > you!) My intention is to bisect for which change may have caused this, but > if someone knows what’s going on, I’m all ears. I didn’t have to bisect! Woo! While ipmitool no longer seems to function, once I enable ipmi in my running kernel I can successfully reboot a 6.7 ipmi-of-this-vintage system now - where previously, from 6.6 going back into late 4.x land, these systems would hang on reboot until I reset the BMC. I no longer have to create a custom /etc/rc.shutdown and other things that did evil stuff like reset the bmc just before rebooting the box in order to avoid a lockup. Oh right, my point: THANK YOU FOR FIXING UP THE IPMI CODE! THANK YOU!
Re: dmesg memory not match spdmem and bios
I just want to know why OpenBSD/i386 have the memory limit to 4G. Thanks for your reply. It is the design of OpenBSD/i386 is 32 bits OS not the hardware limitation. It is ok for me to run OpenBSD/amd64 on a i5 machine. Thanks Clarence Stuart Henderson () 在 2020年6月11日星期四 下午6:02:56 [GMT+8] 寫道： On 2020/06/11 05:04, man Chan wrote: > What make it different ? > > 1) arch==> i386 limit to 4G (dmesg) and spdmem show 8G , Bios show 8G > 2) arch==> amd64 memory show correct figure 8G (dmeag, spdmem and bios) > > 1 & 2 use the same machine with different arch. > > > So can I use the i5 core at i386 arch to use the correct size of memory > (i.e 8G) and how to make it work . You can't. OpenBSD/i386 is a 32-bit OS. This requires addresses that fit in 32 bits, that is the memory location is numbered 4294967295 (2^32) or lower. You are already seeing all the memory that can work with the 32-bit kernel. Why do you want to run i386 anyway? There are many downsides (less supported memory, fewer CPU registers which means that many programs run slower, fewer secury mitigations are available, more limited in terms of what software you can run on it, etc). To me, the only reason for running i386 on amd64-capable hardware is to compile software on a fast new machine to run on other old machines that can't run a 64-bit OS..
Re: dmesg memory not match spdmem and bios
On 6/11/2020 8:57 AM, man Chan wrote: > I just want to know why OpenBSD/i386 have the memory limit to 4G. All operating systems have this limit. The 80386 was released to the public in 1986, when 4 GB was an absurd amount of memory. > It is ok for me to run OpenBSD/amd64 on a i5 machine. Thanks Yes. Intel bet on Itanium/IA-64 for their 64-bit architecture. Meanwhile, AMD designed their own 64-bit architecture that extended x86. Intel wound up licensing AMD's 64-bit architecture, which at the time was called Intel 64 or EM64T. Your i5 processor uses Intel 64, which is compatible with amd64.
Re: iked keeps reconnecting every 8 minutes
> I seems I got it wrong before. Even when there was ESP traffic, iked is going
> to start DPD when there hasn't been any incoming IKE message in the last
> 5 minutes.
>
> My advice would be to just disable DPD in iked for this specific case.
> To do this you will have to patch it and build it from the sources.
> Below is a diff that should do the trick.
>
> Index: ikev2.c
> ===
> RCS file: /cvs/src/sbin/iked/ikev2.c,v
> retrieving revision 1.231
> diff -u -p -r1.231 ikev2.c
> --- ikev2.c 9 Jun 2020 21:53:26 - 1.231
> +++ ikev2.c 10 Jun 2020 11:02:39 -
> @@ -4391,7 +4391,7 @@ ikev2_ike_sa_alive(struct iked *env, voi
>* SA, or if we haven't received an IKE message. but only if we
>* are not already waiting for an answer.
>*/
> - if (((!foundin && foundout) || ikeidle) &&
> + if ((!foundin && foundout) &&
> (sa->sa_stateflags & (IKED_REQ_CHILDSA|IKED_REQ_INF)) == 0) {
> log_debug("%s: sending alive check", __func__);
> ikev2_send_ike_e(env, sa, NULL, IKEV2_PAYLOAD_NONE,
Thank you very much, the patch did the trick. No reconnection since yesterday.
As it is in production, this system is following syspatches only. If there
ever is a syspatch on iked for another problem, I assume I would have to
reapply this patch, right?
Re: __printflike macro on OpenBSD
On Thu, Jun 11, 2020 at 04:37:34AM +, sensiblehue wrote: > Hello, > I was wondering why OpenBSD doesn't have a `__printflike' macro in > ? FreeBSD, NetBSD, and DragonflyBSD have it and it's also > available from libbsd on Linux. > Personally I think it's cleaner and just as portable if not more > portable, because some compilers don't support `__attribute__'. What compilers ?
Re: dmesg memory not match spdmem and bios
On 2020/06/11 05:04, man Chan wrote: > What make it different ? > > 1) arch==> i386 limit to 4G (dmesg) and spdmem show 8G , Bios show 8G > 2) arch==> amd64 memory show correct figure 8G (dmeag, spdmem and bios) > > 1 & 2 use the same machine with different arch. > > > So can I use the i5 core at i386 arch to use the correct size of memory > (i.e 8G) and how to make it work . You can't. OpenBSD/i386 is a 32-bit OS. This requires addresses that fit in 32 bits, that is the memory location is numbered 4294967295 (2^32) or lower. You are already seeing all the memory that can work with the 32-bit kernel. Why do you want to run i386 anyway? There are many downsides (less supported memory, fewer CPU registers which means that many programs run slower, fewer secury mitigations are available, more limited in terms of what software you can run on it, etc). To me, the only reason for running i386 on amd64-capable hardware is to compile software on a fast new machine to run on other old machines that can't run a 64-bit OS..
Adding a reference to the -Oz option to gcc-local(1)
Hi everyone, Recently, while I was browsing through OpenBSD's CVS history, I came across a few usages of the -Oz build option (apparently suggesting that LLVM is not as good at optimizing for size as GCC is, but that's not very relevant to this email - even if it's true, which I'm not exactly sure of) and one commit message mentioning that GCC now also supports this option (as an alias for -Os). I wonder, then, if it would be wise for you to mention this in the gcc-local(1) man page, as it seems to be OpenBSD-specific functionality (I found the commit for GCC 3.3.6 and assume there's a similar one for GCC 4.2.1). This is the kind of thing that's useful to know for people writing makefiles and the like. I'll certainly be using -Oz if I want to optimize for size on any hardware platform for now on, but others may not be aware and might unnecessarily stick with -Os just to be safe (and miss out on getting the smallest possible code size out of LLVM). Obviously it's not a matter of life and death, but given OpenBSD's generally excellent documentation this came across as a minor omission to me. While I'm at it (and now that I've mentioned GCC 3.3.6): good job keeping OpenBSD luna88k alive and kicking, guys! As far as I can tell OpenBSD is the only operating system still putting out new releases for this weird but cool system. I'd still love to obtain one myself some day, but I've already more or less accepted the fact that it won't happen. Still, if anyone just happens to have a working system lying around and wants to sell it, I'd be very interested! Yeah, I know it's a long shot, but I figured trying and failing is better than not trying at all... ;) Regards, Jorden
Re: dmesg memory not match spdmem and bios
What make it different ? 1) arch==> i386 limit to 4G (dmesg) and spdmem show 8G , Bios show 8G 2) arch==> amd64 memory show correct figure 8G (dmeag, spdmem and bios) 1 & 2 use the same machine with different arch. So can I use the i5 core at i386 arch to use the correct size of memory (i.e 8G) and how to make it work . Thanks clarence Theo de Raadt () 在 2020年6月11日星期四 上午9:18:43 [GMT+8] 寫道： i386 showed the correct amount of memory *it could use*. man Chan wrote: > Thanks. I tried to use amd64 which show the correct memory size. > Is there a way to use i386 to show the correct size of memory ? The bios > shows 8G memory. Did I miss something to make it ? > Clarence > > Stuart Henderson () 在 2020年6月11日星期四 上午12:41:40 >[GMT+8] 寫道： > > On 2020-06-10, man Chan wrote: > > You mean the memory limitation of i386 is 4G. Am I right ? > > A 32-bit kernel can only access memory mapped to addresses below 4GB. > > The actual amount of memory that you can use depends on where the > BIOS/UEFI maps the memory (it reserves some addresses for device i/o > etc). > > That's why you see a lower "available memory" amount than 4GB. > >
Re: Protectli FW1 with Intel 82583V - Interfaces errors and latency spike issue
After extensive testing the latency spikes shown up again: To the inside interface of the firewall: Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=132ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 And to the firewall's next hop (ISP ONT) at the same time: Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 Reply from 74.215.235.1: bytes=32 time=242ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 Interface errors are now showing up just as output: #netstat -i NameMtu Network Address Ipkts IfailOpkts Ofail Colls em0 1500XX:XX:XX:XX:XX:XX22655 041589 0 0 em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX22655 041589 0 0 em1 1500XX:XX:XX:XX:XX:XX39924 020476 1 0 em1 1500 172.16.200. XX:XX:XX:XX:XX:XX39924 020476 1 0 em2 1500XX:XX:XX:XX:XX:XX 427 0 330 2 0 em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX 427 0 330 2 0 em3*1500XX:XX:XX:XX:XX:XX0 00 0 0 enc0* 00 00 0 0 pflog0 331360 0 1294 0 0 UDP real time traffic is the most affected one as very sensitive and I keep \ having spikes meanwhile playing online. Thank you! Gabri On 2020-06-10 22:46, Gabri Tofano wrote: That's funny because when I received your e-mail I was almost done in installing OpenBSD 6.6. Another user pointed out to me that in the OpenBSD 6.7 release notes there is a statement in regards of the em(4) drivers: "Improvements in the em(4) driver." and so I have gave it a try. It looks like that the system is now stable and latency spikes/interface errors are not present at all even under heavy traffic loads. I am going to update the message in the OpenBSD-bug mailing list and maybe one of the dev can take a look at it now that we have more info. Thank you for sharing your experience! On 2020-06-10 21:59, obs...@loopw.com wrote: I have a small fleet of protectli firewalls, all of them with em nics. Only the units i’ve upgraded to 6.7 are showing interface errors, where 6.6 is definitely not. On Jun 8, 2020, at 5:30 PM, Gabri Tofano wrote: Hi all, I'm sending this e-mail since I have found other users in this mailing-list using the same device without issues. I'm using a "Protectli FW1" with FreeBSD 12.1 amd64 as a firewall which is serving me with great performances and no issues at all. The appliance has 4 Intel Gigabit 82583V Ethernet NIC ports which are working very well under FreeBSD 12.1. I have used PFsense as well prior to FreeBSD and it worked without issues too. I took the decision to move to OpenBSD 6.7 amd64 in order to benefit of the latest pf (and other) features but unfortunately the OS is giving me an issue which I guess is related to the NIC drivers; When I was connected via ssh I felt some glitches meanwhile I was typing/moving around with the editor, so I started to ping the inside interface from my wired connected pc and found out that time to time the appliance is responding with a 100+/200+ ms response (I have cut some 1ms reply to make it shorter): Reply from 172.16.200.1: bytes=32 time=1ms TTL=254
Re: Protectli FW1 with Intel 82583V - Interfaces errors and latency spike issue
That's funny because when I received your e-mail I was almost done in installing OpenBSD 6.6. Another user pointed out to me that in the OpenBSD 6.7 release notes there is a statement in regards of the em(4) drivers: "Improvements in the em(4) driver." and so I have gave it a try. It looks like that the system is now stable and latency spikes/interface errors are not present at all even under heavy traffic loads. I am going to update the message in the OpenBSD-bug mailing list and maybe one of the dev can take a look at it now that we have more info. Thank you for sharing your experience! On 2020-06-10 21:59, obs...@loopw.com wrote: I have a small fleet of protectli firewalls, all of them with em nics. Only the units i’ve upgraded to 6.7 are showing interface errors, where 6.6 is definitely not. On Jun 8, 2020, at 5:30 PM, Gabri Tofano wrote: Hi all, I'm sending this e-mail since I have found other users in this mailing-list using the same device without issues. I'm using a "Protectli FW1" with FreeBSD 12.1 amd64 as a firewall which is serving me with great performances and no issues at all. The appliance has 4 Intel Gigabit 82583V Ethernet NIC ports which are working very well under FreeBSD 12.1. I have used PFsense as well prior to FreeBSD and it worked without issues too. I took the decision to move to OpenBSD 6.7 amd64 in order to benefit of the latest pf (and other) features but unfortunately the OS is giving me an issue which I guess is related to the NIC drivers; When I was connected via ssh I felt some glitches meanwhile I was typing/moving around with the editor, so I started to ping the inside interface from my wired connected pc and found out that time to time the appliance is responding with a 100+/200+ ms response (I have cut some 1ms reply to make it shorter): Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=163ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=2ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=3ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=43ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=4ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=257ms TTL=254 With FreeBSD 12.1 is steady at <1/1ms all the time and even under load. As an online gamer as well, I felt the glitches meanwhile playing few online FPS games using OpenBSD 6.7 on the appliance. Looking at the interface statistics on OpenBSD I found out that inbound/outbound errors are present (this has been taken after few minutes of a reinstall to test it again): FRW-FW1# netstat -i NameMtu Network Address Ipkts IfailOpkts Ofail Colls em0 1500xx:xx:xx:xx:xx:xx1317600 2351 466114 0 0 em0 1500 74.215.235/ xxx.xxx.xxx.xxx 1317600 2351 466114 0 0 em1 1500xx:xx:xx:xx:xx:xx39278218 1199871 1 0 em1 1500 172.16.200. 172.16.200.1 39278218 1199871 1 0 em2 1500xx:xx:xx:xx:xx:xx156055 1 0 em2 1500 172.16.103/ 172.16.103.254 156055 1 0 em3*1500xx:xx:xx:xx:xx:xx 0 0 0 0 0 enc0* 0 0 0 0 0 0 pflog0 33136 0 0 0 0 0 Looking at the Cisco 3560G where the ports are connected there are no errors at all. I have also doublechecked the drivers and the firmware installed by fw_update are the following: vmm-firmware-1.11.0p2 inteldrm-firmware-20181218 intel-firmware-20200508v0 I have done multiple reinstall with different OS to make sure
