07:27:41 Aargh, have been pulling my hair for days (don't worry, I'm bald) getting a jail on a different vlan, till I found out I'm dealing with a bug (or feature :-) ), described in 240106. No question here, just sharing my frustration 07:36:30 Afterglow I am truly co-frustrated with you 07:37:44 I had to realize years ago that jails really do live up to their name :D it frustrated me too. but it also gives me a bit of confidence that my data is safe in the jail... halfway... 07:48:30 I personally think that jails are godsend, and definitely proof that god exists (proof denies faith, so therefore he doesn't exist) for separating several functions of my server 09:04:58 how do you include a custom .dtb for a uboot port? 09:15:43 Short question. I started looking into wireguard again and saw that there's a /usr/bin/wg on my system. I've read that there was some back and forth on FreeBSD adding the kernel support. Now I'm wondering if kernel support is currently available or not. I can't find anything in the handbook so I'm wondering what the current state of the implementation is :-) 09:16:46 <[tj]> man 4 wg 09:17:01 ring0_starr: i guess you need to change dtb source files (.dts, .dtsi) while building uboot 09:21:06 [tj]: okay, so it's implemented again. Wasn't sure because the news articles were kinda fuzzy for me. 09:21:07 that's what I'm confused about 09:21:44 <[tj]> are you reading news articles from 5 years ago? 09:22:45 how do I do that exactly? make fetch and then find the .dts used? what is the chain of makefiles that the uboot ports use? 09:22:59 for some reason, make fetch doesn't work for sysutils/u-boot-master 09:24:06 I set up wireguard on freebsd like 2 years ago. wg-quick told me it was using the Go port 09:24:29 in other words the kernel support was still semi-broken 09:26:41 ? 09:26:55 the last two lines were @ Liaf 09:27:22 nothing is broken guys, it works as intended 09:27:39 if it had been fixed, it had to've been recently 09:28:39 you have to update your system 09:29:43 I was just confused as I remembered the back and forth 4-5 years ago and when I searched for it I couldn't find anything that just said "everything is fine". Maybe I was just not understanding it correctly hence I thought I ask here. Thank you :-) 09:32:06 i don't think it is, pkg search wireguard shows that wireguard-kmod is absent 09:33:31 i don't think "everything is fine"* to be more clear 10:56:00 the problem was that some commiter just pushed a rushed implementation without approval to get it into 13.0 release, that was noticed fast enought, so that the rushed implementation didn't make it in, later in 13.2 and 14.0 an implementation with review and approval made it into the release as the release notes tell you 12:03:34 nimaje: thank you for the clarification :-) 13:26:00 <[tj]> is there a vnc multiplex I can stick in front of bhyve so my viewer session won't go away on reboots? 13:26:04 <[tj]> this is tedious 13:56:49 so this one is confusing me. zroot/usr has snapshots (confirmed by "zfs list snapshot zroot/usr"). but % cd /usr/.zfs -> cd: no such file or directory: /usr/.zfs 13:57:38 Well, zroot/usr is not mounted 13:58:11 Solved, I'm over in /.zfs/snapshot/autosnap_2025-03-10_13:00:00_hourly/usr/local/etc/radvd.conf.d now 14:16:06 ^ discovered by checking 'zfs get mounted zroot/usr' 16:12:59 ok, interesting. so i'm on a local network ipv4, outside hosts are sometimes reporting back ipv6. isn't there a way to make those reachable thru my ipv4 gateway w/o adding lots of ipv6 internally? 16:32:47 sure, you can add proxy for them 17:17:17 mzar: back on OpenVPN and going to try `dev ovpn0` 17:17:58 hello dvl 17:18:03 mzar: ovpn0 exists, and I've updated the openvpn config. However, I'm getting blocked by: Cannot open TUN/TAP dev /dev/ovpn0: No such file or directory (errno=2) - yes, there is no such device. 17:18:09 it will not work this way, it gets renamed into tun 17:18:24 oh does it? 17:18:36 you have to run it as root if you want to use DCO 17:18:48 I'm Ok with that 17:19:05 and only UDP transport is supported AFAIR 17:19:12 That's what I use 17:19:33 but it improves performance and saves CPU cycles a lot 17:20:16 My existing config used tun2 - I destroyed it already. I'll recreate. 17:21:57 mzar: So how does one tell OpenVPN to use DCO? I have both tun2 and opvn0 17:22:15 I 17:22:45 I've been searching for docs, or examples, and what I have found is not clear. 17:23:40 does anyone use fsck_y_enable in rc.conf? Any ideas why this isn't on by default? 17:24:32 pstef: i use it on UFS VMs, i suspect it's not enabled by default because it could cause data loss (although in that case you've probably lost the data anyway, so...) 17:25:26 pstef: i do, because a number of those systems don't have convenient consoles 17:25:35 thanks, that sounds reasonable 18:14:12 pstef, it's not enabled by default because the default is to do a background fsck if the inital preen is okay-ish. 18:14:44 (I faithfully set it everywhere though - call me a distrustful luddite.) 18:16:15 that's not what I'm seeing on current. I have a machine that's gotten stuck on interactive fsck once in the past and it's again not responding after a reboot 18:20:11 It's a VM/cloud instance? 18:20:27 it's a physical machine 18:21:02 Will it boot to singler user? 18:21:35 I'll know when I go there (no remote access to serial) 18:23:48 Does it have fsck_y_enable set? 18:24:50 not yet 18:26:25 Is it one giant / volume, or is it properly partitioned & sliced like a proper system should be? 18:27:16 it's one microscopic / UFS partition which orbits a larger ZFS pool 18:28:25 Then I would guess it's sitting with a filesystem error on the console. 18:28:49 that's my guess, as well 18:29:44 But yeah - huge fan of: 18:29:45 fsck_y_enable="YES" # Set to YES to do fsck -y if the initial preen fails. 18:29:46 background_fsck="NO" # Attempt to run fsck in the background where possible. 18:29:46 clear_tmp_enable="YES" # Clear /tmp at startup. 18:31:09 are you sure background_fsck="NO" matches the comment? 18:32:42 it may've been changed to NO from YES, which sounds like it'd match the comment 18:32:43 That's straight out of: 18:32:45 https://bpa.st/FM2Q 18:33:37 YES is the default, per /etc/defaults/rc.conf 18:33:55 I tend to grep things out of that file and append to my rc.conf 18:54:32 dvl: you can only tell OpenVPN not to use DCO 18:55:05 mzar: Yes, via --disable-dco - so what I'm trying to do is get /dev/ovpn - so far, no device. 18:56:26 kernel module has to be loaded, network topologu set to subnet, compression disabled, openv process run as root and you will have it 18:57:25 if you are using VPN for bulk transmission then DCO will make it faster 18:58:21 the interface will be renamed to tun, like here: 18:58:39 # ifconfig -g openvpn ->tun10 19:11:24 mzar: I don't know about this. I went from 71Mbit/sec to 114Mbit/sec ... I 19:11:32 I 19:11:38 I'm just not sure. ;) https://bin.langille.org/?5566cfefbf8efe22#A7NoJssny1NNovPWPVW33GxupFd2TLMtkFDvU9aHHvTV 19:13:55 try few parallel transmissions with ipferf, like -P 4 19:14:59 mzar: 133 Mbits/sec 19:15:26 mzar: also, this is over wifi..... 19:15:35 OpenVPN guys take care of us, one of the devs runs FreeBSD as his favourite OS, but kernel DCO module was written by kp@ 19:15:58 Yeah, this is wonderful. 19:16:09 135 Mbits/sec with -p8 19:16:42 143 Mbits/sec with -P12 holy crap 19:17:00 so FreeBSD is definitely not neglected by OpenVPN guys, we had kernel DCO module earlier then Linux (taking about -RELEASEs available to wider audience) 19:17:21 Pretty fantastic. 19:17:52 umm, 160 Mbits/sec 19:17:56 kp@ did nice job 19:18:12 This blog post will point that out. 19:18:22 135 Mb/s feels slow, unless that's limited by the network? 19:18:40 ivy: I'm on wifi..? 19:18:48 ah 19:19:07 I can fix that... 19:19:40 I feel I must do this over wired for a proper test. One of the individual streams got to 181 Mbits/sec 19:19:44 one important thing it so set "tun-mtu 1400" on server side 19:19:49 it will be pushed to clients 19:20:22 if both, client and server use DCO, then mssfix will not work 19:21:21 in my case reducint MTU for the tunnel device additionaly increased network performance 19:21:57 but it was required to make tunnel with DCO working fine over IPv6 transport 19:22:50 probably IPv6 MTU discovery is broken between my home and work networks 19:29:27 First test after setting tun-mtu 1400 - same results as before: about 160 Mbits/sec. I'm about to move over to a wired connection next. 19:43:34 please let us know, in my case, over IPv6 transport it's: 100Mbps (without DCO) vs 400Mbs (DCO on server only) vs 800Mbps (DCO on both ends) 19:47:16 out of curiosity, what kind of transfer would you expect in the same situation but with wireguard instead of ovpn? 19:47:46 i get ~800Mbps Wireguard over the internet on fairly modest hardware (over a 1Gbps link) 19:50:29 [ 5] 0.00-10.01 sec 1.69 GBytes 1.45 Gbits/sec 804 sender 19:50:47 not sure what link speed that is, i thought it was 1Gbps but clearly not 19:57:46 pstef: line speed, the same like for OpenVPN + DCO 19:58:11 mzar / ivy: How does 220 Mbits/sec sound? 19:58:24 so I assume people choose ovpn over wireguard for reasons other than performance 19:58:35 dvl: still seems slow but hard to say without knowing more details (also i know very little about openvpn) 19:58:54 pstef: yes, that's true 19:58:58 pstef: openvpn has been around a lot longer, and it can do things like push config to clients (IP addresses etc) 19:59:00 ivy: It's a baby 4 ATOM CPU 1U 19:59:39 dvl: hm... it depends, How it worked without DCO ? 19:59:55 openvpn is also a bit more flexible, like you can run it over TCP if you really want, and i think it can do layer 2 tunneling, while wireguard only does L3 20:00:30 mzar: Well, a single connection test was about 72Mbit/s, with DCO, was 114 Mbits. 20:01:22 when the OpenVPN session was terminated on such hardware, in my case running iperf tests from the machine connected to network behind this ATOM gateway was giving better results than terminating iperf session on the ATOM gateway 20:01:26 mzar: I'm on a 1GB connection I'm sure. 20:02:17 a bit offtopic, but y'all have connections fast enough to justify playing fast car music whenever you log onto the internet 20:02:22 mzar: That is what I'm doing. the iperf server is on a server in the basement, not the openvpn server. And I'm testing from my laptop in the living room 20:02:38 it's a bit fascinating 20:02:45 Why would one use OpenVPN nowadays, when WireGuard is well-tested/proven/secure? 20:03:20 it looks like a decent setup for running tests dvl 20:03:52 The throughput seems to max out at 220 Mbits/sec 20:04:15 i.e. -P 65 and -P 80 were both 220Mb 20:05:50 regis: couple reasons: «it's what i know», functionality Wireguard can't do which OpenVPN can, and if you have customers who demand OVPN. 20:06:21 dvl: it could probably be improved 20:06:47 LXGHTNXNG: «it's what i know» is definitelly not the reason 20:06:58 mzar: with network tuning etc you mean? 20:08:49 LXGHTNXNG: kind question with no hate: what can't one do on WireGuard, and do on OpenVPN? I've worked with both and see no functionality decrease. 20:09:07 dvl: I don't know, I have one 8-core old ATOM, but it also gives me 800Mbps throughput when I terminate VPN session there 20:10:08 I have not thoroughly explored either option. 20:10:37 LXGHTNXNG: you wrote "functionality Wireguard can't do which OpenVPN can" 20:10:38 OpenVPN has come in handy for me in the past, and I've actually never really played with WG. 20:10:51 I suppose that should be interpreted as a hypothetical. 20:11:04 mzar: What is your connection size? At home, I have 300Mbit, but that does not factor into my test. 20:11:20 now if you'll stop hounding me, I have more important things to do, and lots of coffee to drink 20:11:47 dvl: I see, it could be really bottleneck 20:12:23 LXGHTNXNG: I'm not "hounding you" but am simply curious about your statement "functionality Wireguard can't do which OpenVPN can" 20:13:34 lessons from the Internet coal mines: killfile early, killfile often 20:15:32 regis: both OpenVPN and WireGuard are great protocols 20:18:25 mzar: Both are secure, as is the IKEv2+IPSEC setup. But nowadays you go for WireGuard and there's no need to use OpenVPN. I argued above that wg is somehow deficient in comparison. 20:23:10 I regret asking, I was just curious if there was any difference in performance between the two 20:25:18 pstef: kernel module wg is the go-to if you need some crazy efficient network performance. But for a common user, all these solutions work. 20:25:52 I chose wg for myself personally, only because I can't get excited about networking and this was the simplest solution 20:25:54 regis: no worries, OpenVPN is still secure, safe, robust, and the devs are using FreeBSD, they test each commit against FreeBSD so your user experience will be 100% OK 20:27:26 hello 20:29:28 mzar: I don't neglect OpenVPN in any way. I've replaced some shitty VPN protocols at some "VPN company". Introduced IKEv2+IPSEC, left OpenVPN and set up RADIUS for common login/password management. I don't hate OpenVPN. I simply say that it doesn't make sense nowadays :P 20:31:08 hm... sometimes customers require few certain features 20:31:48 I switch from ports to pkg. I pkg upgrade and now if I run pkg autoremove it shows 45 packages to be removed but these packages are needed. Any idea why this happens? 20:38:15 CyberCr33p: it happens from time to time 20:38:50 mzar I used the same ports options 20:39:13 Hi all - buying a few Supermicro servers and was curious if anyone can speak to how mature support for NVMe drives in hot-swap backplanes is in FreeBSD 13 or 14? 20:39:31 no worries, you can autoremove them and then install again 20:39:35 I think those are called "U.2" drives? 20:42:38 CyberCr33p: `autoremove` will uninstall packages which were installed as dependencies. If whatever needed them is removed, then autoremove will remove them too. If you still need something, install it manually. 20:42:56 CyberCr33p: Perhaps the dependency options changed on something you installed from pkg. 20:44:30 it shows for "autoremove" a lot of php extensions. But /var/db/ports/lang_php83-extensions and the same on poudiere ports directory are exacly the same. 21:16:19 dvl I just notice that I had options in /usr/local/etc/poudriere.d/142amd64 instead of /usr/local/etc/poudriere.d/142amd64-options or /usr/local/etc/poudriere.d/options , I will rename the directory and retry. 21:16:38 so they build with the default options 21:18:15 CyberCr33p: good luck! 21:18:32 99% I am sure this will fix the issue 21:18:35 :D