05:33:40 i'm trying to learn how to use freebsd as a wireguard server to torrent through. i can connect and pass traffic but something feels like not all traffic is going through. i'm using pf.conf to nat traffic out from wg client and rdr traffic in to wg client. https://paste.debian.net/hidden/551bbd71/ anything i can do better pls? 05:40:04 demido: do you want all traffic on that system to go through the vpn, or only torrent traffic? 05:42:55 well originally i just wanted the torrent traffic but now i'm trying anything, so i was basically passing ALL traffic through to wg client except the wg connection itself, and ssh 05:43:06 kinda desperate to figure it out hehe 05:44:00 demido: okay, well rather than using pf nat, i'd suggest using separate fibs (routing tables). for all traffic, set the fib 0 default route to the wg interface and configure the tunnels in fib 1, or for only torrent traffic, set the fib 1 default route to the wg interface and start the torrent client in fib 1 (but you need to be careful of leaking DNS traffic here) 05:44:31 ok can i ask eli5 why do "that"? 05:45:10 it's just neater - rather than messing around with NAT to make it work, you're just telling the kernel to do what you actually want, i.e. route traffic X via the vpn and traffic Y via the local router 05:45:26 also probably more reliable and easier to understand once you have it working :-) 05:45:44 ah ok so my pf is kinda a hack and maybe abusing pf 05:46:07 how do we work with fibs/routing tables? 05:47:14 so first off set net.fibs=1 and net.add_addr_allfibs=1 in /etc/sysctl.conf, then run "/etc/rc.d/sysctl start". now you have two routing tables, which you can view with "netstat -rn -F0" and "netstat -rn -F1" 05:47:24 er, net.fibs=2, sorry! 05:48:19 should net.add_addr_allfibs=2 too? or 1 05:48:26 no, 1 is fine for that 05:48:50 should i disable pf before doing this change? 05:48:52 if it says net.fibs is read only you need to set it in /boot/loader.conf instead, but i think it's been a dynamic tunable for ages 05:49:08 i would turn off your pf nat rules, you don't need to disable pf entirely if you have filtering 05:49:29 no filtering atm. want to get a solid connection first, then i'll experiment with filtering 05:49:41 ok i'll make those changes sec 05:49:48 * Afterglow is learning something here 05:50:50 I'm using FreeBSD since version 4.something, and I never heard of fibs (probably not knowing that I needed them :-) ) 05:52:05 demido: actually, after you set that i suggest rebooting to make sure add_addr_allfibs takes effect (i think this is only applied when interfaces come up initially) 05:52:06 ivy i have net.inet.ip.forwarding=1 in sysctl.conf, should i remove that? i read it was needed for the wg natting 05:52:22 that's not necessary for this setup but it won't hurt either 05:52:36 i'll remove. k gonna reboot box sec 05:53:06 also, do you have IPv6 here or only IPv4? and is the internet connection doing anything weird like DHCP or is it just a static config? 05:54:03 i didn't configure ipv6. don't know if it's automatic somehow? 05:54:14 just static conf 05:54:27 when reboot finishes i'll run netstat -rn -F0 and netstat -rn -F1 to look 05:55:50 ok i looked at routing table and routing table (fib: 1) 05:55:55 they look pretty similar at this point 05:56:17 yeah, they should be mostly identical except you won't have a default route in fib 1 05:56:34 so i guess to start with it's easier to just send all the traffic through wireguard 05:56:51 ok yes 05:57:12 all except the ssh into the wg server, and the wg client connection to the wg server which would create a loop, right? 05:57:20 first off you need to duplicate your current default route in fib 1, so for example "route add -inet default 1.2.3.4 -fib 1" (replace 1.2.3.4 with your default router), then make sure you can "setfib 1 ping freebsd.org" 05:57:38 yeah, the idea is to put wireguard itself in fib 1, which is similar to how linux does this with network namespaces 05:57:56 ahhhh 05:58:22 (and probably sshd too) 05:58:45 i ssh to wg server separately from the wg connection from wg client fyi 05:59:14 oh, do you have a serial / vnc console to access the server in case something goes wrong? this is not the type of config i like to do with only ssh access :-) 05:59:33 ok so that route command will add default route to fib1, the wg connection fib, so that the wg connection has a way out to the inet using the vpn's static ipv4 ip? 05:59:38 ya i do hehe 06:00:49 right, so to make it use that you need to put the wireguard interface in fib 1: "ifconfig wg0 tunnelfib 1" 06:01:25 is it possible to put "route add -inet default 1.2.3.4 -fib 1" into a file like rc.conf so it's permanent? i'm afraid to just type it, then forget later what all i did 06:01:32 (there are two ifconfig options here, 'fib' would put the encapsulated traffic into fib 1, 'tunnelfib' puts the wireguard traffic itself into fib 1, which is what you want) 06:01:42 demido: yes, we'll set this up in /etc/rc.conf in a sec, if it works :-) 06:01:52 ah ok great! sec i'll type 06:03:31 so the rc.conf option for the route is: static_routes="vpn"; route_vpn="default 1.2.3.4 -fib 1" (except use a newline instead of ';'), then you need to add tunnelfib to the ifconfig line, so something like ifconfig_wg0=" tunnelfib 1" 06:05:16 i ran sudo route add -inet default 1.2.3.4 -fib 1, then sudo ifconfig wg0 tunnelfib 1 06:06:58 i don't have an ifconfig_wg0. i have ifconfig_vtnet0..., then i have wireguard_enable="YES" and wireguard_interfaces="wg0" 06:07:06 is that a new line to add? 06:07:09 ah, you're using wireguard from ports, hmm 06:07:17 yep 06:07:34 it has config file in /usr/local/etc/wireguard/wg0.conf 06:07:46 there's a way to run a command in wg.conf for that, i think? in which case you'd want it to run 'ifconfig wg0 tunnelfib 1' 06:08:00 looks like PostUp=... 06:08:07 sec 06:09:23 brb 06:09:33 i still add static_routes="vpn"; route_vpn="default 1.2.3.4 -fib 1" to rc.conf right? 06:09:39 (on 2 lines) 06:13:05 ok i put those 2 lines into rc.conf, and the PostUp line into wg0.conf under [Interface] 06:13:16 yeah, that's right 06:13:32 they match the sudo commands 06:14:28 do i reboot now? 06:14:49 yes, reboot and make sure everything looks right 06:16:22 ok ssh back in gonna run netstat -rn -F0 and netstat -rn -F1 now 06:17:55 ok fib: 1 has default destination now 06:18:06 which is the static ip of the server and its physical if 06:18:18 well, "physical" (vtnet0) 06:18:32 is that all? connect from wg client and it should be good? 06:19:52 the route should be via the ip address of your default router, not the server's ip address... whatever's currently in defaultrouter="" in /etc/rc.conf 06:20:50 oh ok i'll fix that then reboot again sorry 06:21:18 same for the vpn route in rc.conf, that should be the same address as the default route 06:23:14 that's the only place i had to fix the ip 06:23:21 rebooting 06:24:27 ok now both fibs have default route, and gateway is the same for both, the router ip 06:24:57 now should wg client be connected? 06:25:20 yeah, wg should work now - after it comes up, make sure 'ifconfig wg0' shows 'tunnelfib 1' 06:26:26 on the wg server right? 06:26:53 wg0 has tunnelfib: 1! 06:27:36 is the machine you're working on now the client or the server? (i assumed this is the machine you're running the BT client on, or no?) 06:28:00 while wg client reboots.. how does wg server know that traffic coming to it should get redirected to the wg client EXCEPT wg connections from the client, and ssh connections from 'any'? 06:28:07 no i have 3 06:28:25 this 1, the vpn server is a vps in a shitty host, then the 3rd box is on my lan for torrenting 06:28:31 it's the wg client, the 3rd box 06:28:38 ah ok 06:28:45 i ssh from this computer into both 06:28:50 wg server and client 06:29:14 how does wg server know that traffic coming to it should get redirected to the wg client EXCEPT wg connections from the client, and ssh connections from 'any'? 06:29:45 hm, this may actually be an unnecessarily complicated configuration for what you're trying to do :-) 06:31:52 did we mess up? 06:31:52 i was thinking you wanted traffic from this machine to go over wireguard, but you want this machine to just be a router for another wg client, right? 06:32:07 ya 06:32:38 i want wg server to take connection from wg client, and basically pass ALL traffic through to/from wg client, as if wg client was the wg server 06:32:51 except ssh connections to wg server, and wg connections to wg server from client 06:33:16 it's so my isp doesn't see me running torrent traffic in/out 06:33:24 lots of udp and other p2p stuff 06:35:36 hmm, in that case you don't need the fib stuff (sorry!) but you might still need the static route to route traffic over the wireguard tunnel... or are you doing that in wireguard config right now? iirc, wg-quick can add a route for AllowedIPs automatically, but in this case you'd want AllowedIPS to be 0.0.0.0/0 06:37:10 btw wg client can ping wg server's private ip, but can't ping www.freebsd.org. wg client's wg0.conf has allowedips 0.0.0.0/0 for [peer] 06:37:28 not doing any route stuff in wg on server or client 06:37:46 only setting address, dns, private key, allowed ips, endpoint, publickey, and keepalive on client 06:38:25 wg server wg0.conf has address, listen port, postup we added, privatekey, allowedips is wg private ip, publickey 06:39:12 what should we do? 06:39:38 ok, so try this: remove the static route and fib config from rc.conf and the PostUp from wg config and reboot then, then in the server's wg.conf, you want something like "PostUp=/sbin/route add 192.16.0.10/32 wg0" ... i *think* AllowedIPs set to the client IP (192.168.0.10) there should be fine 06:40:08 although wg-quick may do this automatically, i'm not sure - if you start the wg tunnel without PostUp, do you see a route for 192.168.0.10 in netstat -rn? 06:41:20 lemme reset. on wg server commented out postup. now going to comment out 2 fib lines from sysctl, then comment out static_routes and route_vpn from rc.conf. then reboot. good? 06:41:36 yep 06:42:04 don't put the PostUp with /sbin/route in yet, see what the routing table looks like first 06:42:18 i know wg-quick has some magic here, i just don't remember what it is exactly :-) 06:42:23 yep, rebooting then will answer your q 06:42:27 yea lol 06:43:55 ok rebooted, on wg server, netstat -rn: 192.168.0.10 is in Internet: section, link#4 under gateway, UHS flags, wg0 netif 06:45:18 ok, make sure ip.forwarding is 1 still, put back your pf rule for 'nat on vtnet0', but not the rdr, just to test, then run 'tcpdump -ni wg0' on the server and try to connect to the internet from the client... you should at least see incoming traffic from the client 06:45:39 (i'm assuming the client is not freebsd) 06:45:42 k sec. no client is debian 06:47:03 ok forwarding is back in sysctl.conf. nat on vtnet0 from $wgclientip to any -> vtnet0, is back in /etc/pf.conf. reboot now? 06:47:07 (then tcpdump) 06:47:23 you can probably just /etc/rc.d/sysctl start; /etc/rc.d/pf reload 06:47:29 ok sec 06:48:07 on the client, just ping an IP address or something to avoid any other issues like DNS 06:49:39 ok on wg client i ping www.freebsd.org ip, and i see in wg server tcpdump it go through 06:49:46 oh not ntp went through too hehe 06:49:54 wg client got reply too fwiw 06:50:22 s/not/now 06:50:53 you're making a mistake here: wireguard doesn't know about server/client, only peers. And traffic goes from peer to peer, not 'through peers'. If you want a peer to route traffic for you to somewhere else than the peer, you need to NAT the traffic out of there 06:51:11 Afterglow: we're back to their original pf setup which has an outgoing nat for the wg peer 06:51:21 https://paste.debian.net/hidden/551bbd71/ 06:51:25 that was my pf.conf 06:51:53 (and yes, 'client' and 'server' is technically not correct terminology for pf, but... people do tend to use it :-) 06:51:58 s/for pf/for wg/ 06:52:51 demido: so is the client internet working now (via wg)? 06:52:51 so can i make my pf.conf better? 06:53:03 lemme test 06:53:50 ya i can curl an iso file 06:53:56 and do dns queries etc 06:54:26 that's odd, since i think we're back to your original config that didn't work... does it still work if you put the rdr rules back as well? 06:54:32 i didn't add the rdr nordr stuff back btw. only the nat 06:54:47 do i even need them? 06:54:53 i mean i guess so 06:55:13 i do want the wg client to be 'as if' it is the wg server, in the datacenter and not in my home behind my isp 06:55:15 depends, if you want to receive incoming traffic then yes, although my preference would be to just rdr the specific ports you need 06:56:06 well the wg client worked before as far as i could tell, it just didn't seem to get full bandwidth like it did from the server itself 06:56:08 (actually, my preference would be to use an entirely separate public IP address for incoming traffic, but i know that can be hard to do at cheap vps providers) 06:56:16 so i felt like i must not be forwarding everything bidirectional 06:56:23 ya 06:56:38 maybe the problem was i wasn't redirecting everything, but only >1024? 06:56:49 does anything <1024 make udp bandwidth better? 06:56:50 demido: are you downloading and uploading at the same time? because it's all going over vtnet0, your incoming traffic is duplicated as outgoing traffic and vice versa 06:56:58 yea 06:57:19 sorry i meant port 1024 06:58:14 (like say you have 100Mbps on the server, and the client is downloading something at 50Mbps, the server is sending 50Mbps of data out already, so the client would only be able to upload at 50Mbps...) 06:59:06 yea 06:59:55 what seems to happen is wg client doesn't establish as many p2p connections as wg server itself gets. for the same files 07:00:06 so it just felt like the proxying had to be flawe 07:00:07 d 07:00:14 but you guys can't see a prob in my pf.conf so it must be ok? 07:01:15 Afterglow you agree with ivy that https://paste.debian.net/hidden/551bbd71/ can't be improved? 07:02:31 ivy - true for half duplex, but I think full duplex through a switch can get you close to full bandwidth. On a hub, probably not. 07:03:09 demido, I'm not very specialized with pf, but I'll take a look 07:03:17 tyvm 07:03:38 it's mostly/completely udp traffic going through fwiw 07:03:51 but you see i redirected even tcp 07:16:30 is there anything in that pf.conf that doesn't keep established connections alive? i guess that doesn't even make sense in context of udp 07:24:47 find anything? 07:25:10 nope 07:25:25 ok so it looks good then? 07:45:04 Hi, Is it possible to read the handbook for older versions? Like imagine I want to use the handbook for FreeBSD 5 07:49:30 I found it anyway https://docs-archive.freebsd.org/doc/5.5-RELEASE/usr/share/doc/en_US.ISO8859-1/books/handbook/ 08:16:34 https://forums.freebsd.org/threads/installing-freebsd5-in-a-jail-in-freebsd14.96985/ 08:19:21 that was posted in the wrong forum 09:23:25 does anyone here running FreeBSD on macbook air 2012 and have get touchpad to work? and can share configuration for xorg.conf.d/touchpad.conf ? 09:28:54 got it working now, forgot to add moused_port="wsp0" and moused_enable="YES" :) 10:26:22 how can I find the service listening on a certain port (tcp4 882) when sockstat gives me question marks on USER, COMMAND, PID and FD? 10:30:15 <[tj]> k 10:30:46 <[tj]> are you sure it is listening? 10:31:19 <[tj]> does it appear in sockstat -sl 10:31:39 tcp4 0 0 192.168.13.16.882 *.* LISTEN 10:31:45 This is what netstat gives me 10:32:02 <[tj]> and what does sockstat give you? 10:32:31 ? ? ? ? tcp4 192.168.13.16:882 *:* 10:32:52 if I telnet into it, it sets up the connection 10:32:57 <[tj]> with -ls? 10:33:30 ? ? ? ? tcp4 192.168.13.16:882 *:* LISTEN 10:33:36 <[tj]> cool, I have no idea 10:34:19 I'm now tcpdumping it to see if anyone connects. This machine exposes nothing to the internet, btw 11:36:59 Afterglow: do you have lsof installed? 11:37:28 yup 11:55:29 Afterglow: sockstat -l and check suspicous PID 12:01:52 look at my sockstat output above: PID shows a questionmark 12:02:58 USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS PATH STATE CONN STATE 12:03:00 ? ? ? ? tcp4 192.168.13.16:882 *:* LISTEN 12:03:50 ridcully, trying `lsof -Pi4TCP | grep 882` doesn't show the process 12:06:02 ridcully, correction, doesn't show anything about port 882 12:49:52 To be complete: fstat -s | grep "tcp.*:882" isn't showing anything either 12:51:45 machine was rebooted yesterday, after upgrading to 14.2 13:52:40 Afterglow: the ? are specifically because there's no socket associated with it anymore 13:53:22 Found the culprit: after restarting lockd (nfs) the listening port vanished, and it opened another one 14:27:59 yeah that'd do it, too 14:42:40 Afterglow I had exactly the same finding today 14:43:41 https://forums.freebsd.org/threads/why-do-i-have-entries-at-the-end-of-sockstat-not-associated-to-any-service.96990/ 14:44:42 * ivy spies a kevans 14:45:36 * kevans runs 14:49:19 have a nice run kevans 14:49:50 .oO unleash the dogs:) 14:49:59 kevans: when you're done with your run please fix bug 284857! 14:50:35 i can unleash dogs but one is a little dachsund/chihuahua thing and the other only has three legs 14:50:52 i can not run fast but i could probably outrun them 14:51:18 :) 14:51:37 oh, a a ferret dog? we have one of those here 14:51:47 it can't go on a walk with the other dogs because it can't walk fast enough 14:52:18 ivy: I've still no idea how to fix this, I guess melifaro might have some idea 14:52:55 maybe i should try to fix it, it feels like it *should* be easy 14:53:22 last time i tried to fix a wg(4) everything went very badly though 14:55:22 i wonder where your EAFNOSUPPORT is coming from, precisely 14:56:30 i believe it must be in wg_output(): 14:56:31 uskerine_, hope you did find the perp too 14:56:32 if (parsed_af != af) { 14:56:32 xmit_err(ifp, m, NULL, AF_UNSPEC); 14:56:32 return (EAFNOSUPPORT); 14:56:33 } 14:56:42 i could add some debugging logs if that would help, though 14:58:35 ivy: tunnelfib: 1 ≠ route fib, what if tunnelfib = 0 ? 15:00:21 mzar: huh? 15:00:35 in your PR 15:00:45 which PR? 284857? 15:01:15 yes 15:01:34 i don't understand what you mean, "what if tunnelfib = 0" - but it's not, it's 1 15:02:41 OK, so set route with the same fib and use ping with the same fib and reproduce to make it consistent 15:04:20 huh? why? the route doesn't need to have the same fib 15:04:34 OK, if you think so 15:04:41 i know so, this is how tunnelfib works 15:04:55 cool 15:05:20 this is not a misconfiguration on my side, the problem is a missing feature in wg(4) 15:05:41 you have to submit a patch then 15:05:47 oh fuck off 15:05:58 i do not need to submit a patch just to report a bug 15:06:02 the bug exists, i reported it 15:06:12 obviously if i could fix it i would do, maybe i will have a go at that one day... 15:06:48 nice, but if you want to fix it, please submit patch 15:07:32 what is your point even 15:13:05 we always encourage to submit patches;) 15:25:03 :=D 15:27:41 next question, why can't i get Cy's patch in bug 284709 to work 15:27:55 for some reason the files that are meant to be in krb5-server keep ending up in krb5-libs 15:29:03 and the files that are meant to be in krb5-libs end up nowhere 15:42:29 okay, i think Cy's patch is wrong, this seems to fix it: https://github.com/llfw/freebsd-ports/commit/2dc14ff2035e76ec72fa6d6015705d40cebf86aa 15:45:05 ivy: yeah, if you can track it down (or ship me a VM or jail config that can reproduce it in isolation? that seems like it'd be feasible) I'd be happy to look more into it 15:45:30 kevans: i can give you two commands right now that would reproduce it? 15:45:39 alright let me grab my notepad 15:46:54 3!hemlock ~# ifconfig wg1 create inet6 -auto_linklocal -ifdisabled fe80::1/64 up 15:46:54 4!hemlock ~# route add -inet 192.168.1.1 -inet6 fe80::2%wg1 15:46:54 add host 192.168.1.1: gateway fe80::2%wg1 fib 0 15:46:54 5!hemlock ~# ping 192.168.1.1 15:46:54 PING 192.168.1.1 (192.168.1.1): 56 data bytes 15:46:54 ping: sendto: Address family not supported by protocol family 15:46:55 ping: sendto: Address family not supported by protocol family 15:47:30 you don't need a working wg peer since the bug is inside local packet processing 15:48:17 sorry, that was 3 commands, i lied :-) 15:52:27 ok fine 15:52:28 :-p 15:52:52 your guess about where it was erroring is infact correct 15:54:45 hmm, AFAICT that can likely just be removed and wg_xmit() will probably do the right thing; presumably your wg configuration would have IPv4 peers (we can have both IPv4 and IPv6 peers on one wg device, right?) 15:56:04 ivy: you want to test that with a valid setup? https://termbin.com/l8t6 15:56:17 kevans: i have no ipv4 peers at all, but i'm happy to test this 15:57:44 patch applied, building now... 15:58:19 hmm, that probably won't really function, then 16:00:11 Anyone else happen to be seeing strange issues with ROOT DNS servers right now? 16:03:15 ek: there are not thirteen but hundreds of root DNS server, so there's nothing to worry about 16:03:47 ivy: when I say 'ipv4 peers', I really mean one with some ipv4 allowed-ips which you'd need for the wg_xmit() lookup to work 16:04:31 kevans: does if (!(parsed_af == AF_INET || parsed_af == AF_INET6)) make any sense here ? 16:04:42 mzar: Yeah. The problem I'm seeing is that I'm no longer able to look anything up. 16:05:05 I have just built and tested it, works for me 16:05:07 mzar: no, we'll get that same effect in wg_xmit() anyways 16:05:22 OK, so kill it 16:05:25 kevans: oh right -- all my peers have allowedips 0.0.0.0/0, ::/0. but they run over ipv6 transport 16:05:47 haven't tested yet as build is still running 16:05:57 ivy: ok, so yeah- I think just removing that check entirely makes sense and will fix it, but I'll wait for confirmation before throwing it into a review 16:06:10 I have looked at tests, but we are not tesing ip6 for wireguard 16:07:35 kevans: in my case it worked, but I have changed to (!(parsed_af == AF_INET || parsed_af == AF_INET6)) what probably be always false 16:08:35 determine_af_and_pullup() will notably not return anything but one of the two or an error 16:08:52 so maybe a better fit as an assertion, but I'd be inclined to just let wg_xmit() complain 16:08:58 we can MFC it to 14 too 16:10:52 I have not spotted such a check for other tunneling interfaces 16:11:43 FreeBSD is working out for me 16:12:05 could have been lot better if we could have postgreSQL client in ports 16:13:23 Bushmaster: Not sure what you mean, but I see plenty of postgres clients available in ports. 16:23:27 ek, can you point me one 16:23:59 pgAdmin demand to work only with postgres older version and it removes my postgres17.4 16:24:08 hence i cant work with pgAdmin 16:24:42 do you have DBeaver in ports ek 16:25:45 Bushmaster: /usr/ports/databases/postgresql17-client ? Not what you're looking for? 16:26:04 Maybe our interpretations of "client" are different. 16:26:21 yes that is what I am looking for 16:26:52 you mean your interpretation 16:28:03 Bushmaster: there are some tricks you can try, likg locking the package, adding it by hand from file not repo, etc, you don't have to reubuild port in this case 16:28:14 s/liking/locking 16:29:22 mzar, have you tested it, i am kind of new to BSD 16:29:51 if you can help me to get pgAdmin install without it forcing me to remove postgre17 that would be BIG HELP 16:30:48 right now, if I do pkg install pgadmin it will just ask me to remove postgre17 16:30:54 that is not I am gonna do 16:31:09 if you can walk me from here, that would be big help 16:31:20 Bushmaster: read about locking packages and adding pkg by hand, read pkg(8), search for lock and add 16:31:38 not much help 16:31:40 dont't hesitate to do some experimentationg 16:31:55 experiment is for syadmin 16:32:08 i am not a sysadmin , I am Java Developer 16:34:34 you are probably one of devops ? 16:35:59 I'd keep quiet about that 16:37:07 ivy: thank you for fighting with bugs preventing IPv6-only deployment ! 16:38:53 mzar, no, not devops, java developer 16:41:27 Bushmaster: please don't hesitate to play a bit with packages, and you will be fine, there is no need to rebuild port in this case 16:42:46 okay cool 16:43:06 lot to catch up on when it comes to sysadmin, but yeah, I will look into it 16:43:16 Bushmaster: pgadmin is an graphical user interface client.. client is just the console client 16:43:45 i really need a better build system than this Ryzen 2700X 16:43:59 hernan604, i do not see any other SQL client in port collections, DBeaver is good one and like to see in port 16:44:13 i mean you even have RKWard for R programming 16:44:15 Bushmaster: stop saying client. you want a GUI 16:44:20 why cant you integrate DBeaver 16:44:41 these are SQL client, GUI client yes 16:44:54 Bushmaster: there are plenty of clients for postgres ot mysql in ports/pkg 16:45:10 hernan604, can you find me one? 16:46:42 Bushmaster: maybe this https://docs.vultr.com/install-pgadmin-4-for-postgresql-on-freebsd-12-2 16:47:20 let me check 16:47:52 I am in FreeBSD 14.2 16:47:58 not in 12.2 16:48:07 you think it will work? 16:48:10 should be the same 16:48:17 or similar 16:48:46 but you can always try a VM... or install pgadmin inside a linux vm 16:49:13 check vm-bhyve to manage VMs 16:50:33 this is web client, i may go for it 16:50:47 its pgadmin4 16:51:17 ivy: I went to write a test for it, but I'm realizing my route(8) knowledge is nonexistent beyond the absolute most basic usage 16:52:10 ivy: going for the reverse situation because it's easier to just adapt an existing test: route add -inet6 2001:db8::/64 -inet 169.254.0.2 -> 16:52:13 add net 2001:db8::/64: gateway 169.254.0.2 fib 0: Invalid argument 16:52:42 that doesn't seem very invalid damnit 16:52:52 kevans: i have never tried adding an ipv6 route with an ipv4 nexthop, but are you sure 169.254.0.2 is directly reachable? 16:53:03 e.g. did you add 169.254.0.0/24 over a wg tunnel already 16:53:14 yeah, it's the other side of this tunnel 16:53:48 epair on the other side is 192.168.2.2, wg in the other jail has 169.254.0.2 16:53:49 it might be this simply doesn't work because no one would ever test it :-) 16:54:18 what does "route -n get 169.254.0.2" say? 16:54:25 hernan604, that will not work, cos I have updated python in FreeBSD14.2 16:55:24 seems happy and describes a route to 169.254.0.0 with mask 255.255.255.0 via wg0 16:55:33 and virtual machine option is absurd, why on earth I need to install Linux inside FreeBSD and then try to run pgAdmin from there 16:55:47 kevans: you should probably submit this as a bug :-) 16:56:38 you have pgAfmin3 in ports ... all you have to do is find out a way to disentangle it from older version of portsgres 16:57:00 so that it can work for any postgres version 16:57:10 or add DBeaver in ports 16:58:02 kevans: https://www.le-fay.org/tmp/7d/route.txt -- this is definitely a bug 16:59:28 probably a bug in netlink, that broke a lot of things 16:59:44 many of which have seen since fixed, but i doubt anyone is using ipv6 route with ipv4 nexthop 16:59:56 s/seen/since 17:00:58 * kevans grumbles 17:01:25 noone but Juliusz Chroboczek 17:01:30 https://datatracker.ietf.org/doc/rfc9229/ 17:01:37 that's new. though 17:01:50 babel users gonna babel use 17:02:00 Bushmaster: then try building pgadmin from ports whith whatever version you want it to 17:02:49 hernan604, as I said I am not sysadmin 17:03:23 you said you have many SQL client, and then carried on talking 'crap' ... stay quiet my dude 17:07:34 lol 17:08:17 Bushmaster: you are lost. good luck 17:11:38 Bushmaster: i will be telling my friends about this java developer... that never used freebsd, and he said freebsd has no clients for postgres LOL... and he is looking for a postgre client... and then when i suggested him to manually build a pgamin port, he said "he is not a sysadmin" hahahhahahaha 17:11:49 welcome to the console my friend 17:11:55 to unix 17:12:14 you talking crap ... stay quiet 17:12:22 you are a troll 17:12:23 bye 17:13:14 Bushmaster: pgAdmin works with any posgres version, the problem is that it has to be build for a concrete version, so it is build against the 'default' version, so either switch stuff to the default versions in the official pkg repos, build your own pkgs with changed default versions or search for some other solution 17:16:36 nimaje, i understand , as I said I am not a sysadmin but yeah build your own pkgs with changed default versions is something I sure will able to do over time, I do not see you or anyone else can help me to get it down, if I wanna get it done, I sure can, just will take me time 17:18:45 it should not be build against the default version, it should be independent cos it is simply a postgrSQL client, which should work for any postgreSQL versions. Same as DBeaver, it can work with any SQL servers, so do SSMS which work with any Microsoft SQL Server versions 17:18:53 ivy: weirdly enough I reconfigured it to use your original scenario and I get a routing error instead of EAFNOSUPPORT, but `route get` clearly indicates it trying to route traffic to this IP via wg0 17:19:07 ?? 17:19:11 kevans: on 15.0? 17:19:16 yeah 17:19:19 though I'm a few months old 17:19:38 it's possible this actually worked a few months ago, i'm sure i used it before, i only noticed it was broken recently 17:20:57 ah, build finished, let's test your patch 17:27:02 kevans: bad news, it still doesn't work, same error 17:27:09 [2!] uk-myb-1 /# route add -inet 192.168.1.1/32 -inet6 fe80::2c8f:916:ed09:eae1%wg.uk-aai-1 17:27:10 add net 192.168.1.1: gateway fe80::2c8f:916:ed09:eae1%wg.uk-aai-1 fib 0 17:27:10 [3!] uk-myb-1 /# ping 192.168.1.1 17:27:10 PING 192.168.1.1 (192.168.1.1): 56 data bytes 17:27:10 ping: sendto: Address family not supported by protocol family 17:27:51 wait 17:27:55 this is the wrong kernel 17:28:11 lmao i forgot to push 17:28:16 ha... 17:28:30 it worked for me, I applied on both ends 17:28:39 i cannot be held responsible for your shenanigans :-) 17:28:41 ivy: I am going to reply to your PR 17:29:08 ivy: I will submit a patch, which will probably be rejected ;-) 17:29:12 ;-P 17:29:13 kevans: in my defense i'm working on like 5 PRs right now across src and ports 17:29:24 mzar: if it's just kevans' patch i assume he'll accept it? :-) 17:29:42 ha... that's different one 17:30:16 buildworld done (52 seconds), buildkernel done (25 seconds), now waiting for update-packages which is usually like 500 seconds 17:30:24 i wish we could find a way to make this faster 17:32:16 i just want this test case to work 17:32:51 i'm |-| here at posting a phab review, but I want to see a test case go vroom vroom firs. 17:32:54 first 17:33:24 i can't test this properly until i work out how to make OSPFv3 advertise IPv4 routes with IPv6 nexthop, which i'm honestly not sure is even possible with BIRD 17:33:37 but i can at least show you packets going over the tunnel 17:34:48 this routing table seems sane, right? https://termbin.com/lx9z -- in this one, 2001:db8:1::1 is the local wg1, 2001:db8:1::1 is the remote wg2, 192.168.3.1 is some address on the other side 17:34:56 ... ::2 is the remote wg2 17:35:11 ping: sendto: No route to host 17:35:42 that looks wrong, 192.168.3.0/24 is via 2001:db8:1::1, but 2001:db8:1::1 is via lo0 17:37:09 * kevans swaps it in for using the 'other side' of the tunnel as the gateway to same effect 17:37:10 perhaps you meant to add 192.168.3.0/24 via 2001:db8:1::2 17:38:09 ok, packages built, rebooting now 17:39:58 [3!] uk-myb-1 /# route add -inet 192.168.1.1/32 -inet6 fe80::2c8f:916:ed09:eae1%wg.uk-aai-1 17:39:58 add net 192.168.1.1: gateway fe80::2c8f:916:ed09:eae1%wg.uk-aai-1 fib 0 17:39:58 [4!] uk-myb-1 /# ping 192.168.1.1 17:39:58 PING 192.168.1.1 (192.168.1.1): 56 data bytes 17:40:05 [1!] uk-myb-1 /# tcpdump -ni wg.uk-aai-1 host 192.168.1.1 17:40:05 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode 17:40:05 listening on wg.uk-aai-1, link-type NULL (BSD loopback), snapshot length 262144 bytes 17:40:06 17:39:51.238732 IP 81.187.47.201 > 192.168.1.1: ICMP echo request, id 58121, seq 0, length 64 17:40:10 that seems to be working 17:41:48 there, got the test to work 17:42:21 don't ask me how, but it does what I want it to and demonstrates the error but works after 17:46:00 https://reviews.freebsd.org/D49172 17:55:31 that's probably another bug: link-local address not working over wg(4) interface 17:56:40 err - wrong window 17:56:53 but wg interfaces aren't really local, are they 17:57:25 yep 17:57:56 so ND resolution is rather not supposed to work here 17:59:49 anyway, the PR 284857 describes the problem with IPv4 routes with IPv6 next hops over wg intefrace, and proposed solution fixes this issue 18:01:43 mzar: link local addresses work fine over wg(4) though? 18:01:56 i have like 20 bgp/ospf peers over link local addresses on wg(4) 18:02:40 bird> show ospf neigh lf6 18:02:40 lf6: 18:02:40 Router ID Pri State DTime Interface Router IP 18:02:40 10.1.2.2 1 Full/PtP 35.866 wg.uk-myb-2 fe80::340c:19c6:1b3b:730b 18:02:40 81.187.47.194 1 Full/PtP 34.618 wg.uk-aai-1 fe80::2c8f:916:ed09:eae1 18:03:31 nice, so it's not broken 18:04:39 there's no NS/ND since wg(4) is a PtP interface that pretends not to be in a way i find unhelpful 18:04:47 but that's how wireguard works, i don't think freebsd can fix that 18:05:00 ivy: I have responed to your PR, since I have spent some time testing this issue, there is no any race with kevans's approach, just to confirm that it was broken 18:05:28 mzar: i saw your patch, i have no opinion on whether that or kevans' is preferable 18:07:45 huh what? pkg-static: krb5-1.21.3 conflicts with krb5-libs-1.21.3 (installs files into the same place). Problematic file: /usr/local/bin/compile_et 18:07:59 oh never mind, i know what's going on 18:09:24 well, sort of -- i'm not sure why jellyfin depends on krb5... i don't remember it supporting Kerberos authentication 18:22:05 I have one lingering problem with pf: the rules won't load on boot. https://bsd.network/web/@dvl/114082898655646261 18:24:16 dvl: what's the point of a bogons table? 18:24:47 ivy: Blocking networks which have addresses which are not assigned to anyone. 18:25:01 dvl: sure, but why? 18:25:11 ivy: ... because I can...? 18:25:15 Or perhaps I can. 18:25:17 but you can't :-P 18:25:25 if pf cooperates 18:25:40 i mean your question is valid, i'm just not sure this is a useful thing to do... 18:25:44 Not at boot, yet. This must be a solved problem. 18:26:12 FWIW, it is commonly done on appliances 18:26:29 less nowadays, i feel 18:26:41 it's not like the 90s when everyone took a bogons feed from team cymru 18:27:22 Ironically, that's the one I'm using. 18:28:12 yeah, i looked at doing that too but i couldn't see any benefit 18:28:29 *maybe* for a transit ISP, to avoid wasted bandwidth if nothing else 18:28:39 but for an end system? i don't think you gain anything 18:30:40 why is security@ discussing Bible passages? 18:32:12 dvl: what does "pfctl -sm" show ? have you tried to increase the limit ? how many addresses do you have ? 18:33:44 mzar: https://dpaste.org/VgJOM - I have not tried increasing the limit, mainly because it works after boot. 18:34:37 ivy: looks like a troll or maybe misdirected mail? seems like it's in reply to something but the thread it's in doesn't seem to match where they replied 18:35:54 this is new https://i.imgur.com/gmTDD7q.png 18:36:01 no, I found it. They seem to have been set off by something in someone's signature. 18:37:37 ah, looks like https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282605 18:37:38 dvl: it could be problem with: 1. table too small 2. pf cannot parse so large file (too many entries to be added at once) 18:37:57 if the table is too small, try to increase its size 18:38:08 mzar: I wonder why it fails at boot time. Let's see what I have now: 18:38:15 if there is a problem with processing large file, please split it 18:38:29 at boot time ? 18:38:37 PF i loaded later 18:39:24 s/i/is 18:39:27 mzar: The problem occurs when booting the host. 18:39:50 mzar: After it boots, I ssh in, run `pfctl -f /etc/pf.conf`, done. 18:40:20 ha.. 18:40:23 mzar: I say boot, I mean during system startup. 18:42:21 anyway, you are close to this value, maybe it's worth increasing this limit ? 18:46:37 mzar: Agreed. I'll paste what I did. 18:50:22 mzar: https://dpaste.org/gzzRM 18:50:27 * gman999 waves to dvl 18:50:32 Next goal, reboot. 18:50:46 mr gman999 18:51:28 gman999: I thought about you one cold morning... it reminded me of you saying it was pretty safe in the neigborhood when it was real cold, not so much when it was real hot. 18:51:36 :) 18:51:58 unlikely i'l be at bsdcan this year 18:52:03 unfortunately 18:52:21 now there's a product: bsd in a can 18:52:40 located in a small cold city with good kebab 18:52:50 gman999: I will probably be there. 18:52:57 good. 18:53:05 patrick will be my proxy... as always 18:53:19 sends a flurry of 'hellos' when at a con 18:53:20 all we need to make that happen is FreeBSD running on a 2013 Mac Pro 18:53:35 gman999: You'll remember the year I won a NetGate appliance, 10 years ago... that unit will be up for auction this year. I am retiring it. 18:53:43 ha 18:53:49 yes... long time ago 18:53:53 oh BSDcan is in the USA 18:54:02 jbo: You are mistaken. 18:54:04 ha.. 18:54:12 dvl, I think trump disagrees 18:54:19 i'll give ottawa the kebab point. 18:54:25 well, and other things 18:54:43 another nycbsdcon will be difficult in the near future... 18:54:46 we have to see at some point. 18:54:52 i dont have the time... 18:55:06 and we struggle to get speakers for regular meetings at this point. 18:55:12 we see though 18:56:16 gw reboot time /cc mzar 19:05:14 mzar: Still does not load on boot. 19:07:56 ha.. problem with parsing so large file, most likely 19:08:27 maybe you can split it into two and add some bogons later, as a workaround 19:11:47 wait you're parsing bogons for something dvl? 19:11:59 issue loading a bogon table or something? 19:15:25 gman999: yes, also tried moving the syctl into /boot/loader.conf, but nope. https://bsd.network/web/@dvl/114082898655646261 19:16:02 mzar: on boot, 1 - empty the file, 2 - start pf, 3 - load up the file 19:16:38 I'd rather do it in diffent way 19:17:33 pfctl -t bogons -T add -f complete_set 19:17:47 and at boot try smaller set 19:18:41 adding this to rc.local will work, but after reloading PF someone has to fix it, either the sysadmin or cron 19:18:49 anyway, duct tape fix 19:19:01 mzar: a cron job for @reboot 19:19:40 it's worth filling a PR though 19:19:41 mzar: I don't want anything requiring manual steps 19:19:54 mzar: OK, I shall. 19:23:18 in the past I tried to fix similiar problem using anchors and loading these anchor from files, but it didn't help much and only made things more complex 19:42:59 mzar: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285081 19:43:49 dvl: have you tried setting the pf table sizes via loader.conf? sysctl.conf stuff is loaded much much later 19:44:13 zi: How do I set pf tables sizes in loader.conf? 19:44:32 vi /boot/loader.conf 19:44:36 shove sysctl.conf lines into file 19:45:21 ^C:wq 19:45:27 shutdown -r now PRAISE ZI 19:45:38 something to that effect 19:46:04 First, I need to find the sysctl items. I have tried net.pf.request_maxcount=350000 in there, no fix. 19:46:38 net.pf.states_hashsize 19:46:38 Size of hash tables that store states. Should be power of 2. 19:46:38 Default value is 131072. 19:46:38 net.pf.source_nodes_hashsize 19:46:38 Size of hash table that store source nodes. Should be power of 19:46:39 2. Default value is 32768. 19:50:39 here we go again! 19:54:58 may the odds be ever in your favor 19:59:01 zi: added the entries, rebooted, values are not changed. 19:59:43 zi: this is how we do it... https://dpaste.org/HyXLS 20:00:17 what do you mean that they were not changed? 20:00:30 are you loading pf @ boot as well? 20:00:34 [19:59 gw01 dvl ~] % sysctl net.pf.states_hashsize net.pf.source_nodes_hashsize 20:00:34 net.pf.states_hashsize: 131072 20:00:34 net.pf.source_nodes_hashsize: 32768 20:00:39 if the module isnt there, you cant set settings from within the module 20:00:46 oooooo 20:00:52 * zi taps forehead 20:01:34 Never done that before~ 20:02:08 pf_load="YES" 20:02:12 and again 20:04:08 hope you are getting your card punched each time 20:04:15 you'll be in the frequent rebooters hall of fame in no time 20:10:08 indeed 20:10:34 zi: see anything wrong in my config? https://dpaste.org/zjJ5s 20:12:57 can you share the output of the 2 sysctls you are changing (sysctl xx) 20:13:09 and then grep -r net.pf /etc/sysc* 20:15:39 and grep set /etc/pf.conf* 20:22:18 [20:10 gw01 dvl ~] % sysctl net.pf.states_hashsize net.pf.source_nodes_hashsize 20:22:19 net.pf.states_hashsize: 131072 20:22:19 net.pf.source_nodes_hashsize: 32768 20:22:58 [20:22 gw01 dvl ~] % grep -r net.pf /etc/sysc* 20:23:41 /etc/sysctl.conf.local:net.pf.request_maxcount=550000 20:23:50 [20:23 gw01 dvl ~] % grep set /etc/pf.conf 20:23:50 set limit { states 200000, src-nodes 100000, frags 200000, table-entries 350000 } 20:23:50 set block-policy return 20:23:50 set loginterface $ext_if 20:23:50 set skip on lo0 20:24:00 and no dpaste for me. 20:24:40 % grep pf loader.conf 20:24:40 net.pf.source_nodes_hashsize="1048576" 20:24:40 % sysctl net.pf.source_nodes_hashsize 20:24:41 net.pf.source_nodes_hashsize: 1048576 20:24:49 it looks like if you have /usr/obj on tmpfs, WITH_META_MODE=yes is not respected. Of course, if you try consecutive rebuilds ( without reboot, because /usr/obj gets cleared ). Is this expected behavior? 20:24:53 quotes 20:25:25 you must quote it 20:25:26 quote it good 20:25:48 can't reboot right now... $WORK 20:25:54 hah 20:25:58 keep your punchcard handy 20:26:32 dvl: maybe adding PF to kernel will help to fix this problem 20:27:01 mzar: and go away from RELEASE ...?! o.O ;) 20:28:45 I am sorry, wrong advice, let me apologize, I am not much using RELEASEs 20:30:38 mzar: No apology necessary, it is a valid suggestion, and my reply was joking. 20:31:41 bye 20:37:01 zi: no workie. I find edge cases. 20:39:34 must be doing something funky here 20:40:14 those settings def work, at least on this 13.4-R box 20:50:33 I do find edge cases. 20:58:03 i love edge cases 21:01:47 Interesting, if I empty the large file, reboot, still does not load the rules. I suspect something else is blocking this. I'm going to visit the console in the basement. SOmetime.... 21:02:55 maybe fire up a VM to test the loader bits in isolation 21:16:52 zi: You'll remember the old console server.... I scrolled back, found the pf errors stopping the load. Well, I got the rules to load by fixing the hostnames, vs IP addresses, which crept into my pf macros. I also emptied the table file. I'm going to load that back up and try again. Still default values for net.pf.states_hashsize & net.pf.source_nodes_hashsize 21:21:46 maybe restore pf.conf to defaults/no tables and just get the loader knobs applying correctly, then start reintroducing stuff 21:22:18 and/or move this into a vm for testing so you arent bonking (what im assuming is) your nat gateway 21:23:48 Yeah, it's my nat gateway. 21:24:33 zi: I have solved the major problem of the rules not loading on reboot. 21:25:51 I am not able to get net.pf.states_hashsize set away from default. Yet that is not stopping the table from loading. 21:30:25 rgr 21:31:19 I've closed my PR and apologized. 21:31:46 zi: Thanks for helping. Sorry for the noise. 21:32:00 mzar: you as well, thanks. :) Fixed. 21:33:12 nw 21:33:49 thank you for giving the opportunity to help with this troubleshooting dvl ! 21:34:09 no worries. always happy to share the grief. 21:35:49 lol 21:37:51 are we sharing grief? I'm here. 21:39:51 jbo: I kind of think the answer is that the -newlib port needs to go away 21:40:39 kevans so we are indeed sharing grief then :< 21:40:41 I think life would be better if the -gcc port instead fetched newlib and built it, then libstdc++, and distributed both (maybe later in subpackages) 21:40:57 I don't think it realistically adds much to the build time of a gcc 21:41:10 kevans, is -gcc fetching and building newlib even an option? that sounds like a lot of hassle. 21:41:21 I wouldn't be worried about build time either. I'm more worried about the complexity. 21:41:27 well it's not technically hard to do in ports 21:41:41 kevans, are you going to do it then? <3 21:41:45 it would save me so much hassle every day... 21:41:46 my main concern would be how it current builds, and whether we'd need to swap in our own do-build to drive it all manually 21:42:26 kevans, just out of interest - why do you think that this is the solution vs. just having a -newlib port? Is the problem that the -newlib port would need to be built by the particular -gcc port? 21:42:50 it's mainly that, afaict, a -libstdc++ port would largely be duplicating a -gcc port 21:43:21 because it's distributed with gcc, same build system, need same options, etc 21:45:16 I see 21:45:26 how complex do you think this whole operation would be? 21:45:34 probably not too bad 21:46:15 thank god it's weekend now? :') 21:46:32 well, there's a complication there 21:46:58 it's going to be above 0*C this weekend and relatively nice outsside <_< 21:56:24 hah 21:56:28 well, I hope you can enjoy that :)