Thinkpad T14 AMD Gen 3
Hi, I have a new Thinkpad T14 AMD Gen 3. I tried OpenBSD 7.2-current and the install went smoothly (from USB thumb drive to USB thumb drive, for now). The machine booted, X11 seems to work fine, and so does the Ethernet interface, but there's a whole bunch of "unknown" and "not configured" stuff in the dmesg (see below). For example there doesn't seem to be any sound (the keyboard doesn't beep, at least). More importantly the wifi card (Qualcomm QCNFA765) is not recognized. Is there any chance that it might become supported in the reasonable future or should I try to get a different wifi card (and in such a case, which one)? Any advice? Thank you. (I can provide more information like a pcidump or acpidump if anyone is interested in having a look...) Philippe OpenBSD 7.2-current (GENERIC.MP) #825: Sun Nov 6 12:50:38 MST 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 33014763520 (31485MB) avail mem = 31996776448 (30514MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x73888000 (70 entries) bios0: vendor LENOVO version "R23ET47W (1.17 )" date 05/27/2022 bios0: LENOVO 21CF003XUS efi0 at bios0: UEFI 2.7 efi0: Lenovo rev 0x1110 acpi0 at bios0: ACPI 6.3Undefined scope: \\_SB_.PCI0.GPP1 Undefined scope: \\_SB_.PCI0.GPP2 Undefined scope: \\_SB_.PCI0.GPP2.WWAN Undefined scope: \\_SB_.PCI0.GPP0 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP SSDT SSDT IVRS SSDT SSDT SSDT SSDT TPM2 MSDM BATB HPET APIC MCFG SBST WSMT SSDT CRAT CDIT VFCT FPDT SSDT SSDT SSDT BGRT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT UEFI SSDT SSDT SSDT acpi0: wakeup devices GPP5(S4) GPP6(S0) GPP7(S0) LID_(S4) SLPB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 7 PRO 6850U with Radeon Graphics, 2700.00 MHz, 19-44-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 7 PRO 6850U with Radeon Graphics, 2700.00 MHz, 19-44-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache cpu1: smt 1, core 0, package 0 tsc: cpu0/cpu1: sync test failed timecounter: active counter changed: tsc -> acpihpet0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 7 PRO 6850U with Radeon Graphics, 2700.00 MHz, 19-44-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 7 PRO 6850U with Radeon Graphics, 2700.01 MHz, 19-44-01 cpu3:
Re: Question regarding Apache 2.0 license
Hi Stuart, On Mon, 2022-11-07 at 23:20 +, Stuart Henderson wrote: > Hi Jeroen, > > On 2022-11-07, Jeroen Koekkoek wrote: > > Hi All, > > > > I'm working on some patches/features for NSD. One of the new > > features > > uses some Apache 2.0 licensed code (for now). > > > > Sorry to ask this question, but just to verify: > > > > * OpenBSD-base cannot include any software licensed under Apache > > 2.0. > > * Software in the ports collection is allowed to be licensed under > > Apache 2.0. > > Right. > > > If my assumptions are correct, and since NSD is in base, the > > dependency > > on the Apache 2.0 licensed code is therefore better removed or, > > alternatively, relicensed under a BSD-compatible license, right? > > If this will add Apache-licensed code to NSD itself we can't take it. > (It may be an issue for other users too - in some cases they will > then > have to think more about patent law when they decide whether to use > the software). > > If it's in an external dependency (say, some NSD feature uses some > external Apache-licensed library, but that feature is optional, > and the NSD code which makes use of it follows the standard LICENSE > from the NSD distribution) then we can just disable the option. > Thanks, exactly what I needed to know. - Jeroen
Re: Question regarding Apache 2.0 license
Hi Jeroen, Thank you for considering the license and venturing to improve OpenBSD base, NSD in this case. The preferred license template is modeled after the ISC license, and 2-clause BSD close behind. License policy: ISC or BSD only https://www.openbsd.org/policy.html ISC license template: https://www.openbsd.org/policy.htmlhttps://cvsweb.openbsd.org/src/share/misc/license.template?rev=HEAD Some of the tools I depend on are licensed Apache/GPL, etc, but not in OpenBSD base. Hope that helps. https://cvsweb.openbsd.org/src/share/misc/license.template?rev=HEAD On Mon, Nov 7, 2022 at 3:20 PM, Stuart Henderson wrote: > Hi Jeroen, > > On 2022-11-07, Jeroen Koekkoek wrote: >> Hi All, >> >> I'm working on some patches/features for NSD. One of the new features >> uses some Apache 2.0 licensed code (for now). >> >> Sorry to ask this question, but just to verify: >> >> * OpenBSD-base cannot include any software licensed under Apache 2.0. >> * Software in the ports collection is allowed to be licensed under >> Apache 2.0. > > Right. > >> If my assumptions are correct, and since NSD is in base, the dependency >> on the Apache 2.0 licensed code is therefore better removed or, >> alternatively, relicensed under a BSD-compatible license, right? > > If this will add Apache-licensed code to NSD itself we can't take it. > (It may be an issue for other users too - in some cases they will then > have to think more about patent law when they decide whether to use > the software). > > If it's in an external dependency (say, some NSD feature uses some > external Apache-licensed library, but that feature is optional, > and the NSD code which makes use of it follows the standard LICENSE > from the NSD distribution) then we can just disable the option. > > -- > Please keep replies on the mailing list.
Re: OpenBSD 7.2 on VPS, routing via IPv6 gateway outside of interface prefix
> > I'm sorry, I wasn't thinking very well. > > Have you tried using fe80::1%vio0 as the default IPv6 gateway? > No need to be sorry, I am grateful for any ideas :) And yes, I've also tried fe80::1%vio0 AFAIK that's a bit of a special case and a way how Hetzner (known German cloud provider) routes IPv6 to their VPS. I also installed and used some systems to their cloud, so it also came to my mind, but it didn't work in this particular case. Michal
Re: OpenBSD 7.2 on VPS, routing via IPv6 gateway outside of interface prefix
• Michal Šmucr [2022-11-08 00:09]: > Thank you very much for the reply, Kirill. > > > > try with > > > > > > route add -inet6 2001:db8:efef::1 -llinfo -link -static -iface vio0 > > > > ... that is, try the above before you try to add 2001:db8:efef::1 as > > default gateway. > > I already tested something similar in my previous attempts with flags > and link, but it also didn't work. I'm sorry, I wasn't thinking very well. Have you tried using fe80::1%vio0 as the default IPv6 gateway?
Re: Question regarding Apache 2.0 license
Hi Jeroen, On 2022-11-07, Jeroen Koekkoek wrote: > Hi All, > > I'm working on some patches/features for NSD. One of the new features > uses some Apache 2.0 licensed code (for now). > > Sorry to ask this question, but just to verify: > > * OpenBSD-base cannot include any software licensed under Apache 2.0. > * Software in the ports collection is allowed to be licensed under > Apache 2.0. Right. > If my assumptions are correct, and since NSD is in base, the dependency > on the Apache 2.0 licensed code is therefore better removed or, > alternatively, relicensed under a BSD-compatible license, right? If this will add Apache-licensed code to NSD itself we can't take it. (It may be an issue for other users too - in some cases they will then have to think more about patent law when they decide whether to use the software). If it's in an external dependency (say, some NSD feature uses some external Apache-licensed library, but that feature is optional, and the NSD code which makes use of it follows the standard LICENSE from the NSD distribution) then we can just disable the option. -- Please keep replies on the mailing list.
Re: OpenBSD 7.2 on VPS, routing via IPv6 gateway outside of interface prefix
Thank you very much for the reply, Kirill. > > try with > > > > route add -inet6 2001:db8:efef::1 -llinfo -link -static -iface vio0 > > ... that is, try the above before you try to add 2001:db8:efef::1 as > default gateway. I already tested something similar in my previous attempts with flags and link, but it also didn't work. Here's how it behaves, when I use the exact command you've advised. I removed all previous IPV6 addresses and flushed all routes before testing. $ ifconfig vio0 inet6 2001:db8:efef::d9e:18d2:b761:0/121 $ route add -inet6 2001:db8:efef::1 -llinfo -link -static -iface vio0 add host 2001:db8:efef::1: gateway vio0 $ route -n show -inet6 Routing tables Internet6: DestinationGateway Flags Refs Use Mtu Prio Iface ::1::1UHl 0 20 32768 1 lo0 2001:db8:efef::1 link#1 UHLS 01 - 8 vio0 2001:db8:efef::d9e:18d2:b761:0/121 2001:db8:efef::d9e:18d2:b761:0 UCn00 - 4 vio0 2001:db8:efef::d9e:18d2:b761:0 62:86:db:bc:c6:74 UHLl 00 - 1 vio0 ... $ ping6 2001:db8:efef::1 PING 2001:db8:efef::1 (2001:db8:efef::1): 56 data bytes ping6: sendmsg: Invalid argument ping: wrote 2001:db8:efef::1 64 chars, ret=-1 At this point 2001:db8:efef::1 is inaccessible with normal ping, so it shouldn't work as a default gateway. But nevertheless I've tried that. $ route add -inet6 default 2001:db8:efef::1 add net default: gateway 2a02:25b0:::1 $ ping6 www.google.com PING www.google.com (2a00:1450:4014:80a::2004): 56 data bytes ping6: sendmsg: Invalid argument ping: wrote www.google.com 64 chars, ret=-1 So unfortunately adding a route this way also doesn't work. Thank you, Michal
Question regarding Apache 2.0 license
Hi All, I'm working on some patches/features for NSD. One of the new features uses some Apache 2.0 licensed code (for now). Sorry to ask this question, but just to verify: * OpenBSD-base cannot include any software licensed under Apache 2.0. * Software in the ports collection is allowed to be licensed under Apache 2.0. If my assumptions are correct, and since NSD is in base, the dependency on the Apache 2.0 licensed code is therefore better removed or, alternatively, relicensed under a BSD-compatible license, right? Thanks in advance. Cheers, Jeroen
7.2 miniupnpd
hi, men. it doesn't work only for me? as long as i can remember, there have always been problems with him. who can tell anything about how to fix? or may be any alternative of miniupnpd that works. i tried different build options, but didn't find a working combination. no rules are created in the anchor. --- ext_ifname=pppoe0 ext_perform_stun=yes ext_stun_host=stun.sipgate.net listening_ip=vport0 enable_natpmp=yes enable_upnp=yes secure_mode=no system_uptime=yes notify_interval=60 clean_ruleset_interval=600 anchor=miniupnpd uuid=---- allow 1024-65535 192.168.85.0/0 1024-65535 --- miniupnpd[31745]: version 2.3.0 starting NAT-PMP/PCP UPnP-IGD ext if pppoe0 BOOTID=1667848346 miniupnpd[31745]: STUN: Performing with host=stun.sipgate.net and port=0 ... miniupnpd[31745]: resolve_stun_host: stun.sipgate.net:3478 => 217.10.68.145:3478 miniupnpd[31745]: perform_stun: local ports 3751 46253 4061 16242 miniupnpd[31745]: wait_for_stun_responses: waiting 3 secs and 0 usecs miniupnpd[31745]: wait_for_stun_responses: received responses: 1 miniupnpd[31745]: wait_for_stun_responses: waiting 3 secs and 0 usecs miniupnpd[31745]: wait_for_stun_responses: select(): no more responses miniupnpd[31745]: wait_for_stun_responses: waiting 3 secs and 0 usecs miniupnpd[31745]: wait_for_stun_responses: select(): no more responses miniupnpd[31745]: wait_for_stun_responses: waiting 3 secs and 0 usecs miniupnpd[31745]: wait_for_stun_responses: select(): no more responses miniupnpd[31745]: parse_stun_response: Type 0x0101, Length 68, Magic Cookie 2112a442 miniupnpd[31745]: parse_stun_response: MAPPED-ADDRESS 109.106.141.221:64758 miniupnpd[31745]: parse_stun_response: SOURCE-ADDRESS 217.10.68.145:3478 miniupnpd[31745]: parse_stun_response: CHANGED-ADDRESS 217.116.122.143:3479 miniupnpd[31745]: parse_stun_response: XOR-MAPPED-ADDRESS 109.106.141.221:64758 miniupnpd[31745]: parse_stun_response: SOFTWARE Vovida.org 0.96 miniupnpd[31745]: perform_stun: 1 response out of 4 received miniupnpd[31745]: perform_stun: #0 external address or port changed miniupnpd[31745]: STUN: ext interface pppoe0 with private IP address 172.25.231.96 is now behind restrictive or symmetric NAT with public IP address 109.106.141.221 which does not support port forwarding miniupnpd[31745]: NAT on upstream router blocks incoming connections set by miniupnpd miniupnpd[31745]: Turn off NAT on upstream router or change it to full-cone NAT 1:1 type miniupnpd[31745]: Port forwarding is now disabled miniupnpd[31745]: HTTP listening on port 29442 miniupnpd[31745]: Listening for NAT-PMP/PCP traffic on port 5351 miniupnpd[31745]: HTTP REQUEST from 192.168.85.23:57638 : GET /rootDesc.xml (HTTP/1.1) miniupnpd[31745]: Host: 192.168.85.1:29442 miniupnpd[31745]: 200 rt_msg : msglen=200 version=5 type=14 miniupnpd[31745]: RTM_IFINFO: addrs=10 flags=8b43 index=4 miniupnpd[31745]: 200 rt_msg : msglen=200 version=5 type=14 miniupnpd[31745]: RTM_IFINFO: addrs=10 flags=8b43 index=4 miniupnpd[31745]: level=0 type=30 miniupnpd[31745]: sdl_index = 10 vport0:0.0.0.0.0.1 miniupnpd[31745]: ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1 (ver=1) miniupnpd[31745]: SSDP M-SEARCH from 192.168.85.23:58827 ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1 miniupnpd[31745]: Single search found miniupnpd[31745]: SendSSDPResponse(): 0 bytes to 192.168.85.23:58827 ST: HTTP/1.1 200 OK CACHE-CONTROL: max-age=120 ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1 USN: uuid:----::urn:schemas-upnp-org:device:InternetGatewayDevice:1 EXT: SERVER: OpenBSD/7.2 UPnP/1.1 MiniUPnPd/2.3.0 LOCATION: http://192.168.85.1:29442/rootDesc.xml OPT: "http://schemas.upnp.org/upnp/1/0/;; ns=01 01-NLS: 1667848346 BOOTID.UPNP.ORG: 1667848346 CONFIGID.UPNP.ORG: 1337 miniupnpd[31745]: HTTP REQUEST from 192.168.85.23:57640 : GET /rootDesc.xml (HTTP/1.1) miniupnpd[31745]: Host: 192.168.85.1:29442 miniupnpd[31745]: HTTP REQUEST from 192.168.85.23:57641 : POST /ctl/IPConn (HTTP/1.1) miniupnpd[31745]: Host: 192.168.85.1:29442 miniupnpd[31745]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetStatusInfo miniupnpd[31745]: HTTP REQUEST from 192.168.85.23:57642 : POST /ctl/IPConn (HTTP/1.1) miniupnpd[31745]: Host: 192.168.85.1:29442 miniupnpd[31745]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetExternalIPAddress miniupnpd[31745]: HTTP REQUEST from 192.168.85.23:57643 : POST /ctl/IPConn (HTTP/1.1) miniupnpd[31745]: Host: 192.168.85.1:29442 miniupnpd[31745]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetExternalIPAddress miniupnpd[31745]: HTTP REQUEST from 192.168.85.23:57644 : POST /ctl/IPConn (HTTP/1.1) miniupnpd[31745]: Host: 192.168.85.1:29442 miniupnpd[31745]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping miniupnpd[31745]: AddPortMapping: ext port to
keepassc-2.7.4 and pcsc-lite-1.9.8 dependency
The packages keepassxc-2.7.4-browser-yubikey and keepassxc-2.7.4-yubikey
seem to require pcsc-lite-1.9.8, but somehow pcsc-lite doesn't seem
to be registered as a dependency.
This happens for me on a machine running:
kern.version kern.version=OpenBSD 7.2-current
(GENERIC.MP) #822: Fri Oct 28 21:59:48 MDT 2022
and another running:
kern.version=OpenBSD 7.2-current (GENERIC.MP) #824: Thu Nov 3
21:21:08 MDT 2022
This might just be me not understanding how things work, or it may
be something that will clear itself out, but in case it's not,
a description follows.
The slightly-edited output of typescript found below shows
that keepassxc won't run unless pcsc-lite installed, but
keepassxc doesn't register pcsc-lite as a dependency, so the
system doesn't seem to see that pcsc-lite is required (as indicated
by pkg_info -t). These commands were run on the machine with
the kernel from Oct 28, but the same thing happens on the other
machine.
I do sysupgrade -s for all my boxes and pkg_info -D snap
and did not get the "minor too small" messages that occasionally
happens.
If pcsc-lite just needs to be explicitly added as a dependency,
then the patch would just change WANTLIB and LIB_DEPENDS, I think.
That patch is at the end of this message. I think WANTLIB wants
"pcsclite" and LIB_DEPENDS wants "pcsc-lite."
Edited script showing the problem follows:
machine# /usr/sbin/pkg_delete -a
machine# /bin/ls /var/db/pkg/pcsc* No such file or directory
machine# /bin/ls /var/db/pkg/keepass* No such file or directory
machine# /usr/sbin/pkg_add -D snap keepassxc-2.7.4-browser-yubikey
keepassxc-2.7.4-browser-yub...:minizip-3.0.6:*ok
...
machine# /bin/ls /var/db/pkg/pcsc* No such file or directory
machine# /bin/echo "after regular user tries to run keepassxc, they
get: ld.so: keepassxc: can't load library 'libpcsclite.so.1.0'"
...
machine# /usr/sbin/pkg_add -D snap-pcsc-lite
...
pcsc-lite-1.9.8:*ok The following new rcscripts were installed:
/etc/rc.d/pcscd
machine# /bin/echo "now keepassxc opens"
machine# /usr/sbin/pkg_info -t
...
pcsc-lite-1.9.8 resource manager for PC/SC
machine# /usr/sbin/pkg_delete pcsc-lite pcsc-lite-1.9.8:*ok
...
machine#/sbin/ls /var/db/pkg/pcsc* No such file or directory
machine# /bin/echo "if user tries to open keepassxc now, we're"
machine# /bin/echo "back to::ld.so: keepassxc: can't load library"
machine# /bin/echo "'libpcsclite.so.1.0'"
machine# /usr/sbin/pkg_add -D snap pcsc-lite
...
pcsc-lite-1.9.8:*ok
machine# /bin/ls /var/db/pkg/pcsc* +CONTENTS +DESC +REQUIRING
machine# /usr/sbin/pkg_info -t
...
pcsc-lite-1.9.8 resource manager for PC/SC
# -- end of script -
# Patch follows:
Index: security/keepassxc/Makefile
===
RCS file: /cvs/ports/security/keepassxc/Makefile,v
retrieving revision 1.45
diff -u -p -u -r1.45 Makefile
--- security/keepassxc/Makefile 30 Oct 2022 06:41:31 - 1.45
+++ security/keepassxc/Makefile 7 Nov 2022 18:48:30 -
@@ -14,7 +14,7 @@ PERMIT_PACKAGE = Yes
WANTLIB += ${COMPILER_LIBCXX} Qt5Concurrent Qt5Core Qt5DBus Qt5Gui
WANTLIB += Qt5Network Qt5Svg Qt5Widgets Qt5X11Extras X11 Xtst
-WANTLIB += argon2 botan-2 c m minizip qrencode readline z
+WANTLIB += argon2 botan-2 c m minizip qrencode readline z pcsclite
MASTER_SITES = \
https://github.com/keepassxreboot/keepassxc/releases/download/${V}/
Re: OpenBSD 7.2 on VPS, routing via IPv6 gateway outside of interface prefix
• Kirill Miazine [2022-11-07 13:36]: [...] > > $ ifconfig vio0 inet6 2001:db8:efef::d9e:18d2:b761:0/121 > > $ route add -inet6 default 2001:db8:efef::1 > > add net default: gateway 2001:db8:efef::1: Network is unreachable > > try with > > route add -inet6 2001:db8:efef::1 -llinfo -link -static -iface vio0 ... that is, try the above before you try to add 2001:db8:efef::1 as default gateway. -- -- Kirill Miazine
new release of Perl/CPAN smoker for OpenBSD 7.2
Hello guys, For those that are interested in running CPAN smokers on OpenBSD, I made available new Vagrant boxes for the OpenBSD 7.2 release: https://app.vagrantup.com/arfreitas/boxes/openbsd-7.2-cpan-smoker-amd64 https://app.vagrantup.com/arfreitas/boxes/openbsd-7.2-cpan-smoker-i386 Please let me know if you find any issues. Best regards, Alceu
Re: OpenBSD 7.2 on VPS, routing via IPv6 gateway outside of interface prefix
• Michal Šmucr [2022-11-07 13:02]: [...] > Hello to all, > > I'm looking for possible opinions or advice regarding IPv6 setup at new VPS. > Probably the most common approach is a VPS provider gives you /64 > prefix length with gateway within the subnet. > Works everywhere, it's also the smallest usable prefix length for use > with SLAAC. > However in this case, the VPS has /121 prefix length and its gateway > is outside of the subnet. > Something like this: > VPS IP: 2001:db8:efef::d9e:18d2:b761:0/121 > GW: 2001:db8:efef::1/48 [...] > On OpenBSD I tried.. > > $ ifconfig vio0 inet6 2001:db8:efef::d9e:18d2:b761:0/121 > $ route add -inet6 default 2001:db8:efef::1 > add net default: gateway 2001:db8:efef::1: Network is unreachable try with route add -inet6 2001:db8:efef::1 -llinfo -link -static -iface vio0 > Well, that sounds logical. So I tried to tell how to reach the gateway first. > It should be directly accessible, so after few failed attempts and > digging in man page > I thought the -iface modifier with the local address of the interface > as destination should do the trick. > $ route add -inet6 2001:db8:efef::1 2001:db8:efef::d9e:18d2:b761:0 -iface > $ ping6 2001:db8:efef::1 > PING 2001:db8:efef::1 (2001:db8:efef::1): 56 data bytes > ping6: sendmsg: Invalid argument > > ehh.. no dice > I tried a couple of other things, like adding an additional network > route to /48 prefix, and experimenting with some additional flags, > when adding. But it never worked. > > Is it impossible to achieve? > Like without the equivalent of Linux noprefixroute option, there will > always be an already automatically declared offending route. > Or do I have some mistakes there? > > Thank you, > > Michal > -- -- Kirill Miazine
Re: OpenBSD 7.2 on VPS, routing via IPv6 gateway outside of interface prefix
> De: Michal Šmucr > Envoyé: lundi 7th novembre 2022 13:03 > À: misc@openbsd.org > Sujet: OpenBSD 7.2 on VPS, routing via IPv6 gateway outside of interface > prefix > > Hello to all, > > I'm looking for possible opinions or advice regarding IPv6 setup at new VPS. > Probably the most common approach is a VPS provider gives you /64 > prefix length with gateway within the subnet. > Works everywhere, it's also the smallest usable prefix length for use > with SLAAC. > However in this case, the VPS has /121 prefix length and its gateway > is outside of the subnet. > Something like this: > VPS IP: 2001:db8:efef::d9e:18d2:b761:0/121 > GW: 2001:db8:efef::1/48 Hi, Could you try with this inet6 conf in your /etc/hostname.vio0 : inet6 [yourvpsipv6] 121 !route add -inet6 -net 2001:db8:efef::1/128 -cloning -link -iface vio0 !route add -inet6 default 2001:db8:efef::1 Be aware of icmpv6 filtering in your pf.conf. Regards, -- Eric Jacquot
OpenBSD 7.2 on VPS, routing via IPv6 gateway outside of interface prefix
Hello to all, I'm looking for possible opinions or advice regarding IPv6 setup at new VPS. Probably the most common approach is a VPS provider gives you /64 prefix length with gateway within the subnet. Works everywhere, it's also the smallest usable prefix length for use with SLAAC. However in this case, the VPS has /121 prefix length and its gateway is outside of the subnet. Something like this: VPS IP: 2001:db8:efef::d9e:18d2:b761:0/121 GW: 2001:db8:efef::1/48 Before this OpenBSD VPS I installed another one there with Linux, where it surprisingly went without issues. Unfortunately with the BSD that setup wasn't successful. I came up with two workarounds. First I can set /48 prefix for the interface and it will work, compared to IPV4 there shouldn't be issues like with a wider mask and broadcasts and if I won't use any IP outside of the "designated" prefix, it will likely be fine. The other one is route everything via link-local address of particular gateway (eg. use address like fe80:::::%vio0 which I found), it also works, but it will be sensitive for any failovers or changes on their hardware, as the link local address might change and VPS will be essentially disconnected until manual fix. Anyway I'm still curious why it was possible to set up on Linux and not on OpenBSD. I just booted CentOS live ISO at the exact same VPS and tried to debug that step-by-step without any init scripts or NetworkManager. On CentOS I can do the following steps.. $ ip -6 addr add 2001:db8:efef::d9e:18d2:b761:0/121 dev eth0 noprefixroute $ ip -6 route add 2001:db8:efef::1 dev eth0 $ ip -6 route add default via 2001:db8:efef::1 dev eth0 Then it will work as expected, the important part is noprefixroute option at first command. This will prevent creation (and deletion) of prefix route during IP address assignment, if I omitted that, setup didn't work. On OpenBSD I tried.. $ ifconfig vio0 inet6 2001:db8:efef::d9e:18d2:b761:0/121 $ route add -inet6 default 2001:db8:efef::1 add net default: gateway 2001:db8:efef::1: Network is unreachable Well, that sounds logical. So I tried to tell how to reach the gateway first. It should be directly accessible, so after few failed attempts and digging in man page I thought the -iface modifier with the local address of the interface as destination should do the trick. $ route add -inet6 2001:db8:efef::1 2001:db8:efef::d9e:18d2:b761:0 -iface $ ping6 2001:db8:efef::1 PING 2001:db8:efef::1 (2001:db8:efef::1): 56 data bytes ping6: sendmsg: Invalid argument ehh.. no dice I tried a couple of other things, like adding an additional network route to /48 prefix, and experimenting with some additional flags, when adding. But it never worked. Is it impossible to achieve? Like without the equivalent of Linux noprefixroute option, there will always be an already automatically declared offending route. Or do I have some mistakes there? Thank you, Michal
Re: ntp(d) on Boot Behavior
On 2022-11-07, indivC wrote: > Would the correct place to do this be in /etc/rc > and rdate(8) should be called right before it says > "echo -n 'starting early daemons:'"? > Or is there a better way of doing this? That's probably the most correct place, but I don't like modifying /etc/rc if avoidable, so I normally do that in rc.local. Another option is to run it from hostname.if, it's easy if you have static addresses, it got more complicated for DHCP with the change to fetching those addresses in the background but I think with the current iteration you can probably add "!dhcpleasectl \$if" and run rdate after that.
