Re: Dovecot OpenBSD 7.2 VM
On 11/8/2022 6:50 PM, latin...@vcn.bc.ca wrote: Hello misc Is there a problem installing Dovecot? Thanks I have 2 VMs upgraded working correctly, this is a new installation of Dovecot at Vultr. # pkg_add dovecot quirks-6.42 signed on 2022-10-30T18:56:25Z Can't install dovecot-2.3.19.1p0v0 because of libraries |library iconv.7.1 not found | /usr/local/lib/libiconv.so.7.0 (libiconv-1.16p0): minor is too small |library sqlite3.37.20 not found | /usr/local/lib/libsqlite3.so.37.15 (sqlite3-3.38.3): minor is too small Direct dependencies for dovecot-2.3.19.1p0v0 resolve to icu4c-71.1v0 libstemmer-2.1.0 lz4-1.9.4 xz-5.2.5p1 libexttextcat-3.4.6 sqlite3-3.38.3 bzip2-1.0.8p0 libsodium-1.0.18p1 zstd-1.5.2 libiconv-1.16p0 Full dependency tree is icu4c-71.1v0 libstemmer-2.1.0 lz4-1.9.4 xz-5.2.5p1 sqlite3-3.38.3 libexttextcat-3.4.6 libsodium-1.0.18p1 bzip2-1.0.8p0 libiconv-1.16p0 zstd-1.5.2 Couldn't install dovecot-2.3.19.1p0v0 The system needs to have its packages updated. Those are not 7.2 packages.
Dovecot OpenBSD 7.2 VM
Hello misc Is there a problem installing Dovecot? Thanks I have 2 VMs upgraded working correctly, this is a new installation of Dovecot at Vultr. # pkg_add dovecot quirks-6.42 signed on 2022-10-30T18:56:25Z Can't install dovecot-2.3.19.1p0v0 because of libraries |library iconv.7.1 not found | /usr/local/lib/libiconv.so.7.0 (libiconv-1.16p0): minor is too small |library sqlite3.37.20 not found | /usr/local/lib/libsqlite3.so.37.15 (sqlite3-3.38.3): minor is too small Direct dependencies for dovecot-2.3.19.1p0v0 resolve to icu4c-71.1v0 libstemmer-2.1.0 lz4-1.9.4 xz-5.2.5p1 libexttextcat-3.4.6 sqlite3-3.38.3 bzip2-1.0.8p0 libsodium-1.0.18p1 zstd-1.5.2 libiconv-1.16p0 Full dependency tree is icu4c-71.1v0 libstemmer-2.1.0 lz4-1.9.4 xz-5.2.5p1 sqlite3-3.38.3 libexttextcat-3.4.6 libsodium-1.0.18p1 bzip2-1.0.8p0 libiconv-1.16p0 zstd-1.5.2 Couldn't install dovecot-2.3.19.1p0v0
Re: 0.0.0.0/32 in pf's tables
God abhors a naked singularity. On Tue, 2022-11-08 at 22:47 +0300, 3 wrote: > what religion forbids using 0.0.0.0/32 in tables? 0_0 but 0/0 can be > used.. what's going on?! is the world going mad? >
Re: 2FA VPNs
On 2022-11-02, Stuart Henderson wrote: > If anyone's got any good suggestions on how to do VPNs with 2FA > on an OpenBSD gateway for non-technical users to access (iOS, Android, > Windows clients) I'd love to hear them. > > I could bodge something together with openvpn and TOTP but it doesn't > exactly spark joy. Thought I'd follow up on this with my thoughts after considering the various suggestions (thanks all). iked with EAP-MSCHAPv2 *and* RSA certificates: This was suggested off-list, at least strongswan clearly supports it, and it's likely that other clients do too, but if there is a way to have iked require both cert and EAP auths I don't see anything in the docs showing how to configure it. authpf: This might just work for these non-techy users if it was only Windows machines where I could preconfigure a nice shortcut, but it's just going to be too much of a juggle to have them auth on an iOS/Android ssh client as well as connect VPN. L2TP/IPsec (npppd) and auth via RADIUS: Presumably TOTP would be the way to do MFA here, probably glommed onto a password, but I'm not sure all clients will support auth protocols that send the actual password over the wire to be able to do this (CHAP/MSCHAP won't work as they require both sides to have knowledge of the string used as password). Also L2TP/IPsec is not something I really want to return to having already got rid of it once :) OpenVPN with bsd-auth and login_totp: If I went for OpenVPN I'd really not want to use system users, though it's easy enough to hack something together with OpenVPN's auth scripts. That's a bit of a fallback option I think. Wireguard: I like this for some things, but without some layer on top to do config/auth there's a lot of setup needed on each client. And unless combined with authpf (see above) or in whatever layer on top, there's no way to verify that a second factor was used. Let's Connect/EduVPN: This is what I'm going to look at in more detail next, and it has the advantage over anything IPsec-based in that it should be possible to move across gradually on the same gateway and turn off the old setup when done. As a configure layer on top of wireguard/openvpn and with packaged clients it's quite appealing. Let's see...
Re: OpenBSD 7.2 on VPS, routing via IPv6 gateway outside of interface prefix
po 7. 11. 2022 v 13:38 odesílatel Eric JACQUOT napsal: > 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 > Hi Eric, That was it! The cloning modifier did the trick. I tried almost the exact same thing before, but missed this modifier, that's why it didn't work. I had no clue :) In the end it was enough to add just the host route to the gateway. !route add -inet6 2001:db8:efef::1 -cloning -link -iface vio0 was appended to /etc/hostname.vio and 2001:db8:efef::1 went normally to /etc/mygate Works like a charm now. Thank you so much for the help. Michal
Re: 7.2 miniupnpd
> I don't use upnp, but surely you're going to have some problems > with this upstream NAT... or maybe i'm crazy..? 0_o what business can a program have to what happens outside of its narrow little world consisting of two local interfaces? it's none of her business what happens on the other router. her job is to open ports on the local router on command. she cannot know at all where her place in this world is. hell, even i don't know that! %D but the author of miniupnpd believes that he knows better than me where i am and how to live in this place, what i can do and what i can't do. this is some kind of madness.. that's just not clear whose %\
0.0.0.0/32 in pf's tables
what religion forbids using 0.0.0.0/32 in tables? 0_0 but 0/0 can be used.. what's going on?! is the world going mad?
7.2: unbound(timeout) on startup
Hi, since upgrading my router to 7.1 unbound doesn't start up automatically anymore, instead it times out: starting early daemons: syslogd pflogd unbound(timeout) ntpd. It can be started successfully manually later. This setup worked with 7.0. System is an apu acting as a firewall/router for my home network; outside connectivity is German Telecom DSL via pppoe. dmesg: http://oneiros.de/privat/openbsd/dmesg.txt unbound.conf: http://oneiros.de/privat/openbsd/unbound.conf Any idea how to debug or fix this? Thanks in advance Martin
Re: Connect MIDI keyboard to SF2 player in LMMS - OpenBSD 7.2.
On 11/8/22 17:15, Alexandre Ratchov wrote: If you've multiple MIDI controllers, you could assign a MIDI channel to each (most MIDI controllers have a knob to do so) and then route them all to "midithru/0" so lmms or fluidsynth see them as a single port. For instance: midicat -d -q midi/0 -q midithru/0 midicat -d -q midi/1 -q midithru/0 Then, in lmms (or fluidsynth), configure each track's "Input channel" setting to the corresponding input (click on the "keyboard" icon, then the "enable midi input" button, then select the channel number). If you need a more complex MIDI routing, you could try the audio/midish port. Note that certain programs count channel numbers from 0 other from 1. Hi again Alexandre, OK, many thanks for that. I have tried to make this a little simpler by just using one device, that has both keys and pads. Here is the dmesg section: umidi0 at uhub0 port 5 configuration 1 interface 1 "Nektar Impact LX25+" rev 1.10/0.32 addr 3 umidi0: (genuine USB-MIDI) umidi0: out=1, in=2 midi0 at umidi0: midi1 at umidi0: ugen2 at uhub0 port 5 configuration 1 "Nektar Impact LX25+" rev 1.10/0.32 addr 3 I ran the following: $ midicat -d -q midi/0 -q midithru/0 $ midicat -d -q midi/1 -q midithru/0 It appears that it is necessary to use two terminals for this... As suggested, I configured LMMS' Sf2 Player input channel to "1" and then enabled the midi input. I did the same with the Kicker plugin input channel, set it to "2" and enabled the midi input. I then set the action gear for each plugin to receive MIDI input on each. The Sf2 plugin input can be seen in the piano roll, where notes and velocity can be adjusted after the fact. The terminal running the $ midicat -d -q midi/0 -q midithru/0 command has MIDI output scrolling down the terminal. While the pads produce the correct (drum) sounds when the Kicker plugin is open, when closed (and only the Sf2 and Kicker plugins are in the song editor panel) I only get grand piano sounds. Likewise, there is no scrolling output in the second terminal with the command $ midicat -d -q midi/1 -q midithru/0. Nothing appears in the piano roll either, when I chose "record". Not sure what is going on here...
sysupgrade fails after reboot with: The directory '/home/_sysupgrade/' does not exist.
Hi All, I seem to have a sysupgrade problem ... sysupgrade fails after reboot with an error: The directory '/home/_sysupgrade/' does not exist. Sometime ago I had a similar issue due to my having "/home" as a sub-directory of a filesystem "/space". My mistake apparently. Never the less, I had a simple and effective workaround of modifying the path defined in /auto_upgrade.conf before rebooting. Weirdly, that workaround no longer seems to work. To try and avoid any trace of the previous "/home" mount issue, here is what happens when I use the sysupgrade -b flag to set a completely different "base-directory", located in a different filesystem ... Can anyone see where I am going wrong? mjoelnir:/etc 8.11 15:55:08 # sysupgrade -n -b /fast Fetching from http://ftp.fau.de/pub/OpenBSD/snapshots/amd64/ SHA256.sig 100% |*| 2144 00:00 Signature Verified INSTALL.amd64 100% || 43554 00:00 base72.tgz 100% |*| 332 MB00:33 bsd 100% |*| 22463 KB00:06 bsd.mp 100% |*| 22578 KB00:05 bsd.rd 100% |*| 4541 KB00:02 comp72.tgz 100% |*| 74968 KB00:11 game72.tgz 100% |*| 2745 KB00:01 man72.tgz100% |*| 7612 KB00:03 xbase72.tgz 100% |*| 52850 KB00:09 xfont72.tgz 100% |*| 22967 KB00:06 xserv72.tgz 100% |*| 14815 KB00:04 xshare72.tgz 100% |*| 4573 KB00:02 Verifying sets. Fetching updated firmware. fw_update: added none; updated none; kept intel,inteldrm,vmm Will upgrade on next reboot ### The new "base-directory" has been created: mjoelnir:/etc 8.11 15:57:15 # ls -ld /fast/_sysupgrade drwxr-xr-x 2 root wheel 512 Nov 8 15:57 /fast/_sysupgrade ### It contains the newly downloaded files: mjoelnir:/etc 8.11 15:57:26 # ls -l /fast/_sysupgrade total 1141408 -rw-r--r-- 1 root wheel 43554 Nov 8 00:18 INSTALL.amd64 -rw-r--r-- 1 root wheel 1992 Nov 8 15:55 SHA256 -rw-r--r-- 1 root wheel 348171346 Nov 8 00:13 base72.tgz -rw-r--r-- 1 root wheel 23002725 Nov 8 00:12 bsd -rw-r--r-- 1 root wheel 23120636 Nov 8 00:12 bsd.mp -rw-r--r-- 1 root wheel4650857 Nov 8 00:18 bsd.rd -rw-r--r-- 1 root wheel 76767540 Nov 8 00:13 comp72.tgz -rw-r--r-- 1 root wheel2811462 Nov 8 00:13 game72.tgz -rw-r--r-- 1 root wheel7794925 Nov 8 00:13 man72.tgz -rw-r--r-- 1 root wheel 54119339 Nov 8 00:34 xbase72.tgz -rw-r--r-- 1 root wheel 23518994 Nov 8 00:34 xfont72.tgz -rw-r--r-- 1 root wheel 15170647 Nov 8 00:34 xserv72.tgz -rw-r--r-- 1 root wheel4683158 Nov 8 00:34 xshare72.tgz ### The root directory now also has some new files: mjoelnir:/etc 8.11 15:57:32 # ls -ltr / total 153738 -rw-r--r-- 1 root wheel 468 Jun 2 2019 .profile -rw-r--r-- 1 root wheel 578 Jun 2 2019 .cshrc drwxr-xr-x 2 root wheel 512 Sep 29 2019 space lrwxr-xr-x 1 root wheel 9 Jun 3 2020 opt -> /fast/opt -rw-r--r-- 1 root wheel 90496 Jan 28 2021 boot lrwxrwx--- 1 root wheel11 Aug 19 07:54 sys -> usr/src/sys drwxr-xr-x 2 root wheel 512 Aug 19 07:54 altroot drwxr-xr-x 2 root wheel 1024 Aug 19 07:55 bin drwxr-xr-x 2 root wheel 1536 Aug 19 07:55 sbin drwxr-xr-x 31 root wheel 512 Aug 19 08:34 var drwxr-xr-x 16 root wheel 512 Aug 19 08:34 usr -rwx-- 1 root wheel 22982134 Aug 19 14:46 bsd.sp -rw--- 1 root wheel 4638162 Aug 19 14:46 bsd.rd drwxr-xr-x 4 root wheel 512 Nov 8 13:43 mnt drwxr-xr-x 20 root wheel 512 Nov 8 13:48 home -rwx-- 1 root wheel 23088585 Nov 8 15:02 bsd.booted drwxr-xr-x 6 root wheel 19968 Nov 8 15:41 dev -rwx-- 1 root wheel 23082305 Nov 8 15:41 bsd drwxr-xr-x 6 root wheel 512 Nov 8 15:55 fast -rw-r--r-- 1 root
Re: Connect MIDI keyboard to SF2 player in LMMS - OpenBSD 7.2.
On Tue, Nov 08, 2022 at 11:31:24AM +0100, Brian Durant wrote: > I am trying to connect my MIDI keyboard to the Sf2 Player, in LMMS. sndio > MIDI is set under MIDI interface in the MIDI settings section of the LMMS > preferences. DMESG gives me the following when I plug my MIDI keyboard into > the computer: > > umidi0 at uhub0 port 5 configuration 1 interface 0 "KORG INC. microKEY2" rev > 1.10/1.02 addr 3 > umidi0: (genuine USB-MIDI) > umidi0: out=1, in=1 > midi0 at umidi0: > > I have read the three bits of LMMS documentation on MIDI, and I am familiar > with how to use fluidsynth to connect directly with my MIDI keyboard to the > default soundfont: > > $ fluidsynth /usr/local/share/generaluser-gs/GeneralUser_GS.sf2 > $ midicat -d -q midi/0 -q midithru/0 > > Unfortunately, none of this seems to work in LMMS. Clicking on the action > gear for the Sf2 Player plugin shows MIDI input and output, but does not > list my MIDI keyboard (as in Linux or Windows) so that I can bind it to the > Sf2 Player. There is very little information about using MIDI instruments in > the OpenBSD FAQ, and my knowledge of sdiod and jack are limited. Basically, sndio MIDI attempts to look as MIDI hardware. The computer's MIDI ports are named "midi/0", "midi/1", .. and (in the default sndiod config) they correspond the "midi0 at ..." lines of dmesg. There are also software MIDI thru boxes refered as "midithru/0", "midithru/1", ... For instance, when a program sends events to "midithru/0" all other programs connected to "midithru/0" receive the events. By default programs use "midithru/0" as MIDI port. Certain have no MIDI port selector, but the default port may be changed with the MIDIDEVICE environment variable. > The only way that I have found that I can get this to work, is if I run $ > midicat -d -q midi/0 -q midithru/0 from the command line, before I open LMMS > and I then select MIDI input in the Sf2 Player action gear. However, this > allows only for one MIDI instrument at a time. If I also want to connect a > drumpad like the Akai MPK 218, would I run $ midicat -d -q midi/1 -q > midithru/1 and how do I set MIDI input in the Kicker plugin to only get the > MIDI signals from the drumpad and not the keyboard? Perhaps LMMS and sndio > are only setup for something like the Akai MPK Mini MKIII? > > Any help trying to wrap my head around how MIDI, sndio and jack work in this > context is appreciated. > If you've multiple MIDI controllers, you could assign a MIDI channel to each (most MIDI controllers have a knob to do so) and then route them all to "midithru/0" so lmms or fluidsynth see them as a single port. For instance: midicat -d -q midi/0 -q midithru/0 midicat -d -q midi/1 -q midithru/0 Then, in lmms (or fluidsynth), configure each track's "Input channel" setting to the corresponding input (click on the "keyboard" icon, then the "enable midi input" button, then select the channel number). If you need a more complex MIDI routing, you could try the audio/midish port. Note that certain programs count channel numbers from 0 other from 1. You may need to set sndiod latency (ex. "-z 128" option) and lmms buffer size (Edit->Settings set buffer size to 128).
Multicast Routing issues with OpenBSD
Hi Folks, I try to do multicast routing with OpenBSD 7.2 Here is my setup: # Default GW to internet echo 'inet autoconf' > /etc/hostname.em0 # Get 10.10.12.81/24 from dhcp-server with gw 10.10.12.1 # Multicast Server Interface (transmit packets) echo 'inet 172.16.1.1 255.255.255.0 NONE' > /etc/hostname.em1 # Multicast Client interface (receive packets) echo 'inet 172.16.55.1 255.255.255.0 NONE' > /etc/hostname.em2 # Forward ip & multicast echo 'sysctl net.inet.ip.forwarding=1' > /etc/sysctl.conf echo 'sysctl net.inet.ip.mforwarding=1' >> /etc/sysctl.conf # Enable Multicast on OpenBSD rcctl enable multicast # Disable PF rcctl disable pf # Mrouted Configuration multicast_test# cat /etc/mrouted.conf name STD 239.0.0.0/16 pruning on phyint 172.16.1.1 threshold 16 boundary STD altnet 172.16.0.0/16 phyint 172.16.55.1 threshold 16 boundary STD altnet 172.16.0.0/16 phyint 10.10.12.81 disable # Enable mrouted on startUp rcctl enable mrouted # Reboot system reboot For testing purposes I use this application : Singlewire Software IC Test Multicast (It uses ) I'm sure about my testing environment. Because when I use a Brocade ICX L3 switch with router pim configuration everything is ok. But with OpenBSD multicast routing fails: Here some logs : multicast_test# mrinfo 127.0.0.1 (localhost) [version 3.8,prune,genid,mtrace]: 10.10.12.81 -> 0.0.0.0 (local) [1/1/disabled] 172.16.1.1 -> 0.0.0.0 (local) [1/16/querier/leaf] 172.16.55.1 -> 0.0.0.0 (local) [1/16/querier/leaf] multicast_test# netstat -g Virtual Interface Table Vif Thresh Local-AddressRemote-Address Pkt_in Pkt_out 1 16 172.16.1.1 4580 2 16 172.16.55.100 Multicast Forwarding Cache Hash Origin Mcastgroup Traffic In-Vif Out-Vifs/Forw-ttl 0 172.16.1.1 239.0.1.2 458B 1 Total no. of entries in cache: 1 IPv6 Multicast Interface Table is empty IPv6 Multicast Routing Table is empty Output when I run mrouted at debug mode : multicast_test# mrouted -d mrouted: debug level invalid debug level 2 18:06:55.405 mrouted version 3.8 18:06:55.407 Getting vifs from kernel interfaces 18:06:55.408 installing em0 (10.10.12.81 on subnet 10.10.12/24) as vif #0 - rate=0 18:06:55.408 installing em1 (172.16.1.1 on subnet 172.16.1/24) as vif #1 - rate=0 18:06:55.408 installing em2 (172.16.55.1 on subnet 172.16.55/24) as vif #2 - rate=0 18:06:55.408 Getting vifs from /etc/mrouted.conf 18:06:55.408 Installing vifs in mrouted... 18:06:55.408 vif #1, phyint 172.16.1.1 18:06:55.409 vif #2, phyint 172.16.55.1 pruning on 18:06:55.410 Installing vifs in kernel... 18:06:55.410 vif #1, phyint 172.16.1.1 18:06:55.410 vif #2, phyint 172.16.55.1 vifs_with_neighbors = 0 Virtual Interface Table Vif Name Local-Address M Thr Rate Flags 0em0 10.10.12.81 subnet: 10.10.12/24 1 1 0 disabled 18:06:55.411 warning - SIOCGETVIFCNT fails 1em1 172.16.1.1 subnet: 172.16.1/24 1 16 0 querier alternate subnets: 172.16/16 boundaries: 239.0/16 18:06:55.411 warning - SIOCGETVIFCNT fails 2em2 172.16.55.1 subnet: 172.16.55/241 16 0 querier alternate subnets: 172.16/16 boundaries: 239.0/16 18:06:55.411 warning - SIOCGETVIFCNT fails Multicast Routing Table (3 entries) Origin-Subnet From-GatewayMetric Tmr In-Vif Out-Vifs 172.16.55/24 1 0 21* 172.16.1/24 1 0 12* 172.16/16 1 0 12* 18:07:15.583 update 0 starting at 3 of 3 18:07:16.593 update 0 starting at 3 of 3 18:07:17.602 update 0 starting at 3 of 3 18:07:18.612 update 0 starting at 3 of 3 When i watch packets on em1 i can see multicast packets are arriving: (constantly increasing...) multicast_test# tcpdump -nettti em1 host 239.0.1.2 tcpdump: listening on em1, link-type EN10MB Nov 08 18:19:33.344608 2c:f0:5d:73:f8:c4 01:00:5e:00:01:02 0800 73: 172.16.1.2.50665 > 239.0.1.2.20480: udp 31 Nov 08 18:19:34.358455 2c:f0:5d:73:f8:c4 01:00:5e:00:01:02 0800 73: 172.16.1.2.50665 > 239.0.1.2.20480: udp 31 But at the receiver side (em2) there are no multicast packets transmitted by em1 After a while i saw only one packet as igmp nreport with TTL 1 multicast_test# tcpdump -nettti em2 host 239.0.1.2 tcpdump: listening on em2, link-type EN10MB Nov 08 18:21:12.994258 2c:f0:5d:73:f8:c3 01:00:5e:00:01:02 0800 60: 172.16.55.2 > 239.0.1.2: igmp nreport 239.0.1.2 [ttl 1] I've even tried some igmp/mcast proxies but could not figure out how to become a multicast router with my best OS, OpenBSD. I can not understand what I am doing wrong. Thanks and regards.
Connect MIDI keyboard to SF2 player in LMMS - OpenBSD 7.2.
I am trying to connect my MIDI keyboard to the Sf2 Player, in LMMS. sndio MIDI is set under MIDI interface in the MIDI settings section of the LMMS preferences. DMESG gives me the following when I plug my MIDI keyboard into the computer: umidi0 at uhub0 port 5 configuration 1 interface 0 "KORG INC. microKEY2" rev 1.10/1.02 addr 3 umidi0: (genuine USB-MIDI) umidi0: out=1, in=1 midi0 at umidi0: I have read the three bits of LMMS documentation on MIDI, and I am familiar with how to use fluidsynth to connect directly with my MIDI keyboard to the default soundfont: $ fluidsynth /usr/local/share/generaluser-gs/GeneralUser_GS.sf2 $ midicat -d -q midi/0 -q midithru/0 Unfortunately, none of this seems to work in LMMS. Clicking on the action gear for the Sf2 Player plugin shows MIDI input and output, but does not list my MIDI keyboard (as in Linux or Windows) so that I can bind it to the Sf2 Player. There is very little information about using MIDI instruments in the OpenBSD FAQ, and my knowledge of sdiod and jack are limited. The only way that I have found that I can get this to work, is if I run $ midicat -d -q midi/0 -q midithru/0 from the command line, before I open LMMS and I then select MIDI input in the Sf2 Player action gear. However, this allows only for one MIDI instrument at a time. If I also want to connect a drumpad like the Akai MPK 218, would I run $ midicat -d -q midi/1 -q midithru/1 and how do I set MIDI input in the Kicker plugin to only get the MIDI signals from the drumpad and not the keyboard? Perhaps LMMS and sndio are only setup for something like the Akai MPK Mini MKIII? Any help trying to wrap my head around how MIDI, sndio and jack work in this context is appreciated.
Re: 7.2 miniupnpd
On 2022-11-07, 3 wrote: > 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. > --- It was reported working fairly recently, https://github.com/miniupnp/miniupnp/issues/529 > 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 I don't use upnp, but surely you're going to have some problems with this upstream NAT...
Re: 7.2 miniupnpd
sorry, guys. it turned out that this is not a bug, but just the author of the program has gone mad. he considers himself the ruler of the galaxy and points out how we should live :D although it's not funny at all :\ > 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.
Re: Thinkpad T14 AMD Gen 3
On Tue, Nov 08, 2022 at 03:36:12AM -0700, Theo de Raadt wrote: > Jonathan Gray wrote: > > > > 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. > > > > It is possible someone will look at this. I'm not sure what the > > current situation is with changing cards. In the past Lenovo systems > > have had a list of permitted PCI devices and will refuse to boot if a > > card not in the list is added. > > > An iwx card will definately work in the machine. It is crucial you get > one with the correct minipcie connector, since there is big variation. > I believe it is the same FRU as used on the T14gen2. I don't know the > FRU, but OpenBSD calls it "Intel Wi-Fi 6 AX200". Be careful not to get one designed for an Intel SoC. https://www.intel.com.au/content/www/au/en/support/articles/26155/wireless.html AX411 AX211 AX203 AX201 AX101 9560 9462 9461 "Though you can insert these CRF into a standard M.2 Key E socket, they are only compatible with a system designed for the CNVi."
Re: Thinkpad T14 AMD Gen 3
Jonathan Gray wrote: > > 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. > > It is possible someone will look at this. I'm not sure what the > current situation is with changing cards. In the past Lenovo systems > have had a list of permitted PCI devices and will refuse to boot if a > card not in the list is added. An iwx card will definately work in the machine. It is crucial you get one with the correct minipcie connector, since there is big variation. I believe it is the same FRU as used on the T14gen2. I don't know the FRU, but OpenBSD calls it "Intel Wi-Fi 6 AX200". BTW, we want some loose Qualcomm QCNFA765 cards, or similar.
Re: Thinkpad T14 AMD Gen 3
On Tue, Nov 08, 2022 at 12:45:42AM -0500, Philippe Meunier wrote: > 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 Glad to hear amdgpu works on Rembrandt/Yellow Carp. To make suspend/resume possible look for an option along the lines of "Linux S3" in the UEFI firmware settings for sleep state. > 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). diff below for those, though it is just cosmetic run 'make' in /sys/dev/pci before building a kernel Does sound work when using headphones? > > 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. It is possible someone will look at this. I'm not sure what the current situation is with changing cards. In the past Lenovo systems have had a list of permitted PCI devices and will refuse to boot if a card not in the list is added. Index: sys/dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.2010 diff -u -p -r1.2010 pcidevs --- sys/dev/pci/pcidevs 24 Oct 2022 09:12:09 - 1.2010 +++ sys/dev/pci/pcidevs 8 Nov 2022 08:35:28 - @@ -775,6 +775,11 @@ product AMD 17_7X_PCIE_2 0x1484 17h PCIE product AMD 17_3X_CCP 0x1486 17h Crypto product AMD 17_3X_HDA 0x1487 17h HD Audio product AMD 17_7X_XHCI 0x149c 17h xHCI +product AMD 19_4X_RC 0x14b5 19h/4xh Root Complex +product AMD 19_4X_IOMMU0x14b6 19h/4xh IOMMU +product AMD 19_4X_HB_1 0x14b7 19h/4xh Host +product AMD 19_4X_PCIE_1 0x14b9 19h/4xh PCIE +product AMD 19_4X_PCIE_2 0x14ba 19h/4xh PCIE product AMD 14_HB 0x1510 14h Host product AMD 14_PCIE_1 0x1512 14h PCIE product AMD 14_PCIE_2 0x1513 14h PCIE @@ -812,6 +817,8 @@ product AMD 16_3X_MISC_20x1585 16h Misc product AMD 17_1X_RC 0x15d0 17h/1xh Root Complex product AMD 17_1X_IOMMU0x15d1 17h/1xh IOMMU product AMD 17_1X_PCIE_1 0x15d3 17h/1xh PCIE +product AMD 19_4X_XHCI_4 0x15d6 19h/4xh xHCI +product AMD 19_4X_XHCI_5 0x15d7 19h/4xh xHCI product AMD 17_1X_PCIE_2 0x15db 17h/1xh PCIE product AMD 17_1X_PCIE_3 0x15dc 17h/1xh PCIE product AMD 17_1X_CCP 0x15df 17h/1xh Crypto @@ -834,6 +841,9 @@ product AMD 15_0X_DRAM 0x1602 15/0xh DR product AMD 15_0X_MISC 0x1603 15/0xh Misc Cfg product AMD 15_0X_CPU_PM 0x1604 15/0xh CPU Power product AMD 15_0X_HB 0x1605 15/0xh Host +product AMD 19_4X_XHCI_1 0x161d 19h/4xh xHCI +product AMD 19_4X_XHCI_2 0x161e 19h/4xh xHCI +product AMD 19_4X_XHCI_3 0x161f 19h/4xh xHCI product AMD 17_90_XHCI_1 0x162c 17h/90h xHCI product AMD 17_6X_RC 0x1630 17h/6xh Root Complex product AMD 17_6X_IOMMU0x1631 17h/6xh IOMMU @@ -863,6 +873,14 @@ product AMD 19_5X_DF_4 0x166e 19h/5xh D product AMD 19_5X_DF_5 0x166f 19h/5xh Data Fabric product AMD 19_5X_DF_6 0x1670 19h/5xh Data Fabric product AMD 19_5X_DF_7 0x1671 19h/5xh Data Fabric +product AMD 19_4X_DF_0 0x1679 19h/4xh Data Fabric +product AMD 19_4X_DF_1 0x167a 19h/4xh Data Fabric +product AMD 19_4X_DF_2 0x167b 19h/4xh Data Fabric +product AMD 19_4X_DF_3 0x167c 19h/4xh Data Fabric +product AMD 19_4X_DF_4 0x167d 19h/4xh Data Fabric +product AMD 19_4X_DF_5 0x167e 19h/4xh Data Fabric +product AMD 19_4X_DF_6 0x167f 19h/4xh Data Fabric +product AMD 19_4X_DF_7 0x1680 19h/4xh Data Fabric product AMD 14_LINK0x1700 14h Link Cfg product AMD 14_ADDR0x1701 14h Address Map product AMD 14_DRAM0x1702 14h DRAM Cfg
Re: OpenBSD 7.2 on VPS, routing via IPv6 gateway outside of interface prefix
• Michal Šmucr [2022-11-08 01:30]: > > > > 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 :) Maybe you will find some further ideas in dmesg or /var/log/messages?
