Re: i386, parallel port permission error?
Stuart Henderson wrote: > On 2020-08-17, Doug Moss wrote: > > > > Is it possible with OpenBSD i386 to use the parallel port for lcdproc? > > > > More specifically: > > Did something change at OpenBSD i386 between 5.9 and 6.0 > > related to parallel port / lpt hardware permissions? > > > > Up to OpenBSD i386 5.9, > > I used to be able to have a working case-LCD-screen > > with lcdproc-0.5.7, driver=hd44780, winamp wiring, with 'allowaperture'. > > At OpenBSD i386 6.0 and after, it fails. > > I think this is due to kernel memory access restrictions that were added. > Setting sysctl kern.allowkmem=1 before securelevel is raised bypasses them > but of course weakens protections. Oh good god, it's not lpt access, but direct hardware access? I think we should not be encouraging people to use kern.allowkmem for anything like this.
Re: Protectli FW1 with Intel 82583V - Interfaces errors and latency spike issue
On 2020-08-17, Gabri Tofano wrote: 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 "fail" isn't the same thing as interface errors, you can break it out into "dropped" (-d) and "errors" (-e). Looking at the Cisco 3560G where the ports are connected there are no errors at all. Not surprising as the (errors/drops) are at input on the OpenBSD system. Here the dmesg output: These may give clues: systat mbuf | cat pfctl -si netstat -m vmstat -m 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/GENERIC.MP real mem = 4163854336 (3970MB) avail mem = 4025044992 (3838MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xecea0 (51 entries) bios0: vendor American Megatrends Inc. version "5.6.5" date 10/24/2018 bios0: Protectli FW1 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 PS2K(S3) PS2M(S3) XHC1(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) BRCM(S0) 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.47 MHz, 06-37-09 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 1MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 83MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.01 MHz, 06-37-09 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.03 MHz, 06-37-09 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu2: 1MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.01 MHz, 06-37-09 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu3: 1MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 87 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 3 (RP03) acpiprt4 at acpi0: bus 4 (RP04) acpiec0 at acpi0: not present acpicpu0 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PLPE
i386, parallel port permission error?
Is it possible with OpenBSD i386 to use the parallel port for lcdproc?
More specifically:
Did something change at OpenBSD i386 between 5.9 and 6.0
related to parallel port / lpt hardware permissions?
Up to OpenBSD i386 5.9,
I used to be able to have a working case-LCD-screen
with lcdproc-0.5.7, driver=hd44780, winamp wiring, with 'allowaperture'.
At OpenBSD i386 6.0 and after, it fails.
I have a computer case with a builtin LCD screen.
(Actually a VFD - vacuum fluorescent display)
Silverstone LC03V, has a Samsung 16T202DA1E, which uses the HD44780 protocol
with a cable from the 14 pins on the 16T202DA1E connected to a parallel
port DB25 in the 'winamp' pin wiring style.
The motherboard is an Intel D2700MUD with a parallel port on back panel.
Stripped to the essentials:
- install OpenBSD i386
- lcdproc-0.5.7.tar.gz from sourceforge
compile from source, because package does not include proper hd44780,
and I only needed the LCDd server and the hd44780.so driver
./configure --sysconfdir=/etc/ --enable-drivers=hd44780
cd shared; make
cd server; make
only need:
LCDd (to /usr/local/sbin )
hd44780.so (/usr/local/lib/lcdproc )
created a simple /etc/LCDd.conf, including importantly
Driver=hd44780, ConnectionType=winamp
For OpenBSD i386 (5.8 and 5.9), there seemed to be a permissions issue on the
0x378.
So the tweak that I had to use in the past was to 'allowaperture'
/etc/sysctl.conf
machdep.allowaperture=1
by OS release:
5.9/i386 fail: hd44780: cannot get IO-permission for 0x378: Operation not
permitted
5.9/i386 w/sysctl.conf machdep.allowaperture=1 : ***works***
(for the following these are with machdep.allowaperture=1)
6.0/i386 fail: hd44780: cannot get IO-permission for 0x378: No such file or
directory
6.1/i386 fail: hd44780: cannot get IO-permission for 0x378: No such file or
directory
6.3/i386 fail: hd44780: cannot get IO-permission for 0x378: No such file or
directory
6.7/i386 fail: hd44780: cannot get IO-permission for 0x378: No such file or
directory
I noted that previously (5.8 and 5.9), without allowaperture,
there was a warning "Operation not permitted" that was fixed with
'allowaperture'.
After 6.0, the warning says "No such file or directory"
Also I saw some web pages suggesting 'securelevel' may be a problem
for low level device interfacing, so I tried
6.0/i386 with /etc/rc.securelevel
/usr/local/sbin/LCDd -u root -r 5
This still fails.
Could tell me if they know about this parallel port issue and if there is a fix?
Thanks very much
/var/log/messages has:
LCDd: LCDd version 0.5.7 starting
LCDd: Built on Aug 2 2020, protocol version 0.3, API version 0.5
LCDd: Using Configuration File: /etc/LCDd.conf
LCDd: Set report level to 5, output to syslog
LCDd: Server forking to background
LCDd: Listening for queries on 127.0.0.1:13666
LCDd: HD44780: using ConnectionType: winamp
LCDd: hd44780: Using hd44780_default charmap
LCDd: hd44780: cannot get IO-permission for 0x378: No such file or directory
LCDd: Driver [hd44780] init failed, return code -1
LCDd: Module /usr/local/lib/lcdproc/hd44780.so could not be loaded
LCDd: Could not load driver hd44780
LCDd: There is no output driver
LCDd: Critical error while initializing, abort
dmesg for OpenBSD 5.9 i386:
OpenBSD 5.9 (GENERIC.MP) #1616: Fri Feb 26 01:28:13 MST 2016
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
RTC BIOS diagnostic error 80
cpu0: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz ("GenuineIntel" 686-class) 2.13 GHz
cpu0:
FPU,V86,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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF,ITSC,SENSOR,ARAT
real mem = 3206651904 (3058MB)
avail mem = 3132657664 (2987MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 12/27/11, SMBIOS rev. 2.7 @ 0xbf298000 (28 entries)
bios0: vendor Intel Corp. version "MUCDT10N.86A.0067.2011.1227.1232" date
12/27/2011
bios0: Intel Corporation D2700MUD
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC MCFG HPET
acpi0: wakeup devices SLT1(S4) PS2M(S4) PS2K(S4) UAR1(S3) UAR2(S3) USB0(S3)
USB1(S3) USB2(S3) USB3(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4)
PXSX(S4) RP03(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
cpu0: mwait min=64, max=64, C-substates=0.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz ("GenuineIntel" 686-class) 2.13 GHz
cpu1:
FPU,V86,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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF,ITSC,SENSOR,ARAT
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pin
Re: Firefox Security 2020
On 2020-08-14, Kevin Chadwick wrote: > With the recent news. I decided to take a look again at Firefox and after a > days > use on multiple systems, it even seems to be faster than Chrome. > > I notice significant work on pledge support. Does anyone know if it's > comparable > to Chrome on that front now or still held back by not being designed with > isolation in mind? Run "ps -O pledge" with both running and see what you think. (Shorter pledge list = more restricted).
Re: CPU usage of httpd+slowcgi
On 2020-08-16, Kihaguru Gathura wrote: > Hi, > > It depends on the workload. I'd have thought for most things the max >> really usable at the moment is probably somewhere in the region of 4-8 >> cpu cores before kernel locking gets in the way too much. >> >> FWIW sparc64 ports builds are now done on T4 and they're really fast. >> I think (but am not 100% sure) that this is carved into ldoms so the >> number of cores visible to each OpenBSD instance is limited (so >> contention between cores in the kernel is also limited). >> >> > Up to how many cores will it be guaranteed that kernel locking 'will not > get too much in the way' for hardware running a single instance of OpenBSD > under heavy workload? > > Kind Regards, > > Kihaguru. > There are no guarantees.
Re: i386, parallel port permission error?
On 2020-08-17, Doug Moss wrote: > > Is it possible with OpenBSD i386 to use the parallel port for lcdproc? > > More specifically: > Did something change at OpenBSD i386 between 5.9 and 6.0 > related to parallel port / lpt hardware permissions? > > Up to OpenBSD i386 5.9, > I used to be able to have a working case-LCD-screen > with lcdproc-0.5.7, driver=hd44780, winamp wiring, with 'allowaperture'. > At OpenBSD i386 6.0 and after, it fails. I think this is due to kernel memory access restrictions that were added. Setting sysctl kern.allowkmem=1 before securelevel is raised bypasses them but of course weakens protections.
Re: Tunefs(8)
On Tue, Aug 11, 2020 at 2:07 AM Rupert Gallagher wrote: > > Omit the last line of the manual, because there is no need for it. > Well of course there's no need for it, but why on Earth should that mean that it shouldn't be there? -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: i386, parallel port permission error?
You'll need to chown/chmod it narrowly to the uid who wants to use it.
You want to constrain use of the device driver as much as you can.
>Is it possible with OpenBSD i386 to use the parallel port for lcdproc?
>
>More specifically:
>Did something change at OpenBSD i386 between 5.9 and 6.0
>related to parallel port / lpt hardware permissions?
>
>Up to OpenBSD i386 5.9,
>I used to be able to have a working case-LCD-screen
>with lcdproc-0.5.7, driver=hd44780, winamp wiring, with 'allowaperture'.
>At OpenBSD i386 6.0 and after, it fails.
>
>
>
>I have a computer case with a builtin LCD screen.
>(Actually a VFD - vacuum fluorescent display)
>Silverstone LC03V, has a Samsung 16T202DA1E, which uses the HD44780 protocol
>with a cable from the 14 pins on the 16T202DA1E connected to a parallel
>port DB25 in the 'winamp' pin wiring style.
>The motherboard is an Intel D2700MUD with a parallel port on back panel.
>
>
>Stripped to the essentials:
>- install OpenBSD i386
>- lcdproc-0.5.7.tar.gz from sourceforge
>compile from source, because package does not include proper hd44780,
>and I only needed the LCDd server and the hd44780.so driver
>./configure --sysconfdir=/etc/ --enable-drivers=hd44780
>cd shared; make
>cd server; make
>only need:
>Â LCDd (to /usr/local/sbin )
>Â hd44780.so (/usr/local/lib/lcdproc )
>Â created a simple /etc/LCDd.conf, including importantly
>Â Driver=hd44780, ConnectionType=winamp
>
>
>For OpenBSD i386 (5.8 and 5.9), there seemed to be a permissions issue on the
>0x378.
>So the tweak that I had to use in the past was to 'allowaperture'
>/etc/sysctl.conf
>machdep.allowaperture=1
>
>
>by OS release:
>5.9/i386Â Â fail: hd44780: cannot get IO-permission for 0x378: Operation not
>permitted
>5.9/i386Â w/sysctl.conf machdep.allowaperture=1Â :Â ***works***
>
>(for the following these are with machdep.allowaperture=1)
>6.0/i386Â Â fail: hd44780: cannot get IO-permission for 0x378: No such file
>or directory
>6.1/i386Â Â fail: hd44780: cannot get IO-permission for 0x378: No such file
>or directory
>6.3/i386Â Â fail: hd44780: cannot get IO-permission for 0x378: No such file
>or directory
>6.7/i386Â Â fail: hd44780: cannot get IO-permission for 0x378: No such file
>or directory
>
>I noted that previously (5.8 and 5.9), without allowaperture,
>there was a warning "Operation not permitted" that was fixed with
>'allowaperture'.
>After 6.0, the warning says "No such file or directory"
>
>
>Also I saw some web pages suggesting 'securelevel' may be a problem
>for low level device interfacing, so I tried
>6.0/i386 with /etc/rc.securelevel
>/usr/local/sbin/LCDd -u root -r 5
>
>This still fails.
>
>Could tell me if they know about this parallel port issue and if there is a
>fix?
>
>Thanks very much
>
>
>
>
>/var/log/messages has:
>LCDd: LCDd version 0.5.7 starting
>LCDd: Built on Aug 2 2020, protocol version 0.3, API version 0.5
>LCDd: Using Configuration File: /etc/LCDd.conf
>LCDd: Set report level to 5, output to syslog
>LCDd: Server forking to background
>LCDd: Listening for queries on 127.0.0.1:13666
>LCDd: HD44780: using ConnectionType: winamp
>LCDd: hd44780: Using hd44780_default charmap
>LCDd: hd44780: cannot get IO-permission for 0x378: No such file or directory
>LCDd: Driver [hd44780] init failed, return code -1
>LCDd: Module /usr/local/lib/lcdproc/hd44780.so could not be loaded
>LCDd: Could not load driver hd44780
>LCDd: There is no output driver
>LCDd: Critical error while initializing, abort
>
>
>
>dmesg for OpenBSD 5.9 i386:
>OpenBSD 5.9 (GENERIC.MP) #1616: Fri Feb 26 01:28:13 MST 2016
>Â Â Â dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
>RTC BIOS diagnostic error 80
>cpu0: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz ("GenuineIntel" 686-class) 2.13 GHz
>cpu0:
>FPU,V86,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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF,ITSC,SENSOR,ARAT
>real mem = 3206651904 (3058MB)
>avail mem = 3132657664 (2987MB)
>mpath0 at root
>scsibus0 at mpath0: 256 targets
>mainbus0 at root
>bios0 at mainbus0: date 12/27/11, SMBIOS rev. 2.7 @ 0xbf298000 (28 entries)
>bios0: vendor Intel Corp. version "MUCDT10N.86A.0067.2011.1227.1232" date
>12/27/2011
>bios0: Intel Corporation D2700MUD
>acpi0 at bios0: rev 2
>acpi0: sleep states S0 S3 S4 S5
>acpi0: tables DSDT FACP SSDT APIC MCFG HPET
>acpi0: wakeup devices SLT1(S4) PS2M(S4) PS2K(S4) UAR1(S3) UAR2(S3) USB0(S3)
>USB1(S3) USB2(S3) USB3(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4)
>PXSX(S4) RP03(S4) [...]
>acpitimer0 at acpi0: 3579545 Hz, 24 bits
>acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>cpu0 at mainbus0: apid 0 (boot processor)
>mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
>cpu0: apic clock running at 132MHz
>cpu0: mwait min=64, max=64, C-substates=0.1, IBE
>cpu1 at mainbus0: apid 2 (application processor)
>cpu1: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz ("GenuineIntel" 686-class) 2
Re: Protectli FW1 with Intel 82583V - Interfaces errors and latency spike issue
Were you able to resolve this issue? > On Jun 10, 2020, at 15: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 that this is >> related to OpenBSD 6.7 itself and found the following: >> >> PFsense 2.4.5: no issues at all >> FreeBSD 12.1: no issues at all >> OPNsense: interface errors >> OpenBSD: interface errors and interface latency spikes >> >> I have also swapped the ethernet cables and
Re: npppd failed enable pipex: Invalid argument
> On 10 Aug 2020, at 14:00, Marko Cupać wrote: > >>> On 4 Aug 2020, at 17:04, Marko Cupać wrote: >>> >>> Hi, >>> >>> I have recently upgraded (actually installed from scratch and copied >>> config files) one of my firewalls from 6.6 to 6.7, and (sys)patched >>> it to 017_dix. Everything works great except my npppd setup. It >>> starts fine, but upon connecting over pptp I get the following >>> records in log: >>> (...) >>> Aug 4 15:48:48 nat2 npppd[66557]: ppp id=0 layer=base failed >>> enable pipex: Invalid argument >> >> On Tue, 4 Aug 2020 18:31:44 +0300 >> Vitaliy Makkoveev wrote: >> >> In kernel timeout was disabled for pppx(4). Remove please >> "idle-timeout”. > > Sorry for late reply, I haven't had the chance to test until now. That > was it, after removing idle-timeout, npppd accepts pptp connections. > > Once again you saved me with npppd, thank you! Hello Marko. Can I propose you to try upcoming 6.8? We moved pppac(4) and pppx(4) output processing out of kernel lock. pppx(4) output is still serialised by netlock, but I hope we'll made it per-cpu before 6.8 release. Also, for curiosity reasons, what is your pppx(4) clients count?
Re: CPU usage of httpd+slowcgi
Hi, It depends on the workload. I'd have thought for most things the max > really usable at the moment is probably somewhere in the region of 4-8 > cpu cores before kernel locking gets in the way too much. > > FWIW sparc64 ports builds are now done on T4 and they're really fast. > I think (but am not 100% sure) that this is carved into ldoms so the > number of cores visible to each OpenBSD instance is limited (so > contention between cores in the kernel is also limited). > > Up to how many cores will it be guaranteed that kernel locking 'will not get too much in the way' for hardware running a single instance of OpenBSD under heavy workload? Kind Regards, Kihaguru.
Re: httpd - bypass tls misconfig different ciphers, ecdhe
On Sun, Aug 16, 2020 at 02:34:27PM -0400, trondd wrote: > Oh, I see what you're doing. BOTH listen lines are active in the second > server block. When you connect to port 443 with that config, which TLS > settings does it use? I want to guess that because you're lisening on > port 8000 without tls first, the listen with tls is skipped along with the > tls block below it. No, listen TLS isn't skipped for sub.domain.tld >> This indeed listen on same address ($ext_ip) and same port (443) >> and works as intended with different cipher and ecdhe.
Re: httpd - bypass tls misconfig different ciphers, ecdhe
On Sun, August 16, 2020 1:23 pm, hisacro wrote:
> Aug 16, 2020, 11:44 AM by tro...@kagu-tsuchi.com:
>
>> Because it's not the same IP and port anymore. You can only have one
>> thing listening on an ip+port
>
> I got a working httpd config with same IP and same Port
>
> server "domain.tld" {
> listen on $ext_ip tls port 443
> tls {
> certificate "/etc/ssl/domain.tld.fullchain.pem"
> key "/etc/ssl/private/domain.tld.key"
> ciphers "HIGH:!AES128:!kRSA:!aNULL"
> ecdhe "P-384,P-256,X25519"
> }
> }
> server "sub.domain.tld" {
> listen on 0.0.0.0 port 8000 # confusion?
> listen on $ext_ip tls port 443
> tls {
> certificate "/etc/ssl/domain.tld.fullchain.pem"
> key "/etc/ssl/private/domain.tld.key
> }
> }
>
> This indeed listen on same address ($ext_ip) and same port (443)
> and works as intended with different cipher and ecdhe.
> Note: only when I add listen on 0.0.0.0 port 8000
>
>>Httpd allows you to configure multiple
>>"servers" for subdomains but in reality there is one actual server
>>listening and it has to know what parameters to use
>
> Sorry, I don't understand your reasoning because
> shouldn't httpd work the same way with or without extra listen on 0.0.0.0
>
Oh, I see what you're doing. BOTH listen lines are active in the second
server block. When you connect to port 443 with that config, which TLS
settings does it use? I want to guess that because you're lisening on
port 8000 without tls first, the listen with tls is skipped along with the
tls block below it.
Re: httpd - bypass tls misconfig different ciphers, ecdhe
Aug 16, 2020, 11:44 AM by tro...@kagu-tsuchi.com:
> Because it's not the same IP and port anymore. You can only have one
> thing listening on an ip+port
I got a working httpd config with same IP and same Port
server "domain.tld" {
listen on $ext_ip tls port 443
tls {
certificate "/etc/ssl/domain.tld.fullchain.pem"
key "/etc/ssl/private/domain.tld.key"
ciphers "HIGH:!AES128:!kRSA:!aNULL"
ecdhe "P-384,P-256,X25519"
}
}
server "sub.domain.tld" {
listen on 0.0.0.0 port 8000 # confusion?
listen on $ext_ip tls port 443
tls {
certificate "/etc/ssl/domain.tld.fullchain.pem"
key "/etc/ssl/private/domain.tld.key
}
}
This indeed listen on same address ($ext_ip) and same port (443)
and works as intended with different cipher and ecdhe.
Note: only when I add listen on 0.0.0.0 port 8000
>Httpd allows you to configure multiple
>"servers" for subdomains but in reality there is one actual server
>listening and it has to know what parameters to use
Sorry, I don't understand your reasoning because
shouldn't httpd work the same way with or without extra listen on 0.0.0.0
Re: httpd - bypass tls misconfig different ciphers, ecdhe
Aug 16, 2020, 7:50 AM by tro...@kagu-tsuchi.com: >>On Sat, Aug 15, 2020 at 04:13:51PM -0700, hisacro wrote: > >> $ doas httpd -nv >> server "sub.domain.tld": tls configuration mismatch on same address/port >> >> instead of defining same cipher and ecdhe, uncommenting >> "listen on 0.0.0.0 port 8080" >> bypasses this error >> >> I'm unsure what causes this, can someone shed some light? > >It's what the error says. You're listening twice on the same ip and port >but with different tls blocks. Though I have emphasized enough (even on title), re-stating Why does having a listen statement on port bypasses tls misconfiguration.
