Re: VPN IKEv2 Traffic Flows Only One Direction
On 2020-11-16, Ian Timothy wrote:
> int_if = "em0"
>
> ext_if = "em1"
> ext_net = "23.X.X.128/29"
>
> gateway_ip_ext = "{ 23.X.X.129 }"
> gateway_ip_int = "{ 10.0.0.1 }"
>
> set skip on {lo, enc0}
>
> block return# block stateless traffic
> pass# establish keep-state
>
> pass out on $ext_if from $int_if:network to any nat-to ($ext_if:0)
...also you only nat for em0:network which doesn't cover your vpn range
>
>
> # --- server: sysctl net.inet.{ipcomp.enable,esp.enable,esp.udpencap} ---
>
> net.inet.ipcomp.enable=1
> net.inet.esp.enable=1
> net.inet.esp.udpencap=1
>
>
>
>
>
>
Re: OpenLDAP under 6.8 - no intermediate certs in chain
On 11/16/2020 12:08 AM, Paul B. Henson wrote: I just updated one of my servers running 6.7 to 6.8, and am having a problem with openldap. I have the intermediate cert and root CA in a file referenced by the openldap config: TLSCACertificateFile/etc/openldap/cabundle.crt Under 6.7 with the openldap port from that version, this results in the chain being served: Certificate chain 0 s:CN = ldap-netsvc.pbhware.com i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 i:O = Digital Signature Trust Co., CN = DST Root CA X3 2 s:O = Digital Signature Trust Co., CN = DST Root CA X3 i:O = Digital Signature Trust Co., CN = DST Root CA X3 However, under 6.8 with the newer openldap 2.4.53 port, only the server cert itself is being served, not the intermediate or root: Certificate chain 0 s:CN = ldap-netsvc.pbhware.com i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 This of course causes clients to fail to validate the server cert :(. I'm running openldap 2.4.53 on other operating systems and as far as I know there's no change in behavior with it. So I'm guessing there's an interoperability issue between openbsd libressl and openldap that's causing this problem? Do I need to configure something differently? Any other suggestions? Thanks much... I remember seeing this commit recently. Not sure if this is your problem or not. https://marc.info/?l=openbsd-cvs=160511882917510=2
Re: VPN IKEv2 Traffic Flows Only One Direction
On 2020-11-16, Ian Timothy wrote:
> I’ve been a long time user of OpenBSD, but this is the first time I’m trying
> to setup a VPN. I’m not sure what I’m doing wrong, or what should be the next
> step to troubleshoot. I’ve probably reviewed every IKEv2 how-to I can find.
>
> I need to end up with a configuration that will support several simultaneous
> roaming users connecting from anywhere they happen to be.
>
> Client:
> macOS 10.15.7
> Using builtin VPN client
>
> Server:
> OpenBSD 6.6
6.8 is recommended, iked has seen a lot of improvements since 6.6.
> em1 = 23.X.X.128/29
> em0 = 10.0.0.0/16
> enc0 = 10.1.0.0.16
enc0 should not be configured with an address
> From the client I can connect to 10.0.0.1 but anything outside that network
> traffic slows but does not return:
> # --- server: sysctl net.inet.{ipcomp.enable,esp.enable,esp.udpencap} ---
>
> net.inet.ipcomp.enable=1
> net.inet.esp.enable=1
> net.inet.esp.udpencap=1
net.inet.ip.forwarding?
Re: Large Filesystem
> On 15 Nov 2020, at 20:57, Kenneth Gober wrote: > On Sun, Nov 15, 2020 at 8:59 AM Mischa wrote: > >> On 15 Nov at 14:52, Otto Moerbeek wrote: >>> fsck wil get slower once you start filling it, but since your original >>> fs had about 104k files it expect it not getting too bad. If the speed >>> for your usecase is good as well I guess you should be fine. >> >> Will see how it behaves and try to document as much as possible. >> I can always install another BSD on it. ;) >> > > To give a very rough idea, here is a sample running fsck on an FFS2 > file system with a fairly large number of files: > > > $ df -ik /nfs/archive > > Filesystem 1K-blocks Used Avail Capacity iused ifree %iused > Mounted on > > /dev/sd1g 12308149120 7477490128 421525153664% 4800726 383546408 > 1% /nfs/archive > > $ doas time fsck -f /nfs/archive > > ** /dev/sd1g (6d3438729df51b22.g) (NO WRITE) > > ** Last Mounted on /nfs/archive > > ** Phase 1 - Check Blocks and Sizes > > ** Phase 2 - Check Pathnames > > ** Phase 3 - Check Connectivity > > ** Phase 4 - Check Reference Counts > > ** Phase 5 - Check Cyl groups > > 4800726 files, 934686266 used, 603832374 free (35534 frags, 75474605 > blocks, 0.0% fragmentation) > 3197.25 real35.86 user66.03 sys > > This is on older hardware, and not running the most recent release. > The server is a Dell PowerEdge 2900 with a PERC H700 controller, and > 4 WD Red Pro 8TB disks (WD8001FFWX-6) forming a RAID10 volume > containing 3 small 1TB file systems and 1 large 12TB file system. The > OS is OpenBSD 6.1/amd64. All the file systems on this volume are > mounted with the softdep option and the big one has noatime as well. > > The time to run fsck is really only an issue when the server reboots > unexpectedly (i.e. due to a power outage). Coming up after a proper > reboot or shutdown is very fast due to the file systems being clean. > A UPS can help avoid most of these power-related reboots. Alas, this > particular server was connected to a UPS with a bad battery so it has > rebooted due to power outages at least a half-dozen times this year, > each of them involving a fairly long fsck delay. I finally took the time > last week to replace the UPS batteries so going forward this should > be much less of a problem. I do recommend the use of a UPS (and > timely replacement of batteries when needed) if you are going to > host very large FFS2 volumes. > > I have never lost files due to a problem with FFS2 (or with FFS for that > matter), but that is no reason not to perform regular backups. For this > particular file system I only back it up twice a year, but the data on it > doesn't change often. File systems with more 'normal' patterns of usage > get backed up weekly. The practice of taking regular backups also helps > ensure that 'bit rot' is detected early enough that it can be corrected. Thank you for sharing your experience. Gives me some more confidence to just go for it. ;) Mischa
Re: Wrong net in vlan
> Am 15.11.2020 um 22:33 schrieb Mihai Popescu :
>
> Hint: show some dhcpd configs.
>From /etc/dhcpd.conf:
- - -
subnet 172.16.11.0 netmask 255.255.255.0 {
option routers 172.16.11.1;
range 172.16.11.100 172.16.11.200;
}
subnet 172.16.12.0 netmask 255.255.255.0 {
option routers 172.16.12.1;
range 172.16.12.100 172.16.12.200;
}
- - -
>From /etc/rc.conf.local:
- - -
dhcpd_flags="em0 em3 vlan11 vlan12 vlan13 vlan14 vlan15 vlan16"
- - -
Axel
---
PGP-Key: CDE74120 ☀ computing @ chaos claudius
signature.asc
Description: Message signed with OpenPGP
Re: OpenLDAP under 6.8 - no intermediate certs in chain
On 2020-11-16, Brad Smith wrote: > On 11/16/2020 12:08 AM, Paul B. Henson wrote: >> I just updated one of my servers running 6.7 to 6.8, and am having a >> problem with openldap. I have the intermediate cert and root CA in a >> file referenced by the openldap config: >> >> TLSCACertificateFile/etc/openldap/cabundle.crt >> >> Under 6.7 with the openldap port from that version, this results in the >> chain being served: >> >> Certificate chain >> 0 s:CN = ldap-netsvc.pbhware.com >> i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 >> 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 >> i:O = Digital Signature Trust Co., CN = DST Root CA X3 >> 2 s:O = Digital Signature Trust Co., CN = DST Root CA X3 >> i:O = Digital Signature Trust Co., CN = DST Root CA X3 >> >> However, under 6.8 with the newer openldap 2.4.53 port, only the server >> cert itself is being served, not the intermediate or root: >> >> Certificate chain >> 0 s:CN = ldap-netsvc.pbhware.com >> i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 >> >> This of course causes clients to fail to validate the server cert :(. >> >> I'm running openldap 2.4.53 on other operating systems and as far as I >> know there's no change in behavior with it. So I'm guessing there's an >> interoperability issue between openbsd libressl and openldap that's >> causing this problem? >> >> Do I need to configure something differently? Any other suggestions? >> >> Thanks much... > > > I remember seeing this commit recently. Not sure if this is your problem > or not. > > https://marc.info/?l=openbsd-cvs=160511882917510=2 > > Yes OpenLDAP is broken with TLS 1.3 server-side unless you have that commit (or build LibreSSL with TLS 1.3 server support disabled). As far as I can tell there's no method to disable TLS 1.3 via config.
Re: kernel relinking error
- Mail original -
> De: "sylvain saboua"
>
> After a full upgrade following the FAQ,
> and running the usual syspatch, pkg_add -u, pkg_check :
>
> dmesg highlights :
>
> random: boothowto does not indicate good seed
>
> cpu at mainbus0: not configured
> (see
> https://www.reddit.com/r/openbsd/comments/hab68w/how_can_i_enable_intel_hyperthreading_smt_back/
Simply # echo "bsd.mp" > /etc/boot.conf worked
> "eeprom" at iic0 addr 0x50 not configured
>
> efifb at mainbus0 not configured
>
> drm:pid23547:ivb_set_fifo_underrun_reporting *ERROR* [drm] *ERROR*
> uncleared fifo underrun on pipe A
> drm:pid23547:intel_cpu_fifo_underrun_irq_handler *ERROR* [drm]
> *ERROR* CPU pipe A FIFO underrun
> drm:pid23547:cpt_set_fifo_underrun_reporting *ERROR* [drm] *ERROR*
> uncleared pch fifo underrun on pch transcoder A
> drm:pid23547:intel_pch_fifo_underrun_irq_handler *ERROR* [drm]
> *ERROR* PCH transcoder A FIFO underrun
>
However there was also the minor mistake :
reorder_kernel: failed -- see /usr/share/relink/kernel/GENERIC.MP/relink.log
after # doas sha256 -h /var/db/kernel.SHA256 /bsd
and rebooting, I get the same error in the dmesg but different file :
(SHA256) /bsd: OK
LD="ld" sh makegap.sh 0x gapdummy.o
ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS}
ld: error: undefined symbol: sysctl_bounded_arr
>>> referenced by icmp6.c:1923 (/usr/src/sys/netinet6/icmp6.c:1923)
>>> icmp6.o:(icmp6_sysctl)
*** Error 1 in /usr/share/relink/kernel/GENERIC.MP (Makefile:1437 'newbsd':
@echo ld -T ld.script -X --warn-common -nopie -o newbsd '${SYSTE...)
> Sylvain S
6.7 > 6.8 upgrade log
After a full upgrade following the FAQ, and running the usual syspatch, pkg_add -u, pkg_check : dmesg highlights : random: boothowto does not indicate good seed cpu at mainbus0: not configured (see https://www.reddit.com/r/openbsd/comments/hab68w/how_can_i_enable_intel_hyperthreading_smt_back/ "eeprom" at iic0 addr 0x50 not configured efifb at mainbus0 not configured drm:pid23547:ivb_set_fifo_underrun_reporting *ERROR* [drm] *ERROR* uncleared fifo underrun on pipe A drm:pid23547:intel_cpu_fifo_underrun_irq_handler *ERROR* [drm] *ERROR* CPU pipe A FIFO underrun drm:pid23547:cpt_set_fifo_underrun_reporting *ERROR* [drm] *ERROR* uncleared pch fifo underrun on pch transcoder A drm:pid23547:intel_pch_fifo_underrun_irq_handler *ERROR* [drm] *ERROR* PCH transcoder A FIFO underrun Sylvain S dmesg.68 Description: Binary data
Re: support new
Hi, i don't care greatly if another developer wants to add this, but i advise against it. Talking to this person is a tedious job, he seems to not understand very well what you say or to not really listen. He is also quite bad at explaining stuff and it's hard to figure out what he is driving at. So i fear listing him might do our users a disservice. Yours, Ingo Emre Kal wrote on Mon, Nov 16, 2020 at 03:50:24AM +0100: > 0 > C Turkey > P > T Istanbul > Z 34330 > O Consultant > I Emre Kal > A Levent, Besiktas > M e...@tuta.io > U > B > X > N OpenBSD consulting and support. Experienced in OpenBSD httpd, > relayd and Packet Filter (PF).
Re: OpenLDAP under 6.8 - no intermediate certs in chain
On 2020-11-16, Stuart Henderson wrote: > Yes OpenLDAP is broken with TLS 1.3 server-side unless you have that > commit (or build LibreSSL with TLS 1.3 server support disabled). As far > as I can tell there's no method to disable TLS 1.3 via config. ...actually I have now added a workaround to the databases/openldap port in 6.8-stable to disable TLS 1.3, so either rebuild or wait for -stable packages and it should fix things.
Re: APU4 hardware network interfaces tied together
On 2020-11-15, Mihai Popescu wrote: > Hello, > > In the scenario of building a router with APU4, one interface is for wan, > the rest of three are free to use. > What is the most sane and performance wise ( CPU load, interface load, > etc.) way to tie together the remaining three interfaces as a switch, and > avoid using one IP class per interface? bridge(4), and add a vether to the bridge to hold the IP address (otherwise the IP will stop working if the port it's configured on goes down). > Is it better to use one for lan, leave the remaining two unused and cascade > a dumb switch for other lan connections? If there is a significant amount of traffic between machines on the bridged ports, it will be slowed down by the bridge. Also PF rules have to take the bridging into account. On the other hand, that might be want you want..
Re: OpenBSD 6.8 (release) guest (qemu/kvm) on Linux 5.9 host (amd64) fails with protection fault trap
On 16/11/2020 04:49, Bodie wrote: Can you show what is in /proc/cpuinfo in Linux host and possibly even its dmesg? Thanks for trying to help - sure, here's /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Turion(tm) II Neo N40L Dual-Core Processor stepping: 3 microcode : 0x1c8 cpu MHz : 1000.000 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate vmmcall npt lbrv svm_lock nrip_save bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400 spectre_v1 spectre_v2 bogomips: 2995.05 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor : 1 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Turion(tm) II Neo N40L Dual-Core Processor stepping: 3 microcode : 0x1c8 cpu MHz : 800.000 cache size : 1024 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate vmmcall npt lbrv svm_lock nrip_save bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400 spectre_v1 spectre_v2 bogomips: 2995.05 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate Attached dmesg.linux with dmesg up to when it starts with initrd - let me know if you would like to see more, as I didn't want to attach a massive file (Linux knows how to pollute dmesg). Any chance to try live OpenBSD there to get dmesg too? Harder to get dmesg from installcd than anticipated, but attached as dmesg.baremetal :-) What is the OS version and Qemu/KVM version on that Linux host? Linux kernel is 5.9.8 and qemu is 5.1.0-r2 (the -r2 is just for Gentoo, so perhaps ignore that). [0.00] Linux version 5.9.8-gentoo-x86_64 (root@nana) (gcc (Gentoo 9.3.0-r1 p3) 9.3.0, GNU ld (Gentoo 2.34 p6) 2.34.0) #3 SMP Sun Nov 15 15:55:27 GMT 2020 [0.00] Command line: BOOT_IMAGE=/vmlinuz-5.9.8-gentoo-x86_64 root=UUID=45a4a2fb-15c5-4d51-85a0-7f405d596d12 ro [0.00] KERNEL supported cpus: [0.00] AMD AuthenticAMD [0.00] x86/fpu: x87 FPU will use FXSAVE [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable [0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e2000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xaff8] usable [0.00] BIOS-e820: [mem 0xaff9e000-0xaff9] type 9 [0.00] BIOS-e820: [mem 0xaffa-0xaffadfff] ACPI data [0.00] BIOS-e820: [mem 0xaffae000-0xaffd] ACPI NVS [0.00] BIOS-e820: [mem 0xaffe-0xafff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xffa0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00042fff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] DMI: HP ProLiant MicroServer, BIOS O41 07/29/2011 [0.00] tsc: Fast TSC calibration failed [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] last_pfn = 0x43 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-E uncachable [0.00]
Re: APU4 hardware network interfaces tied together
> bridge(4), and add a vether ... Reading thru man pages I see there are other options: switch, aggr, trunk, etc. I barely understand these, since IP is an ugly business. My intention is to replace ISP router with something based on OpenBSD I can configure myself. I see now that APU4 is too much, I am inclined to try RPi4 with an USB network interface. If anyone has any other suggestion, please email me directly to ease the list. Thank you all.
Re: APU4 hardware network interfaces tied together
On 2020-11-16, Mihai Popescu wrote: >> bridge(4), and add a vether ... > > Reading thru man pages I see there are other options: switch, aggr, trunk, > etc. aggr and trunk are for combining two or more ports into a single uplink (aggr only for LACP, trunk for various methods). Rither used to get more capacity or to provide failover. bridge (and theoretically switch but I never got it to do anything useful) make a group of ports act like a network switch (maybe with filtering between the ports). > I barely understand these, since IP is an ugly business. These are closer to thw erhernet layer, IP is a separatr layer that runs "on top" of this layer.
vmm-* missing from http://firmware.openbsd.org/firmware/snapshots/
Recent snapshot install for amd64, first run reports the missing package from firmware.
Re: APU4 hardware network interfaces tied together
On Mon, Nov 16, 2020, 6:05 PM Stuart Henderson wrote: > > bridge (and theoretically switch but I never got it to do anything > useful) make a group of ports act like a network switch (maybe with > filtering between the ports). > I've been having issues with switch (4) as well... The reason I decided to go for switch vs bridge on my APU2 is that, from what I understood, bridge invokes some ugly locks in the kernel whereas switch was written without as big of locks in mind. I could be wrong here but maybe someone can correct me. I have a feeling there is something wrong with switch(4) but I haven't been able to independently test that. -John >
Re: OpenBSD 6.8 (release) guest (qemu/kvm) on Linux 5.9 host (amd64) fails with protection fault trap
On 16/11/2020 20:40, Philip Guenther wrote: Looks like qemu fails to behave like a real AMD CPU by failing to handle the wrmsr() for that errata. Also the kernel you're running it on is failing to apply the errata itself (because otherwise OpenBSD won't be trying to flip the bit itself). Go shake an AMD errata document at the qemu people and figure out why your host kernel isn't applying a documented fix. Thanks! This is very helpful - I will figure out why both my host kernel isn't applying the errata and report to qemu.
Re: OpenBSD 6.8 (release) guest (qemu/kvm) on Linux 5.9 host (amd64) fails with protection fault trap
On Sun, Nov 15, 2020 at 10:24 AM Gabriel Garcia wrote:
> I would like to run OpenBSD as stated on the subject - I have been able,
> however, to run it successfully with "-cpu Opteron_G2-v1", but I would
> rather use "-cpu host" instead. Also note that on an Intel host, OpenBSD
> appears to work successfully on the same Linux base.
>
> qemu invocation that yields a trap:
>
...
Lots of looking everywhere but the error going on here. Let's look at the
trap/ddb output:
> kernel: protection fault trap, code=0
> Stopped at amd64_errata_setmsr+0x4e: wrmsr
>
> Contents of CPU registers:
> ddb> show registers
> rdi 0x9c5a203a
> rsi 0x820ff920errata+0xe0
> rbp 0x824c5740end+0x2c5740
> rbx 0x18
> rdx0
> rcx 0xc0011029
> rax 0x3
> r80x824c55a8end+0x2c55a8
> r9 0
> r10 0xbdf7dabff85d847b
> r11 0x51e076fef1dcfa7b
> r120
> r130
> r14 0x820ff940acpihid_ca
> r15 0x820ff920errata+0xe0
> rip 0x81bc6edeamd64_errata_setmsr+0x4e
> cs 0x8
> rflags 0x10256__ALIGN_SIZE+0xf256
> rsp 0x824c5730end+0x2c5730
> ss 0x10
> amd64_errata_setmsr+0x4e: wrmsr
Oh hey, it says RIGHT THERE that a wrmsr instruction faulted. Which one?
Well, it's in the function amd64_errata_setmsr(). Furthermore, we just
have to remember that wrmsr takes the MSR to write in the %ecx register
(something the qemu people surely know) and so it's the 0xc0011029 MSR.
Let's grep for that in the amd64 kernel source:
: bleys; cd /usr/src/sys/arch/amd64/
: bleys; grep -rw 0xc0011029 *
include/specialreg.h:#define MSR_DE_CFG 0xc0011029 /* Decode
Configuration */
: bleys; grep -rwl MSR_DE_CFG *
amd64/identcpu.c
amd64/vmm.c
amd64/amd64errata.c
include/specialreg.h
: bleys; grep -rwl ^amd64_errata_setmsr *
amd64/amd64errata.c
: bleys; less +/MSR_DE_CFG amd64/amd64errata.c
<...>
/*
* 721: Processor May Incorrectly Update Stack Pointer
*/
{
721, 0, MSR_DE_CFG, amd64_errata_set9,
amd64_errata_setmsr, DE_CFG_721
},
Looks like qemu fails to behave like a real AMD CPU by failing to handle
the wrmsr() for that errata. Also the kernel you're running it on is
failing to apply the errata itself (because otherwise OpenBSD won't be
trying to flip the bit itself). Go shake an AMD errata document at the
qemu people and figure out why your host kernel isn't applying a documented
fix.
Paying attention to what the kernel tells you is a Good Thing. Honestly,
what you showed above, that it trapped on wrmsr with those registers should
have been enough for the qemu people to figure out what wasn't working.
Philip Guenther
Re: OpenBSD 6.8 (release) guest (qemu/kvm) on Linux 5.9 host (amd64) fails with protection fault trap
On Sun, Nov 15, 2020 at 06:20:52PM +, Gabriel Garcia wrote: > Hi, > > I would like to run OpenBSD as stated on the subject - I have been able, > however, to run it successfully with "-cpu Opteron_G2-v1", but I would > rather use "-cpu host" instead. Also note that on an Intel host, OpenBSD > appears to work successfully on the same Linux base. > > qemu invocation that yields a trap: > qemu-system-x86_64 -enable-kvm -machine q35 -cpu > host,-nodeid-msr,-vmx-msr-bitmap,-popcnt,-tsc-deadline,-mmxext,-fxsr-opt,-pdpe1gb,-rdtscp,-3dnow,-3dnowext,-cmp-legacy,-svm,-cr8legacy,-abm,-sse4a,-misalignsse,-3dnowprefetch,-osvw,-amd-no-ssb > \ > > -drive file=/path/to/raw.img,format=raw,if=virtio \ > > -m 512M \ > > -display curses > > (note that `-cpu host` without deactivating any flag also yields a trap) Try -cpu kvm64. > > dmesg output: > ddb> dmesg > > OpenBSD 6.8 (GENERIC) #1: Tue Nov 3 09:04:47 MST 2020 > > > r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > real mem = 519954432 (495MB) > > avail mem = 489299968 (466MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5aa0 (9 entries) > > bios0: vendor SeaBIOS version > "?-20190711_202441-buildvm-armv7-10.arm.fedorapro > > ject.org-2.fc31" date 04/01/2014 > > bios0: QEMU Standard PC (Q35 + ICH9, 2009) > > acpi0 at bios0: ACPI 3.0 > > acpi0: sleep states S3 S4 S5 > > acpi0: tables DSDT FACP APIC HPET MCFG WAET > > acpi0: wakeup devices > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: AMD Turion(tm) II Neo N40L Dual-Core Processor, 1497.89 MHz, 10-06-03 > > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH, > MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,POPCNT,DEADLINE,HV,NXE,MMXX,FFXSR,PAGE1GB, > RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW, > > SSBDNR > > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB > 64b/line 1 > > 6-way L2 cache, 16MB 64b/line 16-way L3 cache > > cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > > cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > > kernel: protection fault trap, code=0 > > Stopped at amd64_errata_setmsr+0x4e: wrmsr > > > Contents of CPU registers: > ddb> show registers > > rdi 0x9c5a203a > > rsi 0x820ff920errata+0xe0 > > rbp 0x824c5740end+0x2c5740 > > rbx 0x18 > > rdx0 > > rcx 0xc0011029 > > rax 0x3 > > r80x824c55a8end+0x2c55a8 > > r9 0 > > r10 0xbdf7dabff85d847b > > r11 0x51e076fef1dcfa7b > > r120 > > r130 > > r14 0x820ff940acpihid_ca > > r15 0x820ff920errata+0xe0 > > rip 0x81bc6edeamd64_errata_setmsr+0x4e > > cs 0x8 > > rflags 0x10256__ALIGN_SIZE+0xf256 > > rsp 0x824c5730end+0x2c5730 > > ss 0x10 > > amd64_errata_setmsr+0x4e: wrmsr > > > > Working system dmesg (only change from invocation above is "-cpu > Opteron_G2-v1"): > OpenBSD 6.8 (GENERIC) #1: Tue Nov 3 09:04:47 MST 2020 > > > r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > real mem = 519950336 (495MB) > > avail mem = 489304064 (466MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5aa0 (9 entries) > > bios0: vendor SeaBIOS version > "?-20190711_202441-buildvm-armv7-10.arm.fedoraproject.org-2.fc31" date > 04/01/2014 > > bios0: QEMU Standard PC (Q35 + ICH9, 2009) > > acpi0 at bios0: ACPI 3.0 > > acpi0: sleep states S3 S4 S5 > > acpi0: tables DSDT FACP APIC HPET MCFG WAET > > acpi0: wakeup devices > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: AMD Opteron 22xx (Gen 2 Class Opteron), 1497.89 MHz, 0f-06-01 > > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, > CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF > > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB > 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 cache > > cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > > cpu0: DTLB 255 4KB
Re: OpenLDAP under 6.8 - no intermediate certs in chain
On 11/16/2020 6:52 AM, Stuart Henderson wrote: ...actually I have now added a workaround to the databases/openldap port in 6.8-stable to disable TLS 1.3, so either rebuild or wait for -stable packages and it should fix things. Cool, I was actually already building from source in order to enable modules. I updated my ports tree and rebuilt, looks good now, thanks much for the quick fix. It still does behave a little bit differently; under 6.7 it was including the root CA in the chain sent by the server, under 6.8 it is only including the intermediate, not the root. Which I actually prefer, as sending the root is a waste of time, the client needs to have that itself anyway in order to validate the chain in the first place.
Potential ksh bug?
Hello, I'm not sure if this is a bug, or if it's just a pdksh thing, but I stumbled upon some interesting behaviour when I was tinkering around with quoting and using a poor mans array: test=$(cat <<'__EOT' # I'll choose not to close this quote other_stuff __EOT ) echo "$test" When I run this command on ash, dash, yash, bash, zsh or ksh93 I get the following output: # I'll choose not to close this quote other_stuff But when I run it on ksh from base or any pdksh derivative it throws an error about an unclosed quote: test.sh[8]: no closing quote This snippet works on every POSIX-y shell in the ports tree, and fails on every pdksh variant I tried, including on NetBSD and DragonflyBSD as well. I don't have the requisite esoteric knowledge regarding pdksh's internal quoting logic, so I'm hoping one of the gurus here can determine whether this is a bug or if I'm just doing something annoying. Any insight that can be provided would be much appreciated. Regards, Jordan
Re: Potential ksh bug?
On 17.11.2020 05:04, Jordan Geoghegan wrote: Hello, I'm not sure if this is a bug, or if it's just a pdksh thing, but I stumbled upon some interesting behaviour when I was tinkering around with quoting and using a poor mans array: test=$(cat <<'__EOT' # I'll choose not to close this quote other_stuff __EOT ) echo "$test" When I run this command on ash, dash, yash, bash, zsh or ksh93 I get the following output: # I'll choose not to close this quote other_stuff But when I run it on ksh from base or any pdksh derivative it throws an error about an unclosed quote: test.sh[8]: no closing quote This snippet works on every POSIX-y shell in the ports tree, and fails on every pdksh variant I tried, including on NetBSD and DragonflyBSD as well. I don't have the requisite esoteric knowledge regarding pdksh's internal quoting logic, so I'm hoping one of the gurus here can determine whether this is a bug or if I'm just doing something annoying. BTW try it somewhere with vim and enabled color syntax and you will see immediately what is wrong Any insight that can be provided would be much appreciated. Regards, Jordan
Re: Potential ksh bug?
On 17.11.2020 05:04, Jordan Geoghegan wrote: Hello, I'm not sure if this is a bug, or if it's just a pdksh thing, but I stumbled upon some interesting behaviour when I was tinkering around with quoting and using a poor mans array: test=$(cat <<'__EOT' # I'll choose not to close this quote other_stuff __EOT ) echo "$test" When I run this command on ash, dash, yash, bash, zsh or ksh93 I get the following output: # I'll choose not to close this quote other_stuff But when I run it on ksh from base or any pdksh derivative it throws an error about an unclosed quote: test.sh[8]: no closing quote This snippet works on every POSIX-y shell in the ports tree, and fails on every pdksh variant I tried, including on NetBSD and DragonflyBSD as well. I don't have the requisite esoteric knowledge regarding pdksh's internal quoting logic, so I'm hoping one of the gurus here can determine whether this is a bug or if I'm just doing something annoying. Any insight that can be provided would be much appreciated. What exactly are you trying to achieve? If you will look in sh(1) for 'Command expansion' then there are defined rules and your form is not between them. So error message about missing closing quote is actually proper behavior. Plus I will not be so sure that bash is behaving properly: $ bash -x test.sh ++ cat + test=' # I'\''ll choose not to close this quote other_stuff' + echo '#' 'I'\''ll' choose not to close this quote other_stuff # I'll choose not to close this quote other_stuff $ Notice how one single quote is here "test='" abd second one is in "other_stuff'" You can compare results between various shells with ktrace/ktruss too $ bash --version | head -1 GNU bash, version 5.0.18(1)-release (x86_64-unknown-openbsd6.8) $ If you want to read the file then you do not need interaction and if you want to get input from user then use 'read' As well it is good idea to avoid reserved words as a names for variables ;-) (test) Regards, Jordan
Re: APU4 hardware network interfaces tied together
On Mon, Nov 16, 2020 at 06:37:50PM -0700, John McGuigan wrote: > On Mon, Nov 16, 2020, 6:05 PM Stuart Henderson wrote: > > > > > bridge (and theoretically switch but I never got it to do anything > > useful) make a group of ports act like a network switch (maybe with > > filtering between the ports). > > > > I've been having issues with switch (4) as well... The reason I decided to > go for switch vs bridge on my APU2 is that, from what I understood, bridge > invokes some ugly locks in the kernel whereas switch was written without as > big of locks in mind. I could be wrong here but maybe someone can correct > me. >From my knowledge switch has the same limitation as bridge(4) when it comes to locks. Both require the big kernel lock to operate. > I have a feeling there is something wrong with switch(4) but I haven't been > able to independently test that. switch(4) is mostly for people that want to play with SDN and should not be used as bridge(4) replacement. It is far from finished. -- :wq Claudio
Re: Potential ksh bug?
On 11/16/20 10:36 PM, Bodie wrote: On 17.11.2020 05:04, Jordan Geoghegan wrote: Hello, I'm not sure if this is a bug, or if it's just a pdksh thing, but I stumbled upon some interesting behaviour when I was tinkering around with quoting and using a poor mans array: test=$(cat <<'__EOT' # I'll choose not to close this quote other_stuff __EOT ) echo "$test" When I run this command on ash, dash, yash, bash, zsh or ksh93 I get the following output: # I'll choose not to close this quote other_stuff But when I run it on ksh from base or any pdksh derivative it throws an error about an unclosed quote: test.sh[8]: no closing quote This snippet works on every POSIX-y shell in the ports tree, and fails on every pdksh variant I tried, including on NetBSD and DragonflyBSD as well. I don't have the requisite esoteric knowledge regarding pdksh's internal quoting logic, so I'm hoping one of the gurus here can determine whether this is a bug or if I'm just doing something annoying. Any insight that can be provided would be much appreciated. What exactly are you trying to achieve? If you will look in sh(1) for 'Command expansion' then there are defined rules and your form is not between them. So error message about missing closing quote is actually proper behavior. Plus I will not be so sure that bash is behaving properly: $ bash -x test.sh ++ cat + test=' # I'\''ll choose not to close this quote other_stuff' + echo '#' 'I'\''ll' choose not to close this quote other_stuff # I'll choose not to close this quote other_stuff $ Notice how one single quote is here "test='" abd second one is in "other_stuff'" You can compare results between various shells with ktrace/ktruss too $ bash --version | head -1 GNU bash, version 5.0.18(1)-release (x86_64-unknown-openbsd6.8) $ If you want to read the file then you do not need interaction and if you want to get input from user then use 'read' As well it is good idea to avoid reserved words as a names for variables ;-) (test) Regards, Jordan I'm not trying to achieve anything in particular, I was just testing out differences in behaviour between different shells. I just noticed that pdksh variants handled this differently than any other shell I tested in the ports tree. Regards, Jordan
Re: OpenLDAP under 6.8 - no intermediate certs in chain
On 11/16/2020 2:30 AM, Stuart Henderson wrote: Yes OpenLDAP is broken with TLS 1.3 server-side unless you have that commit (or build LibreSSL with TLS 1.3 server support disabled). As far as I can tell there's no method to disable TLS 1.3 via config. Hmm, yah, you can disable old versions, but I don't think there is any way to disable newer ones.
Re: OpenLDAP under 6.8 - no intermediate certs in chain
On 11/15/2020 10:18 PM, Brad Smith wrote: I remember seeing this commit recently. Not sure if this is your problem or not. https://marc.info/?l=openbsd-cvs=160511882917510=2 That definitely looks like it, thanks for the pointer.
Re: [SPAM] Re: APU4 hardware network interfaces tied together
Buy a switch, and buy the APU4. Two ports don't get used, so what? It'll be more reliable long term than a RPi4. A router with only one physical port isn't a router, it's a host, no matter how many vlans you throw at it. Cheers, Noth On 16/11/2020 18:06, Mihai Popescu wrote: bridge(4), and add a vether ... Reading thru man pages I see there are other options: switch, aggr, trunk, etc. I barely understand these, since IP is an ugly business. My intention is to replace ISP router with something based on OpenBSD I can configure myself. I see now that APU4 is too much, I am inclined to try RPi4 with an USB network interface. If anyone has any other suggestion, please email me directly to ease the list. Thank you all.
