fna, fna3d packages GONE on 6.8
Babes, I want to install fna and fna3d to be able to play terraria with fnaify but the packages seem to be nonexistant on 6.8-release, and they used to be available. I can't use -Dsnap because the new packages depend on a new version of sdl2, which depends on a new version of xenocara which is not available on 6.8. I would upgrade to 6.9-beta but as I sent in a previous email it does not boot on my computer, so I'm at a loss. Does anyone know of a way to fix this? Or why the packages are no longer available? Thanks.
Re: fna, fna3d packages GONE on 6.8
On Fri, Mar 05, 2021 at 02:49:19AM +, jpegb...@dismail.de wrote: ... > I want to install fna and fna3d to be able to play terraria with fnaify > but the packages seem to be nonexistant on 6.8-release, and they used > to be available. I can't use -Dsnap because the new packages depend on > a new version of sdl2, which depends on a new version of xenocara which > is not available on 6.8. I would upgrade to 6.9-beta but as I sent in > a previous email it does not boot on my computer, so I'm at a loss. > Does anyone know of a way to fix this? Or why the packages are no > longer available? Thanks. The games/fna and graphics/fna3d ports were committed after 6.8, there were never any packages for 6.8. https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/games/fna/ https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/graphics/fna3d/
Re: 6.9-beta failing to boot with X file sets, black screen
>> Hello, >> I'm having a problem with 6.9-beta that I reported on a few months ago >> on 6.8-current, but that seems to have been ignored. When booting >> 6.9-beta I get a black lit screen after half the dmesg has been >> displayed. This happens on an amd64 dell precision m4800 laptop with >> intel graphics (haswell), core i7-4810MQ. I upgraded through a snapshot >> and after it failed to boot I reinstalled the snapshot without the X >> file sets, with which I was able to obtain a dmesg and pcidump -v. The >> workaround for this seems to be either installing without X or booting >> a single processor kernel. the 6.8-current report is here: >> https://marc.info/?l=openbsd-bugs=160575016004118=2 >> Dmesg and pcidump -v are attached below. Hope this helps! > > Your other mail mentions switchable graphics. And I assume that the > dedicated GPU is an nvidia by your dmesg. > > Does your comment in the previous mail about disabling switchable > graphics still let you boot successfully? Yes. It is able to boot, but graphics won't function if I disable switchable graphics. > I'm not shocked this doesn't work. nvidia support is quite limited. I've > tried OpenBSD on some machines with nvidia, and it's worked "ok". I've > had other instances where it just hasn't worked at all (in similar ways > to what you describe). The bottom line is that when I'm considering > hardware for running OpenBSD, I pretend nvidia doesn't exist. I do the same thing, I just use the intel graphics and let the nvidia card sit on my computer, but for some reason beta won't work even with that. 6.8-stable works fine.
6.9-beta failing to boot with X file sets, black screen
Hello, I'm having a problem with 6.9-beta that I reported on a few months ago on 6.8-current, but that seems to have been ignored. When booting 6.9-beta I get a black lit screen after half the dmesg has been displayed. This happens on an amd64 dell precision m4800 laptop with intel graphics (haswell), core i7-4810MQ. I upgraded through a snapshot and after it failed to boot I reinstalled the snapshot without the X file sets, with which I was able to obtain a dmesg and pcidump -v. The workaround for this seems to be either installing without X or booting a single processor kernel. the 6.8-current report is here: https://marc.info/?l=openbsd-bugs=160575016004118=2 Dmesg and pcidump -v are attached below. Hope this helps! OpenBSD 6.9-beta (GENERIC.MP) #368: Sun Feb 28 21:10:13 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34243895296 (32657MB) avail mem = 33190711296 (31653MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xecd50 (101 entries) bios0: vendor Dell Inc. version "A25" date 10/08/2018 bios0: Dell Inc. Precision M4800 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG ASF! DMAR SSDT acpi0: wakeup devices RP01(S4) PXSX(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PXSX(S4) GLAN(S4) EHC1(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) Core(TM) i7-4810MQ CPU @ 2.80GHz, 2794.05 MHz, 06-3c-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 2793.55 MHz, 06-3c-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 2793.55 MHz, 06-3c-03 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 2793.55 MHz, 06-3c-03 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 2793.54 MHz, 06-3c-03 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Core(TM)
Re: native wireguard + nat
Please provide your whole pf.conf file and ifconfig output. It's difficult to help with only a small subset of the configuration. There are PF macros referenced, but they weren't included either. On Thu, Mar 4, 2021 at 10:53 AM Riccardo Giuntoli wrote: > root@ganesha:/etc# cat pf.conf | grep wg > > > > block in on wg > match out on $ext_if from wg0:network to any nat-to $ext_if:0 > pass in on wg from wg:network to ! modulate state > root@ganesha:/etc# > root@ganesha:/etc# ping -c 1 10.10.10.2 > PING 10.10.10.2 (10.10.10.2): 56 data bytes > 64 bytes from 10.10.10.2: icmp_seq=0 ttl=64 time=84.140 ms > > --- 10.10.10.2 ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 84.140/84.140/84.140/0.000 ms > root@ganesha:/etc# > > root@ganesha:/etc# tcpdump -i vio0 host 10.10.10.2 > tcpdump: listening on vio0, link-type EN10MB > 17:51:48.596335 10.10.10.2.41470 > > m71os.services.getactivationkey.com.https: S 2252122240:2252122240(0) win > 65535 (DF) > ^C > 74 packets received by filter > 0 packets dropped by kernel > root@ganesha:/etc# > > PF nat doesn't translate. > > On Thu, Mar 4, 2021 at 6:43 PM Ashton Fagg wrote: > > > Riccardo Giuntoli writes: > > > > > Hi list. A pleasure to. > > > > > > Got a strange error with native wireguard for roadwarrior config. > > > > Pasting the full error makes people more likely to help you. > > > > > PF NAT doesn't work. > > > > Ok, but what's the error? "doesn't work" isn't very descriptive. > > > > > Someone with the same problem. > > > > > > root@ganesha:/etc# sysctl kern.version > > > kern.version=OpenBSD 6.8 (GENERIC) #5: Mon Feb 22 04:04:49 MST 2021 > > > r...@syspatch-68-amd64.openbsd.org: > > > /usr/src/sys/arch/amd64/compile/GENERIC > > > > > > root@ganesha:/etc# > > > > > -- > Name: Riccardo Giuntoli > Email: tag...@gmail.com > Location: sant Pere de Ribes, BCN, Spain > PGP Key: 0x67123739 > PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739 > Key server: hkp://wwwkeys.eu.pgp.net >
Re: ikectl ca and subjectAltName for IKEv2 VPNs
On 3/4/21 12:29 AM, Stuart Henderson wrote: > On 2021-03-04, David Newman wrote: >> Apparently Apple iOS and iPadOS VPN clients now require a subjectAltName >> in the client cert, not just the CN, to set up IKEv2 VPN tunnels.* The >> subjectAltName can be the same as the CN; it just has to be present. > > Most IKE software has always needed this. (Web browsers also recently-ish > started needing it too). > >> Questions about this: >> >> 1. Does the 'ikectl ca certificate create' command >> support creation of X.509 certs with a subjectAltName defined in >> addition to the CN? >> >> If so, what's the syntax? > > It does this by default. Thanks, I hadn't realized that, and should have grep'd the cert for 'DNS:' before asking. And yet, an iOS client initiator still fails with an authentication error on the iOS side. 'ipsecctl -sa' on the OpenBSD responder looks fine, with a tunnel established. The server and client certs generated by 'ikectl sa' have alt names but the CA cert does not. Does it need one? I suspect an error in iOS VPN configuration, but just checking. One other thing about the client cert: The CN is for something like 'iphone.networktest.com', which is an FQDN for which I have not created a DNS record. Again, does it need one? This is for a road-warrior configuration that will come in from different IP addresses, so I'm unclear what name/address pair I'd use in the DNS. Thanks again. dn > >> 2. Can a separate standalone CA just create the certs with the necessary >> SAN fields? > > Yes. > >> Is it as easy as just dropping the root cert, the client >> certs, and keys in these respective directories? >> >> /etc/iked/ca >> /etc/iked/certs >> /etc/iked/private >> >> If not, what else is needed? Thanks! > > You don't need anything from the client (certificates or keys) on the server, > just the CA certificate, the server certificate, and the server private key. > > This is fine if the certificates are signed directly by the CA (as would > often be the case if using your own standalone CA) but I haven't been able > to get this working for certs signed by an intermediate 'sub CA' as is > done for most commercial CAs. > >
Re: native wireguard + nat
root@ganesha:/etc# cat pf.conf | grep wg block in on wg match out on $ext_if from wg0:network to any nat-to $ext_if:0 pass in on wg from wg:network to ! modulate state root@ganesha:/etc# root@ganesha:/etc# ping -c 1 10.10.10.2 PING 10.10.10.2 (10.10.10.2): 56 data bytes 64 bytes from 10.10.10.2: icmp_seq=0 ttl=64 time=84.140 ms --- 10.10.10.2 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 84.140/84.140/84.140/0.000 ms root@ganesha:/etc# root@ganesha:/etc# tcpdump -i vio0 host 10.10.10.2 tcpdump: listening on vio0, link-type EN10MB 17:51:48.596335 10.10.10.2.41470 > m71os.services.getactivationkey.com.https: S 2252122240:2252122240(0) win 65535 (DF) ^C 74 packets received by filter 0 packets dropped by kernel root@ganesha:/etc# PF nat doesn't translate. On Thu, Mar 4, 2021 at 6:43 PM Ashton Fagg wrote: > Riccardo Giuntoli writes: > > > Hi list. A pleasure to. > > > > Got a strange error with native wireguard for roadwarrior config. > > Pasting the full error makes people more likely to help you. > > > PF NAT doesn't work. > > Ok, but what's the error? "doesn't work" isn't very descriptive. > > > Someone with the same problem. > > > > root@ganesha:/etc# sysctl kern.version > > kern.version=OpenBSD 6.8 (GENERIC) #5: Mon Feb 22 04:04:49 MST 2021 > > r...@syspatch-68-amd64.openbsd.org: > > /usr/src/sys/arch/amd64/compile/GENERIC > > > > root@ganesha:/etc# > -- Name: Riccardo Giuntoli Email: tag...@gmail.com Location: sant Pere de Ribes, BCN, Spain PGP Key: 0x67123739 PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739 Key server: hkp://wwwkeys.eu.pgp.net
Re: native wireguard + nat
Riccardo Giuntoli writes: > Hi list. A pleasure to. > > Got a strange error with native wireguard for roadwarrior config. Pasting the full error makes people more likely to help you. > PF NAT doesn't work. Ok, but what's the error? "doesn't work" isn't very descriptive. > Someone with the same problem. > > root@ganesha:/etc# sysctl kern.version > kern.version=OpenBSD 6.8 (GENERIC) #5: Mon Feb 22 04:04:49 MST 2021 > r...@syspatch-68-amd64.openbsd.org: > /usr/src/sys/arch/amd64/compile/GENERIC > > root@ganesha:/etc#
Re: 6.9-beta failing to boot with X file sets, black screen
jpegb...@dismail.de writes: > Hello, > I'm having a problem with 6.9-beta that I reported on a few months ago > on 6.8-current, but that seems to have been ignored. When booting > 6.9-beta I get a black lit screen after half the dmesg has been > displayed. This happens on an amd64 dell precision m4800 laptop with > intel graphics (haswell), core i7-4810MQ. I upgraded through a snapshot > and after it failed to boot I reinstalled the snapshot without the X > file sets, with which I was able to obtain a dmesg and pcidump -v. The > workaround for this seems to be either installing without X or booting > a single processor kernel. the 6.8-current report is here: > https://marc.info/?l=openbsd-bugs=160575016004118=2 > Dmesg and pcidump -v are attached below. Hope this helps! Your other mail mentions switchable graphics. And I assume that the dedicated GPU is an nvidia by your dmesg. Does your comment in the previous mail about disabling switchable graphics still let you boot successfully? I'm not shocked this doesn't work. nvidia support is quite limited. I've tried OpenBSD on some machines with nvidia, and it's worked "ok". I've had other instances where it just hasn't worked at all (in similar ways to what you describe). The bottom line is that when I'm considering hardware for running OpenBSD, I pretend nvidia doesn't exist.
native wireguard + nat
Hi list. A pleasure to. Got a strange error with native wireguard for roadwarrior config. PF NAT doesn't work. Someone with the same problem. root@ganesha:/etc# sysctl kern.version kern.version=OpenBSD 6.8 (GENERIC) #5: Mon Feb 22 04:04:49 MST 2021 r...@syspatch-68-amd64.openbsd.org: /usr/src/sys/arch/amd64/compile/GENERIC root@ganesha:/etc# -- Name: Riccardo Giuntoli Email: tag...@gmail.com Location: sant Pere de Ribes, BCN, Spain PGP Key: 0x67123739 PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739 Key server: hkp://wwwkeys.eu.pgp.net
Re: 6.8 with gnome boots to xterm after upgrade
On 2021-03-03, Sivan ! wrote: > After sysupgrade -s, during which there were two or more automatic > reboots, freebsd, upgraded to 6.9 booted after asking password for ssh key, > and started with xvterm console. Startx attempted to switch to gui, but > returned errors. > > Please advise. > > Thank you > Make sure you have run sysmerge. If that doesn't help then we need more than just "returned errors" - *what* errors?
Re: ikectl ca and subjectAltName for IKEv2 VPNs
On 2021-03-04, David Newman wrote: > Apparently Apple iOS and iPadOS VPN clients now require a subjectAltName > in the client cert, not just the CN, to set up IKEv2 VPN tunnels.* The > subjectAltName can be the same as the CN; it just has to be present. Most IKE software has always needed this. (Web browsers also recently-ish started needing it too). > Questions about this: > > 1. Does the 'ikectl ca certificate create' command > support creation of X.509 certs with a subjectAltName defined in > addition to the CN? > > If so, what's the syntax? It does this by default. > 2. Can a separate standalone CA just create the certs with the necessary > SAN fields? Yes. > Is it as easy as just dropping the root cert, the client > certs, and keys in these respective directories? > > /etc/iked/ca > /etc/iked/certs > /etc/iked/private > > If not, what else is needed? Thanks! You don't need anything from the client (certificates or keys) on the server, just the CA certificate, the server certificate, and the server private key. This is fine if the certificates are signed directly by the CA (as would often be the case if using your own standalone CA) but I haven't been able to get this working for certs signed by an intermediate 'sub CA' as is done for most commercial CAs.
