Re: net/unifi fails to start
On 12/08/18 13:33, Stuart Henderson wrote: Any chance you could have connected to 8443 over http instead of https? There is a check that warns if you do this (at least in unifi 5.9.x - I don't have an older install handy to check) but I guess it might not work in all cases. The logged error you mention is normal and expected, there are a couple of binary-only modules - libubnt_sdnotify_jni.so and libubnt_webrtc_jni.so - where only Linux/Windows/MacOS versions are provided and source is not available, but most things still work fine without them. (there's another java module, the "snappy" compressor, which includes .so modules and an OpenBSD build isn't included upstream, so the port uses a version which I've built instead). Yup, that was my problem, I accidentally connected over http. When I connect over https from the get go, everything works as expected. I just did a modest sized install using the Unifi kit at a local hotel in town here, and everything thus far has worked flawlessly. I've got the unifi controller running in a vmm virtual machine on top of the OpenBSD storage server in the hotel office. Thanks Stuart for maintaining the unifi port, installation was a breeze! Cheers, Jordan
Re: radeon driver bug?
Ok, I upgraded my OpenBSD system to -current, and rebuild the Jahshaka. After all, the results are same as before. Skeletal Animations runs for less than 1 second, and halt for about 35 seconds, and then runs for less than 1 second, and halt for about 35 second(yes, it's same)... Above cycle continues eternally. Kenji 2018年12月10日(月) 1:23 tfrohw...@fastmail.com : > On December 9, 2018 1:22:42 AM UTC, "岡本健二" wrote: > >I found mesa-libs-18.1.9 for FreeBSD ports. > >How can I get it without FreeBSD system? > > > >Kenji > > > > > >2018年12月8日(土) 14:48 岡本健二 : > > > >> I installed Ubuntu 18.04 to a AMD 6450 graphic card, and played > >> Jahshaka. It has mesa version 18.2, and runs Jahshaka very > >> smoothly. > >> > >> The colors I reported before are same in this machine, so that > >> report was not correct. > >> > >> Kenji > >> > >> 2018年12月7日(金) 11:09 岡本健二 : > >> > >>> I checked mesa-18.3.0 sources under src/gallium/drivers/r600 and > >compared > >>> with those > >>> of xenocara. File names are all same, however, individual sizes are > >very > >>> different for > >>> most of those, which would not permit me to copy those to > >xenocara... > >>> > >>> Kenji > >>> > >>> > >>> 2018年12月6日(木) 15:14 岡本健二 : > >>> > also, it stull has some bugs, because the colors of some > parts are different from those of original ones. > > Kenji > > > 2018年12月6日(木) 15:10 岡本健二 : > > > Sorry, I'm a novice to OpenBSD. > > Yes, it's current branch of xenocara. > > I updated my xenocara (stable) to that current, and build new > >xenocara > > here. > > > > Wow, it makes the Jahshaka works! > > > > However, it still has some bugs, because it moves and stop > >suddenly and > > then > > move again. Whine the animation stops, the system seems to > >halting... > > > > Anyway it makes much advance, I included the screenshot of it. > > > > Kenji > > > > PS: sorry tfrohwein, this is doubled to you > > > > 2018年12月6日(木) 13:26 岡本健二 : > > > >> in-current means stable 6.4? > >> > >> Kenji > >> > >> 2018年12月5日(水) 23:58 tfrohw...@fastmail.com > >: > >> > >>> On December 5, 2018 9:41:44 AM UTC, "岡本健二" > >>> wrote: > >>> >This errors come from > >>> > >>/usr/xenocara/lib/mesa/src/gallium/drivers/r600/r600_state_common.c. > >>> >The mesa version of OpenBSD6.4 is 13.0.6. > >>> >I'm running this Jahshaka on Ubutu 18.04, where the mesa > >version is > >>> >18.x. > >>> > > >>> >So, it may be the mesa problem... > >>> > > >>> >Kenji > >>> > > >>> > > >>> >2018年12月4日(火) 16:19 岡本健二 : > >>> > > >>> >> I'm using AMD HD6450 graphic card which I reported before, > >and > >>> faced > >>> >a > >>> >> curious thing > >>> >> during running Jahshaka Studio (dev version 7.03a). > >>> >> To run Jahshaka on OpenBSD 6.4 I needed to delete google > >breakpad > >>> >> temporally, which > >>> >> is not the problem now. > >>> >> > >>> >> After start to run 'Jahshaka Studio', I got start 3D > >animation > >>> sample > >>> >> 'Skeletal Animation' data to load, then > >>> >> I got many errors included below which seems to come from > >radeon > >>> drm > >>> >> driver's bug to me. > >>> >> If you interested please check it. > >>> >> > >>> >> Thanks in advance > >>> >> > >>> >> Kenji > >>> >> > >>> >> > >>> > >>> There's a known bug where the shader on r600 uses too many > >registers: > >>> > >>> https://bugs.freedesktop.org/show_bug.cgi?id=99349 > >>> > >>> I encountered this bug with godot on a Radeon HD 7570, too, and > >it > >>> went away with the updated mesa that's in -current. > >>> > >> > > I think you are asking for way more than you (or most misc@ readers) can > handle. Porting low-level libraries from FreeBSD is far from trivial. > > My advice remains: if you want working graphics, you should run > OpenBSD-current, not 6.4-release. What you did is try to plug in stuff from > -current into 6.4 which is huge gamble and I'm not surprised if the result > is weird. > > Just read the OpenBSD FAQ again for how to install -current. I would stop > experimenting like you've one until you understand the system much better > than now. >
Re: rtwn
On Tue, Dec 11, 2018 at 10:05:24AM +0800, Kevin Lo wrote: > > On Tue, Dec 11, 2018 at 04:20:11AM +0300, gilmulin wrote: > > > > Hello, > > > > I have OpenBSD installed on my laptop (6.4 GENERIC.MP#1 amd64). I love > > it. > > And I hope to fix Wi-Fi problem described below. Because staying on wire > > is not comfort way :) > > > > My network device is Realtek RTL8723BE Wireless LAN 802.11 PCI-E NIC. > > > > # dmesg | grep Realtek | grep pci2 > > "Realtek 8191SE" rev 0x00 at pci2 dev 0 function 0 not configured > > > > # pcidump -v 2:0:0 > > 2:0:0: Realtek 8191SE > > 0x: Vendor ID: 10ec Product ID: b723 > > 0x0004: Command: 0007 Status: 0010 > > 0x0008: Class: 02 Subclass: 80 Interface: 00 Revision: 00 > > 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line > > Size: 10 > > 0x0010: BAR io addr: 0x2000/0x0100 > > 0x0014: BAR empty () > > 0x0018: BAR mem 64bit addr: 0x9050/0x4000 > > 0x0020: BAR empty () > > 0x0024: BAR empty () > > 0x0028: Cardbus CIS: > > 0x002c: Subsystem Vendor ID: 17aa Product ID: b736 > > 0x0030: Expansion ROM Base Address: > > 0x0038: > > 0x003c: Interrupt Pin: 01 Line: 0a Min Gnt: 00 Max Lat: 00 > > 0x0040: Capability 0x01: Power Management > > State: D0 > > 0x0050: Capability 0x05: Message Signalled Interrupts (MSI) > > 0x0070: Capability 0x10: PCI Express > > Link Speed: 2.5 / 2.5 GT/s Link Width: x1 / x1 > > 0x0100: Enhanced Capability 0x01: Advanced Error Reporting > > 0x0140: Enhanced Capability 0x03: Device Serial Number > > 0x0150: Enhanced Capability 0x18: Latency Tolerance Reporting > > 0x0158: Enhanced Capability 0x1e: L1 PM > > > > By the way, rtwn driver has the firmware for my device: > > # ls /etc/firmware | grep rtwn-rtl8723 > > rtwn-rtl8723befw_36 > > rtwn-rtl8723fw > > rtwn-rtl8723fw_B > > > > As one can see, the device is detected. Vendor's ID 10ec is Realtek, and > > 17aa is Lenovo. It's OK, as I see. > > But card is not determined properly. However, "Product ID: b723" is > > close to reality. > > What should I do to match correctly all these entities and to fix > > problem with this pci device? > > As I see, there are few options to solve my problem. > > Could you tell me the best option? > > Yours is RTL8723DE, which is not supported yet. Oops, typo. RTL8723BE is currently not supported. > > > > Current state of firmware packages: > > $ fw_update -i > > Installed: intel-firmware-20180807p0v0 uvideo-firmware-1.2p2 > > Installed, extra: rtwn-firmware-20180103 rsu-firmware-1.2p1 > > > > Thank you. > > Stas > > Kevin > >
Re: rtwn
On Tue, Dec 11, 2018 at 04:20:11AM +0300, gilmulin wrote: > > Hello, > > I have OpenBSD installed on my laptop (6.4 GENERIC.MP#1 amd64). I love > it. > And I hope to fix Wi-Fi problem described below. Because staying on wire > is not comfort way :) > > My network device is Realtek RTL8723BE Wireless LAN 802.11 PCI-E NIC. > > # dmesg | grep Realtek | grep pci2 > "Realtek 8191SE" rev 0x00 at pci2 dev 0 function 0 not configured > > # pcidump -v 2:0:0 > 2:0:0: Realtek 8191SE > 0x: Vendor ID: 10ec Product ID: b723 > 0x0004: Command: 0007 Status: 0010 > 0x0008: Class: 02 Subclass: 80 Interface: 00 Revision: 00 > 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line > Size: 10 > 0x0010: BAR io addr: 0x2000/0x0100 > 0x0014: BAR empty () > 0x0018: BAR mem 64bit addr: 0x9050/0x4000 > 0x0020: BAR empty () > 0x0024: BAR empty () > 0x0028: Cardbus CIS: > 0x002c: Subsystem Vendor ID: 17aa Product ID: b736 > 0x0030: Expansion ROM Base Address: > 0x0038: > 0x003c: Interrupt Pin: 01 Line: 0a Min Gnt: 00 Max Lat: 00 > 0x0040: Capability 0x01: Power Management > State: D0 > 0x0050: Capability 0x05: Message Signalled Interrupts (MSI) > 0x0070: Capability 0x10: PCI Express > Link Speed: 2.5 / 2.5 GT/s Link Width: x1 / x1 > 0x0100: Enhanced Capability 0x01: Advanced Error Reporting > 0x0140: Enhanced Capability 0x03: Device Serial Number > 0x0150: Enhanced Capability 0x18: Latency Tolerance Reporting > 0x0158: Enhanced Capability 0x1e: L1 PM > > By the way, rtwn driver has the firmware for my device: > # ls /etc/firmware | grep rtwn-rtl8723 > rtwn-rtl8723befw_36 > rtwn-rtl8723fw > rtwn-rtl8723fw_B > > As one can see, the device is detected. Vendor's ID 10ec is Realtek, and > 17aa is Lenovo. It's OK, as I see. > But card is not determined properly. However, "Product ID: b723" is > close to reality. > What should I do to match correctly all these entities and to fix > problem with this pci device? > As I see, there are few options to solve my problem. > Could you tell me the best option? Yours is RTL8723DE, which is not supported yet. > > Current state of firmware packages: > $ fw_update -i > Installed: intel-firmware-20180807p0v0 uvideo-firmware-1.2p2 > Installed, extra: rtwn-firmware-20180103 rsu-firmware-1.2p1 > > Thank you. > Stas Kevin
Re: TLS suddenly not working over IKED site-to-site
I would like to re-title this as something like "pf and iked instability on recent snapshots," but don’t know if doing so would break the mailing list thread, exiso, I left the subject unchanged... > -Original Message- > From: Theodore Wynnychenko [mailto:t...@uchicago.edu] > Sent: Saturday, December 08, 2018 4:03 PM > To: misc@openbsd.org > Cc: 'Rachel Roch' > Subject: RE: TLS suddenly not working over IKED site-to-site > > > . . . > I now find I can no longer connect to with TLS/SSL over the iked tunnel > (the original behavior that seemed to have corrected itself). Also, > icinga continues to be unable to verify the status of the remote hosts > over port 5665. > > I don't have time right now to try using s_client and s_server and > watching enc0 to see what is happening, but I will when I can. > > If anyone has an ideas on what may be happening, please let me know. > > Thanks > Ted Hello again; So, I am at a complete loss to understand what is going on. Today, I tried using openssl s_client and s_server to make a connection through the iked vpn (as I described in my last post). However, with NO changes to iked.conf or pf.conf, today I had several connection attempts that completed correctly. I have not included any output from those sporadic, completely functional connections. Rather, today, most of the connections by s_client are not even acknowledged by the s_server on the other side of the iked vpn. For example: On the s_client machine: # openssl s_client -state -connect "remote.host":https SSL_connect:before/connect initialization SSL_connect:SSLv3 write client hello A ... and nothing more ... But on the s_server machine today all I see is: # openssl s_sever -state -accept https ...certificate options... Using auto DH parameters Using default temp ECDH parameters ACCEPT ... and no connection attempt is ever acknowledged ... (Yesterday, at least this first part of the connection was received by the s_server: Using auto DH parameters Using default temp ECDH parameters ACCEPT SSL_accept:before/accept initialization ... and nothing more yesterday ...) So, today using tcpdump on the outgoing interface of the s_client machine and the incoming interface of the "local" iked vpn endpoint shows: 16:43:05.107524 172.30.1.254.7305 > 172.30.7.205.443: S 1751796302:1751796302(0) win 16384 16:43:05.149146 172.30.1.254.7305 > 172.30.7.205.443: . ack 2119500805 win 256 16:43:05.149895 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 256 16:43:06.648487 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 256 16:43:09.648557 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 256 16:43:09.948433 172.30.1.254.7305 > 172.30.7.205.443: F 196:196(0) ack 1 win 256 16:43:15.648712 172.30.1.254.7305 > 172.30.7.205.443: FP 0:196(196) ack 1 win 256 And this traffic (incomplete thought it may be for an ssl handshake) appears to be passed to enc0 intact: 16:43:05.105044 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 172.30.7.205.443: S 3570513915:3570513915(0) win 16384 (encap) 16:43:05.146122 (authentic,confidential): SPI 0xe1c30e4a: 172.30.7.205.443 > 172.30.1.254.7305: S 1312941075:1312941075(0) ack 3570513916 win 16384 (encap) 16:43:05.146654 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 172.30.7.205.443: . ack 1 win 256 (encap) 16:43:05.147365 (unprotected): SPI 0xef27: 172.30.1.254.7305 > 172.30.7.205.443: P 1:197(196) ack 1 win 256 (encap) 16:43:06.645932 (unprotected): SPI 0xef27: 172.30.1.254.7305 > 172.30.7.205.443: P 1:197(196) ack 1 win 256 (encap) 16:43:09.646049 (unprotected): SPI 0xef27: 172.30.1.254.7305 > 172.30.7.205.443: P 1:197(196) ack 1 win 256 (encap) 16:43:09.945908 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 172.30.7.205.443: F 197:197(0) ack 1 win 256 (encap) 16:43:09.981966 (authentic,confidential): SPI 0xe1c30e4a: 172.30.7.205.443 > 172.30.1.254.7305: . ack 1 win 261 (encap) 16:43:15.646158 (unprotected): SPI 0xef27: 172.30.1.254.7305 > 172.30.7.205.443: FP 1:197(196) ack 1 win 256 (encap) BUT, at the other end of the VPN, on enc0, all that is seen leaving the iked VPN tunnel is: 16:43:05.130558 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 172.30.7.205.443: S 3570513915:3570513915(0) win 16384 (encap) 16:43:05.131049 (authentic,confidential): SPI 0xe1c30e4a: 172.30.7.205.443 > 172.30.1.254.7305: S 1312941075:1312941075(0) ack 3570513916 win 16384 (encap) 16:43:05.174802 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 172.30.7.205.443: . ack 1 win 256 (encap) 16:43:09.966420 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 172.30.7.205.443: F 197:197(0) ack 1 win 256 (encap) 16:43:09.966853 (authentic,confidential): SPI 0xe1c30e4a: 172.30.7.205.443 > 172.30.1.254.7305: . ack 1 win 261 (encap) I have no idea what this
rtwn
Hello, I have OpenBSD installed on my laptop (6.4 GENERIC.MP#1 amd64). I love it. And I hope to fix Wi-Fi problem described below. Because staying on wire is not comfort way :) My network device is Realtek RTL8723BE Wireless LAN 802.11 PCI-E NIC. # dmesg | grep Realtek | grep pci2 "Realtek 8191SE" rev 0x00 at pci2 dev 0 function 0 not configured # pcidump -v 2:0:0 2:0:0: Realtek 8191SE 0x: Vendor ID: 10ec Product ID: b723 0x0004: Command: 0007 Status: 0010 0x0008: Class: 02 Subclass: 80 Interface: 00 Revision: 00 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 10 0x0010: BAR io addr: 0x2000/0x0100 0x0014: BAR empty () 0x0018: BAR mem 64bit addr: 0x9050/0x4000 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 17aa Product ID: b736 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0a Min Gnt: 00 Max Lat: 00 0x0040: Capability 0x01: Power Management State: D0 0x0050: Capability 0x05: Message Signalled Interrupts (MSI) 0x0070: Capability 0x10: PCI Express Link Speed: 2.5 / 2.5 GT/s Link Width: x1 / x1 0x0100: Enhanced Capability 0x01: Advanced Error Reporting 0x0140: Enhanced Capability 0x03: Device Serial Number 0x0150: Enhanced Capability 0x18: Latency Tolerance Reporting 0x0158: Enhanced Capability 0x1e: L1 PM By the way, rtwn driver has the firmware for my device: # ls /etc/firmware | grep rtwn-rtl8723 rtwn-rtl8723befw_36 rtwn-rtl8723fw rtwn-rtl8723fw_B As one can see, the device is detected. Vendor's ID 10ec is Realtek, and 17aa is Lenovo. It's OK, as I see. But card is not determined properly. However, "Product ID: b723" is close to reality. What should I do to match correctly all these entities and to fix problem with this pci device? As I see, there are few options to solve my problem. Could you tell me the best option? Current state of firmware packages: $ fw_update -i Installed: intel-firmware-20180807p0v0 uvideo-firmware-1.2p2 Installed, extra: rtwn-firmware-20180103 rsu-firmware-1.2p1 Thank you. Stas
Re: iked : pf.conf rule for outgoing traffic
On 2018-12-07, Thuban wrote: > * Stuart Henderson le [06-12-2018 13:44:50 +]: >> On 2018-12-06, Thuban wrote: >> > * Thuban le [02-12-2018 19:16:09 +0100]: >> >> Hi, >> >> I need help to write a correct rule in pf.conf. >> >> >> >> I want : >> >> >> >> A -> B --> web >> >> >> >> The appearing IP of A is the B's one on the web. >> >> >> >> I managed to configure iked on A and B using default pubkeys according >> >> to Stuart Henderson advices. >> >> >> >> iked.conf on A : >> >> >> >> ikev2 active ipcomp esp \ >> >> from 192.168.100.0/16 to 0.0.0.0/0 \ >> >> peer "xx.xx.xx.xx" \ >> >> srcid "m...@moria.lan" \ >> >> dstid "B-hostname.tld" \ >> >> tag IKED >> >> >> >> iked.conf on B : >> >> >> >> ikev2 "warrior" passive esp \ >> >> from 0.0.0.0/0 to 0.0.0.0/0 \ >> >> local xx.xx.xx.xx peer any \ >> >> srcid "B-hostname.tld" \ >> >> tag IKED >> >> >> >> Auth works as expected : >> >> >> >> # iked -vvd >> >> .. >> >> sa_state: VALID -> ESTABLISHED from xx.xx.xx.xx:4500 to >> >> 192.168.100.122:4500 policy 'policy1' >> >> .. >> >> >> >> >> >> But I can't reach internet from A through B. >> >> >> >> Here is the pf.conf on B (at least a small part of it) >> >> >> >> pass out on egress \ >> >> from any to any tagged IKED \ >> >> nat-to (egress) >> >> >> >> >> > >> > I'm still stuck at the same point. >> > Can someone give me an example of a working configuration natting ot >> > Internet? >> >> I used this, >> >> pass in on enc0 inet from $some_net >> pass out quick on egress inet received-on enc0 nat-to $some_address >> >> Also I don't remember what you've already said you checked, but >> make sure you have sysctl net.inet.ip.forwarding=1. >> > > Thank you. > Yes, I do have ip.forwarding=1. > > I'm confused how to replace "$some_address". Isn't it "(egress)" ? > > Regards. > > It depends on what you want - I was just giving you the working example you asked for :-) in my case I want to nat to a specific address, and not track the address/es on any egress interfaces.
Re: VMs as real hosts on the same network
On 2018-12-07, mabi wrote: > ‐‐‐ Original Message ‐‐‐ > On Friday, December 7, 2018 12:40 PM, Mischa wrote: > >> The VLAN does require an IP address as far as I am aware. > > Thanks that worked. I now have network connectivity on my public VM VLAN. I > saw that adding an IP to my VLAN interface automatically set the trunk > interface to PROMISC. > > I was trying to avoid "wasting" an IP address as there is no real need for an > IP on that VLAN interface on the server itself. But if that's the only way I > am fine with that :) > > That sounds like a bug... >
Re: Renew/extend CA created with ikectl
On 2018-12-07, Kim Zeitler wrote: > This is a cryptographically signed message in MIME format. > > --ms050605050209090609050606 > Content-Type: text/plain; charset=utf-8; format=flowed > Content-Language: en-GB > Content-Transfer-Encoding: 7bit > > Hello, > > before I start getting creative with openssl(1) on my ikectl(8) created ca. > > Yesterday my ca certificate expired and I need to renew it (without > loosing all the client certificates) > > Is there a recommended way of renewing the ca.crt created using ikectl > ca create? It's a bit awkward but can be done, you'll find some information at https://serverfault.com/questions/306345/certification-authority-root-certificate-expiry-and-renewal You'll need to get the new CA cert installed on clients anyway though (and I don't suppose the client certs have much longer validity either?) so doing the above might not save you much trouble .. > I didn't find anything in the man pages nor on the mailing list. Having > had a look at ikeca.c gave me some idea of how the file is created. > > Also is there a way of having the ca cert valid for more than 365 days? Not without patching the command-line in ikectl code, or generating the cert manually. It's not ideal.. I'd probably recommend using something else to manage your internal CA (or just avoiding X509 if you don't actually need it...).
Re: Pass, gpg2, gpg
On Fri, Dec 07, 2018 at 04:33:36PM +0100, Lucas López wrote: > Question: How to set gpg, gpg2 as interactive mode *by default*? I don't use passwordstore, but I do use gpg2 (gpg is a different program entirely). If you use gpg2, did you try manually setting a pinentry? https://wiki.archlinux.org/index.php/GnuPG#pinentry -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: rtable, rdomain for ppp0 with DHCP assigned IP
On 2018-12-09, Denis wrote: > Stuck when running cvsync in rdomain 1. It seems cvsync does not using > second routing table because of pf.conf misconfiguration or something. > > em0 as a main ISP channel, ppp0 works as reserved wireless ISP channel. > Some system services like cvsync, git, ntp should use second routing > table (rtable 1) assigned to ppp0. > > # route -T1 exec cvsync -c /etc/cvsync.conf > Connecting to cvsync_server_remote_IP port > host cvsync_server_remote_IP port : Can't assing requested address > service is not available at cvsync_server_remote_IP port > > --- configs > # cat /etc/hostname.em0 > rdomain 0 > dhcp > > # cat /etc/hostname.ppp0 > rdomain 1 > dhcp DHCP doesn't run on PPP. > # pppd call ISP > > # ifconfig ppp0 > ppp0: flags=8051 rdomain 1 mtu 1500 > index 7 priority 0 llprio 3 > grups: ppp > inet ISP_ppp0_gateway --> local_ppp0_IP netmask 0xffc0 > > # route -T1 show > local_ppp0_IP ISP_ppp0_gateway_IP UH Prio 8 ppp0 > ISP_ppp0_gateway_IP ISP_ppp0_gateway_IP UHl Prio 1 ppp0 No default route. Perhaps you need to run pppd in rdomain 1? > # cat /etc/pf.conf > ... > match out on rdomain 0 from lo0 to any nat-to (em0) port 1024:65535 rtable 0 > match out on rdomain 1 from lo0 to any nat-to (ppp0) port 1024:65535 > rtable 1 > ... > pass out quick on ppp0 inet proto tcp from (ppp0) to any port flags > S/SA modulate state queue cvs > ... As an aside, I would recommend using rsync rather than cvsync - many of the repo mirrors offer this, it's noted on cvsync.html. cvsync is fragile and frequently breaks.
Re: Pass, gpg2, gpg
Am Freitag, den 07.12.2018, 16:33 +0100 schrieb Lucas López: > I like https://www.passwordstore.org/ and I am so gratefull to have it > in OpenBSD as a package! Please do not ask questions that have nothing to do with OpenBSD in misc@. If it is about the port itself, you may contact the maintainer (which would be me in this case) or may use ports@. But if the question is not at all OpenBSD related, you're better advised to use the mailling list of the software itself: https://lists.zx2c4.com/mailman/listinfo/password-store That being said, of course I may answer your questions shortly via PM. Cheers David
