Re: wireguard reconfiguration reliability
On 3/20/2024 20:56 Kirill Miazine wrote: Like in this thread, I guess: https://marc.info/?t=16964239631=1=2 Indeed. Thanks for the link.
Re: wireguard reconfiguration reliability
On Wed, Mar 20, 2024 at 09:56:06PM +0100, Kirill Miazine wrote: > Like in this thread, I guess: > > https://marc.info/?t=16964239631=1=2 Yes, that is likely the issue we're hitting. Seems last message is from 10/2023 and the issue wasn't resolved :(, so I guess it's a known problem with no solution on the horizon. Next time I'll try your workaround of batching the commands up (ifconfig wg1 down; ifconfig wg1 delete; ifconfig wg1 destroy) rather than running one at a time and keep my fingers crossed I win the race condition :). Thanks for the help...
Re: New asset
Just would drop a thank you for the kindness to reply me. And, to answer, I'm mostly a baby dadder during the day so spare time and night is for the great work and exclusively under exposure of tons of positive enthusiasm.. that - beside a good training to resist tireness - is the true rocknroll. In alternative cheergirls do not function, neither. NB: for a general convinience I can't send a private pigeon.. If everything look hilarious is absolutely wanted. -Dan Brodey Dover : > Progress looks great. > > Keep up the great work!
Re: wireguard reconfiguration reliability
• Paul B. Henson [2024-03-20 21:14]: On 3/20/2024 9:21 AM, Zack Newman wrote: clients in rdomain(4) 0. Last week I ran ifconfig wg1 destroy, replaced the wgkey and wgpsk for one of the three wgpeers in the second interface, and ran sh /etc/netstart wg1. Once I did this, the server seemingly froze: That's similar to what we see, although generally the entire server doesn't die, just the ifconfig command wedges and can't be killed, and the box can't be rebooted cleanly. Like in this thread, I guess: https://marc.info/?t=16964239631=1=2 Thanks for the feedback…
Re: wireguard reconfiguration reliability
On 3/20/2024 9:21 AM, Zack Newman wrote: clients in rdomain(4) 0. Last week I ran ifconfig wg1 destroy, replaced the wgkey and wgpsk for one of the three wgpeers in the second interface, and ran sh /etc/netstart wg1. Once I did this, the server seemingly froze: That's similar to what we see, although generally the entire server doesn't die, just the ifconfig command wedges and can't be killed, and the box can't be rebooted cleanly. Thanks for the feedback…
Re: wireguard reconfiguration reliability
• Paul B. Henson [2024-03-20 20:38]: On 3/20/2024 1:44 AM, Kirill Miazine wrote: actually I checked, and I do use wgpka on clients, but not on the server -- I don't remember why I didn't... In our case the server is on an Internet accessible address, whereas the clients are behind a NAT firewall. We also have keepalives enabled on the clients (to maintain their NAT mapping) but not on the server (as if the client isn't sending its keepalives the server isn't going to get through anyway). this decribes my setup more or less, but some "clients" have stable, routable, reachable addresses. A scenario where it stops but then works again as soon as traffic is sent does kind of sound like a firewall or NAT timeout issue? We don't have that problem, if we leave it completely alone it generally works indefinitely with no issues. It's just when we try to modify the configuration that things sometimes go sideways. what makes flow stop is e.g. if server is rebooted, then clients wouldn't re-connect. it could also be that flushing wgpeers and then re-adding them also made clients go away. again, I haven't spent much time debugging and can't guarantee that described behaviour is what really is going on: I noticed the issue and that ping would seemingly resolve it, so I just added pings everywhere. Thanks for the data point…
Re: openbsd vm with SR-IOV vf nic
On 3/20/2024 2:46 AM, Jonathan Matthew wrote: mcx(4) supports virtual functions, mostly because they're identical to physical functions from the driver's perspective, so all we had to do was add the device IDs. Ah, that wasn't readily apparent; I didn't see anything in the man page mentioning SR-IOV or virtual functions, nor in the source code when I went to take a peek now. I guess if you're familiar with Mellanox you'd be aware the vf was basically the same as the physical card and presumably supported by the same driver. bnxt(4) could support virtual functions pretty easily, since they're largely the same as physical functions, but some work would be required there. Cool, thanks for the pointers…
Re: wireguard reconfiguration reliability
On 3/20/2024 1:44 AM, Kirill Miazine wrote: actually I checked, and I do use wgpka on clients, but not on the server -- I don't remember why I didn't... In our case the server is on an Internet accessible address, whereas the clients are behind a NAT firewall. We also have keepalives enabled on the clients (to maintain their NAT mapping) but not on the server (as if the client isn't sending its keepalives the server isn't going to get through anyway). A scenario where it stops but then works again as soon as traffic is sent does kind of sound like a firewall or NAT timeout issue? We don't have that problem, if we leave it completely alone it generally works indefinitely with no issues. It's just when we try to modify the configuration that things sometimes go sideways. Thanks for the data point…
Re: wireguard reconfiguration reliability
I have two wg(4) interfaces: one that is a site-to-site tunnel (i.e., exactly one wgpeer where both sides have wgendpoint configured) in rdomain(4) 1, and another that is used as the "server" for roaming VPN clients in rdomain(4) 0. Last week I ran ifconfig wg1 destroy, replaced the wgkey and wgpsk for one of the three wgpeers in the second interface, and ran sh /etc/netstart wg1. Once I did this, the server seemingly froze: it stopped responding to ICMPv6, ICMP, and UDP traffic sent to a vlan(4) interface in rdomain(4) 0 whose parent is an ixl(4) interface. After about a minute, the server started to respond to traffic; nonetheless I rebooted the server as a precautionary measure. I almost never change the wg(4) config, so I cannot say if this is a new issue or an issue at all-perhaps it was just a coincidence-and if an issue, not sure if this is related to what is happening to you. I thought I'd provide a possible data point though. The server is running OpenBSD 7.4-stable.
No internet after connecting to wifi
Hello, I am having problem connecting to internet in my openbsd desktop. During installation I was unable to connect to my mobile hotspot (don't have wifi). I didn't pay much attention to it and continued to installation. After installation I went to install firmware for my wifi card (cheap wifi dongle using mtw firmware) using android usb tethring. After doing a fw_update, I tried to connect to mobile hotspot using ifconfig utility as stated in faq I did ifconfig mtw0 nwid xyz wpakey xyz and ran the command. After that I did ifconfig mtw0 inet autoconf. I tried to ping openbsd.org but it din't worked. Here are the outputs of dmesg, netstat -rn and ifconfig. Any help will be appreciated. ## Ifconfig output ## 0: flags=2008049 mtu 32768 index 2 priority 0 llprio 3 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff00 enc0: flags=0<> index 1 priority 0 llprio 3 groups: enc status: active mtw0: flags=808843 mtu 1500 lladdr 00:e0:2d:4c:73:7f index 3 priority 4 llprio 3 groups: wlan media: IEEE802.11 autoselect (DS1 mode 11g) status: active ieee80211: join net chan 1 bssid ea:ed:fb:e9:27:74 -37dBm wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp pflog0: flags=141 mtu 33136 index 4 priority 0 llprio 3 groups: pflog Netstat -rn ## Internet: Destination Gateway Flags Refs Use Mtu Prio Iface 224/4 127.0.0.1 URS 0 0 32768 8 lo0 127/8 127.0.0.1 UGRS 0 0 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 1 10 32768 1 lo0 Internet6: Destination Gateway Flags Refs Use Mtu Prio Iface ::/96 ::1 UGRS 0 0 32768 8 lo0 ::1 ::1 UHhl 10 28 32768 1 lo0 :::0.0.0.0/96 ::1 UGRS 0 0 32768 8 lo0 2002::/24 ::1 UGRS 0 0 32768 8 lo0 2002:7f00::/24 ::1 UGRS 0 0 32768 8 lo0 2002:e000::/20 ::1 UGRS 0 0 32768 8 lo0 2002:ff00::/24 ::1 UGRS 0 0 32768 8 lo0 fe80::/10 ::1 UGRS 0 0 32768 8 lo0 fec0::/10 ::1 UGRS 0 0 32768 8 lo0 fe80::1%lo0 fe80::1%lo0 UHl 0 0 32768 1 lo0 ff01::/16 ::1 UGRS 0 0 32768 8 lo0 ff01::%lo0/32 fe80::1%lo0 Um 0 1 32768 4 lo0 ff02::/16 ::1 UGRS 0 0 32768 8 lo0 ff02::%lo0/32 fe80::1%lo0 Um 0 1 32768 4 lo0 # /etc/hostname.mtw0 join net wpakey d2b9cs4s joint jio-net wpakey 2089dhsdf9h inet autoconf # dmesg | grep mtw0 mtw0 at uhub0 port 3 configuration 1 interface 0 "??MediaTek802.11 n WLAN 802.11 n WLAN" rev 2.01/0.00 addr 2 mtw0: MAC/BBP MT7601 (rev 0x0500), RF MT7601 (MIMO 1T1R), address 00:e0:2d:4c:73:7f Thanks
Re: New asset
Progress looks great. Keep up the great work! Brodey Sent from my iPhone > On Mar 20, 2024, at 10:07, dan wrote: > > Hello, > > We are working.. on/the new asset.. > pointing out the overwhelming importance of the unstructured data. > Footage attached. > > -Dan >
Re: pdftotext
On Wed, 2024-03-20 at 11:55 +, James Cass wrote: > pkg_info poppler-utils In addition. If you know the name of the tool, but you don't know which package it resides in, pkglocate from pkglocatedb is your friend: $ pkglocate pdftotext bash-completion-2.11p0:shells/bash-completion:/usr/local/share/bash-completion/completions/pdftotext fish-3.7.0:shells/fish:/usr/local/share/fish/completions/pdftotext.fish poppler-utils-24.02.0:print/poppler,-utils:/usr/local/bin/pdftotext poppler-utils-24.02.0:print/poppler,-utils:/usr/local/man/man1/pdftotext.1 martijn@ > > On Wednesday, March 20th, 2024 at 7:42 AM, soko.tica > wrote: > > > > > > > > Hallo list, > > > > There used to be pdftotext package, but I couldn't have found him now. I am > > running OpenBSD -stable 7.4 amd64. > > > > I guess it is located in some other package, but can't find it. > > > > Please let me now which package I should install. Thanks in advance. > > > > > > >
Re: pdftotext
pkg_info poppler-utils - Information for https://cdn.openbsd.org/pub/OpenBSD/7.5/packages/amd64/poppler-utils-24.02.0.tgz Comment: PDF conversion tools and utilities Description: This package contains xpdf-workalike command line utilities for getting information of PDF documents, convert them to other formats, or manipulate them: * pdfattach -- file creator * pdfdetach -- file extractor * pdffonts -- font analyzer * pdfimages -- image extractor * pdfinfo -- document information extractor * pdfseparate -- page extractor * pdftocairo -- PDF to PNG/JPEG/PDF/PS/EPS/SVG converter using cairo * pdftohtml -- PDF to HTML/XML/PNG converter * pdftoppm -- PDF to PPM converter * pdftops -- PDF to PostScript (PS) converter * pdftotext -- PDF to text converter * pdfunite -- PDF merging tool Maintainer: Matthias Kilian WWW: https://poppler.freedesktop.org/ Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland. On Wednesday, March 20th, 2024 at 7:42 AM, soko.tica wrote: > Hallo list, > > There used to be pdftotext package, but I couldn't have found him now. I am > running OpenBSD -stable 7.4 amd64. > > I guess it is located in some other package, but can't find it. > > Please let me now which package I should install. Thanks in advance.
pdftotext
Hallo list, There used to be pdftotext package, but I couldn't have found him now. I am running OpenBSD -stable 7.4 amd64. I guess it is located in some other package, but can't find it. Please let me now which package I should install. Thanks in advance.
Re: openbsd vm with SR-IOV vf nic
On Tue, Mar 19, 2024 at 09:54:40PM -0700, Paul B. Henson wrote: > Is it very common for people to be running openbsd boxes under > virtualization and using an SR-IOV vf nic? I'm curious what cards people > are using. > > It looks like the only available driver is iavf, for the Intel 700 > cards? Are there any other drivers I missed? mcx(4) supports virtual functions, mostly because they're identical to physical functions from the driver's perspective, so all we had to do was add the device IDs. bnxt(4) could support virtual functions pretty easily, since they're largely the same as physical functions, but some work would be required there. > > We have some systems with Intel X550 cards in them, based on the 82599 > chipset, which openbsd doesn't currently support. Yuichiro NAITO ported > a driver from netbsd: > > https://marc.info/?l=openbsd-tech=168722323125036=2 > > We tested it under 7.3, and then an updated version for 7.4, and it's > been working great. At one point yasuoka@ had said he would review and > merge it, but it looks like that hasn't happened yet and I haven't heard > back the last couple of times I tried to ask him about it (I assume he's > busy with other things and don't want to bug him any more). > > So I was just wondering if there are any other available drivers I might > have missed for other cards we might have, if anybody else was > interested in X550/82599 vf support, and if maybe any other dev might be > willing to take a look at it and possibly commit it. > > Thanks much... >
Re: wireguard reconfiguration reliability
• Lorenz (xha) [2024-03-20 09:29]:
[...]
> > I've seen some issues too, but has not identified a reproducible pattern.
> > What I've seen, however, is that WG packets start flowing when the other end
> > of the connection pings back, so in my setup with a central VPN server I
> > make it ping all the peers' WG IP adress periodically:
> >
> > #!/bin/sh
> > ifconfig wg1 | \
> > grep wgaip | \
> > awk '{print $2} ' | \
> > grep /32$ | \
> > sed 's/\/32//' | \
> > sort | while read x; do
> > ping -w 1 -c 1 $x 2>&1
> > done
> >
> > and then each peer also pings the server's WG IP periodically.
>
> i think that this is a different issue than the one paul has. are
> you aware that the "wgpka" option exists? (documented in ifconfig(8)).
> that might solve your problem.
could be a different issue FWIW.
yes, I am aware of and use wgpka, and yet the workaround still was
necessary.
Re: wireguard reconfiguration reliability
On Wed, Mar 20, 2024 at 08:15:55AM +0100, Kirill Miazine wrote:
> Hi there
>
> • Paul B. Henson [2024-03-20 05:40]:
> > We're using wireguard to set up VPN connections from various systems
> > deployed on-prem at customer sites to central openbsd boxes to route
> > internal traffic between the remote boxes and the internal network.
> >
> > After a fresh reboot with a given configuration, everything works great.
> > The problem we have is when we later add or remove a remote system and
> > try to reconfigure the wireguard interface on the central servers.
> >
> > Sometimes the new system just won't work, or oddly the new system works
> > fine but an existing system that was working breaks 8-/. When that
> > happens, we generally have to reboot it, at which point everything
> > works.
>
> I've seen some issues too, but has not identified a reproducible pattern.
> What I've seen, however, is that WG packets start flowing when the other end
> of the connection pings back, so in my setup with a central VPN server I
> make it ping all the peers' WG IP adress periodically:
>
> #!/bin/sh
> ifconfig wg1 | \
> grep wgaip | \
> awk '{print $2} ' | \
> grep /32$ | \
> sed 's/\/32//' | \
> sort | while read x; do
> ping -w 1 -c 1 $x 2>&1
> done
>
> and then each peer also pings the server's WG IP periodically.
i think that this is a different issue than the one paul has. are
you aware that the "wgpka" option exists? (documented in ifconfig(8)).
that might solve your problem.
Re: wireguard reconfiguration reliability
Hi there
• Paul B. Henson [2024-03-20 05:40]:
We're using wireguard to set up VPN connections from various systems
deployed on-prem at customer sites to central openbsd boxes to route
internal traffic between the remote boxes and the internal network.
After a fresh reboot with a given configuration, everything works great.
The problem we have is when we later add or remove a remote system and
try to reconfigure the wireguard interface on the central servers.
Sometimes the new system just won't work, or oddly the new system works
fine but an existing system that was working breaks 8-/. When that
happens, we generally have to reboot it, at which point everything
works.
I've seen some issues too, but has not identified a reproducible
pattern. What I've seen, however, is that WG packets start flowing when
the other end of the connection pings back, so in my setup with a
central VPN server I make it ping all the peers' WG IP adress periodically:
#!/bin/sh
ifconfig wg1 | \
grep wgaip | \
awk '{print $2} ' | \
grep /32$ | \
sed 's/\/32//' | \
sort | while read x; do
ping -w 1 -c 1 $x 2>&1
done
and then each peer also pings the server's WG IP periodically.
Occasionally ifconfig on the wg interface just wedges completely. When
that happens, it won't reboot cleaning, we have to hard reset it.
I've seen lockups upon destroying wg interface, but not during normal
operations (i.e. leaving wg alone).
Has anyone else seen this type of behavior? I'm not sure how common it
is to have regular ongoing changes to wireguard like we are doing, so it
might not pop up often.
Thanks much...
Re: rpc
If the latency of the web technologies are fine, I guess someone will point out: NextCloud Indeed is an allroundtheclock solution. If you need something custom, on premised, with the messaging on the top I can also think to go over my https://homomm.5mode-foss.eu and shape its intranet facilities like within a star cascade :-) Otherwise.. -Dan Mar 20, 2024 06:50:39 Gustavo Rios : >> NFS/NIS/AMD are very old technology and are not robust. > > How to replace NIS ? > >> Each OS implements different and only somewhat interoperable versions. >> >> You really need to give a better idea of the size and shape of the problem. >> How much data? >> What size is each datum? >> What latency is allowed? >> Concurrency & locking? >> What kind of data? >> Tightly coupled or looser networked? >> Central control or fully distributed?
