00:02:48 has anyone tried the new PF NAT64 support in 5.0 (pass in ... nat-to)? it seems to work but i can't get ICMP errors to be delivered, so e.g. traceroute doesn't work 00:02:53 s/5.0/15.0 01:34:03 ivy: if you look at the commit which introduced nat64 support, it seems you should be getting those 01:34:06 https://cgit.freebsd.org/src/commit/?id=fcdb520c1b4e1a5d5a2e54cb916dccbc848d32ba 01:34:52 gt: i think it's because i'm missing this one: https://cgit.freebsd.org/src/commit/?id=25dbba4fc6e152a05e091180b2e031ab495ba337 - need to wait until later to test though 01:37:21 interesting 01:47:55 ivy: can you confirm that it works trying a pure icmp traceroute? 01:48:41 ICMP doesn't work either, but i'm hoping this actually fixes both despite the commit message not mentioning it, if not i'll open a bug 01:50:20 so you can't even ping any node atm? 01:50:58 oh, normal ping works, i mean ICMP traceroute doesn't - the problem is specifically how the ttl exceeded packet is translated 01:51:42 for ICMP traceroute it seems like the error is dropped entirely though, so... we'll see what happens 01:51:53 traceroute -I $host, or traceroute --icmp $host should do a pure icmp traceroute with no udp shennanigans 01:52:56 that's what i'm talking about - neither ICMP nor UDP traceroute works, but even though the commit message only mentions UDP, i'm hoping it will also fix ICMP traceroute as the fix doesn't look protocol-specific 01:57:25 got it thank you, i was just curious and have no way of testing it myself atm (i actually implemented a pure icmp ping/traceroute library back ~2015 in golang) 02:18:26 ivy: i'm not sure they'd appear in pflog if there's an underlying bug (by explicitly adding a log rule for icmp types), but you can try tcpdump to see if they're even hitting the interface 02:19:23 they should be 02:30:44 at least the incoming ones, if you don't even see the outgoing icmp packets, then that'd be 150% pf's fault 02:32:24 incoming packets on the interface will be captured by tcpdup before they're processed by pf, but outgoing ones could only have gone through pf first 02:54:30 The latest cpu-microcode-intel 20250211 is causing my workstation to crash on boot. Anyone else have success or otherwise? 03:23:13 This is on a 7th gen Intel i7, but I notice the updates don't pertain to this particular generation 06:04:55 something seems to have broken IPv4 routes with IPv6 nexthop over wg(4), even though it works fine on Ethernet 06:05:45 forwarded traffic just vanishes, and local traffic gets 'no route to host' 06:22:10 filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284857 ... i'm sure this used to work fairly recently 06:24:51 ivy: Connection over IPv6 or v4? 06:25:08 ek: the Wireguard tunnel is using IPv6 transport 06:25:52 ivy: So, connecting to server via v6? 06:26:17 And routing v6? Or routing both v4 and v6? 06:26:47 do you mean the tunnel or the encapsulated traffic? the tunnel is configred with IPv6 endpoints, the traffic being passed is IPv4 but with an IPv6 nexthop (over the tunnel) 06:29:18 or the traffic *not* being passed, i should say... IPv6 traffic is working fine over the tunnel 06:29:37 ivy I guess both? I was wondering if the WG server was listening on both v4 and v6, what the WG tunnel was offering to accept as a forward (end-point or otherwise) and what you were expecting on the client-side (full v4/v6 from end-point or otherwise.) 06:29:43 But, I get it. 06:29:55 ek: wireguard only listens on IPv6 06:30:16 and allowed ips is set to 0.0.0.0/0, ::/0 on both sides 06:30:16 I'll see if I can test this and reproduce. 06:30:47 ivy: It's assigning both v4 and v6 then? 06:30:54 ... to the client? 06:31:23 no, the only addresses on the wg interfaces are fe80::1 on one side and fe80::2 on the other side, so all the routes are using the link local gateway 06:31:26 I shouldn't say "assigning." But, accepting. 06:32:26 ivy: I would think that should be fine as long as the link-local can be used as a gateway. And, you say v6 is working fine, but v4 isn't? 06:32:54 right 06:33:44 and it's not ipv6 nexthops being broken in general (which happened a while ago) since the same thing works fine over an igc(4) interface when wireguard isn't involved 06:34:05 the error is weird too: 06:34:07 PING 46.235.229.111 (46.235.229.111) from 81.187.47.196: 56 data bytes 06:34:07 ping: sendto: Address family not supported by protocol family 06:35:58 Hrm. That almost looks like an issue with the way the routing is happening. Is the 81.187.* address your WG client? 06:36:37 If so, shouldn't that have an RFC1918 address the v4 side? 06:36:41 they're both servers (or peers) as far as wireguard is concerned, neither is really a client. 81.187.47.196/32 is assigned to lo0 on that side 06:37:31 Ah. I gotcha'. Peer-to-peer setup. Not a client<->server setup. 06:38:08 (ping -S is needed because freebsd source address selection is broken for ipv4 when the source address is on lo0, which is also annoying but it's a separate issue) 06:40:52 I haven't done a WF P2P setup yet. So, I'm afraid I won't be of all that much help here. However, does this help at all?: https://forums.freebsd.org/threads/ping6-address-family-not-supported-by-protocol-family.51467/ 06:41:59 that looks like it was a bug in the poster's own application 06:43:05 Yeah. It does. I also didn't notice how old it was. I don't think that's related. Sorry. 06:43:07 i suspect something is going wrong inside wg(4) when it looks up the nexthop 06:43:23 i don't see any recent commits to that code though 06:43:47 i wonder if i can get BIRD to add these as interface routes instead... 06:44:25 I would think that's very possible. 06:47:26 it is not urgent so i might just wait to see if someone fixes it :-) 06:49:43 ivy: With any luck, the bug reported should turn up something. 06:50:43 You're not doing any v6<->v4 negotiation between the two hosts, right? Nothing out of the ordinary? 06:50:55 Like, no conversions? 06:51:47 BGP is running over the tunnel (which is what adds the route), but nothing particularly unusual. other than ipv6 nexthops for ipv4 i guess, which doesn't seem to be all that well tested 06:54:02 Hrm. I'm not sure why any of that wouldn't work. Seems (fairly) straight forward. Perhaps it is a bug with nexthops. Not sure. I'm going to follow that bug, though. 07:36:12 hey guys. I'm trying to determine the current global v6 address from python code, and got all v6 addresses printed out very quickly using pyutils.net_if_addrs. my problem is now: how do i deal with deprecated prefixes? i need to know which ip address would be used to establish new connections 07:36:27 *psutils, not pyutils 07:37:31 i did some quick google searches on how to deal with that, but the complexity seems to be rather high compared to the 4 lines needed to just get the addresses 07:37:32 Grabunhold: a much easier way to do that is to connect() a UDP socket to the target, then use getsockname() to find the local address. that won't generate any network traffic 07:38:00 ivy: that sounds good! 07:38:35 trying to reliably reproduce freebsd's source selection algorithm would be unreasonably difficult, especially for ipv6 as you have to deal with the RFC address selection policy which the administrator can customise 07:40:59 so if i understand correctly, by opening a new socket, i let the OS do it's thing regarding v6 address selection and then simply look at the address it has chosen 07:41:25 and that should, without customization by the admin, be the most recent prefix? 07:42:10 not necessarily "the most recent" -- e.g. if you connect to a link-local address it will choose the appropriate link-local address as source, even if a ULA/GUA prefix is assigned 07:44:34 it will also prefer ULA source when connecting to a ULA, and vice versa for GUAs 09:25:39 ivy: my usecase is determining which address to use to update an AAAA record of the machine. my ISP might push a new v6 prefix, and I want to notice and update that record 09:26:58 so if i point the UDP socket to a GUA (globally unique address, i guess?), it should pick the address generated using the recently pushed v6 prefix over the deprecated one? 09:55:23 hi, I trying to play around with pf and altq.. https://pastebin.com/04F2NNa9 when I running pfctl -nf /etc/pf.conf I got syntax error on line 11 that is queue highprio.. and I cant really see whats wrong and i wondering if someone can point me in right direction? 10:01:08 Grabunhold: assuming nothing unusual is going on, probably, yes 10:01:42 if this is DHCPv6-PD though, it might make more sense to do this in a script that runs when a new binding is received 10:03:26 (if it's just SLAAC, i don't think FreeBSD has a way to hook a script for that though) 10:25:29 nwe: `max 10Mb` is the problem 10:34:25 ridcully: so it means it will by default only allow max 6Mb ? 10:52:41 is it still the case that you should disable LRO and TSO on router interfaces, or is that out of date? 11:19:26 ivy: it's just SLAAC 11:22:48 ivy: will try my luck with the UDP socket under the assumption that my network is not too unusual. we'll see how it goes. I can report back if you're interested (but it might take me a few days to get around to actually implement that script) 11:23:10 thanks for your input and time, it's very much appreciated 11:53:27 I using qemu with network-driver intel e1000 (found in FreeBSD as em0) and in man altq I can read that em driver should support ALTQ, but when I trying to load my pf.conf it complain about 'altq not defined on em0' should I take that s em0 doesnt support ALTQ ? 12:10:35 nwe: side note: you might want to switch to virtio interfaces when using FreeBSD as a guest on qemu 12:14:34 Grabunhold: I will change to start using virtio instead, do you know if vtnet0 support ALTQ ? 12:14:57 i do not, sorry 12:15:17 but virtio should universally be better if you care about network performance 12:15:44 emulation real hardware is usually a fallback for situations where guest-side paravitualized drivers are not an option 12:15:51 *emulating 12:15:54 em(4) does support altq according to altq(4), while vtnet(4) is not listed there 12:16:17 Grabunhold: I dont running FreeBSD on my firewall now, and I testing it in a virtual machine to maybe later switch and convert existing firewall-rules to pf (Freebsd) 12:16:20 ivy: maybe the driver supports it, but the hardware as emulated by qemu does not? 12:17:02 Grabunhold: looks like it is as you say.. the hardware emluated doesnt support it.. 12:17:29 becuase both vtnet0 and em0 doesnt work both complain about vtnet0 and em0 doesnt support ALTQ 12:17:55 nwe: did you compile a kernel with altq support? i don't think it's in GENERIC 12:19:59 ivy: nope Hasn't compile anything just installed FreeBSD on this vm 12:20:52 nwe: you will need to build a custom kernel with the options described in altq(4), see https://docs.freebsd.org/en/books/handbook/kernelconfig/ 12:21:43 okey will look into it :) thanks for pointing this out =) 12:22:50 also i would be surprised if vtnet didn't actually support altq, the documentation may just be out of date 12:23:52 ivy: I will start to read and compile custom kernel 12:24:01 and see if it´s working after that 12:26:52 don't expect too much performance if you have to use emulated e1000 h/w though 12:27:24 emulating real hardware via qemu comes at a considerable price 12:28:07 Grabunhold: this is not for performance just more for learning ALTQ (FREEBSD) and also test convert existing firewall to FreeBSD PF =) 12:28:20 so I later on can just drop replace my hardware :P 13:49:18 Grabunhold: ivy: after I recompile the kernel with ALTQ it´s working :) but another stupid question.. if I want to limit one queue to say only 1 Mbit should that queue look like this "queue sco bandwidth 1Mb priority XX , I trying to scp (because I have set that pass in on $ext_if proto tcp from any to any port 22 queue scp . but when I scp a big file it still going over 1Mbit. 15:30:42 Where do I find a complete list of etherner vendors that is downloadable, machine-readable and free? 15:32:40 <[tj]> https://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml 15:32:57 <[tj]> the people that assign internet numbers seems like a good starting point 15:38:08 Indeed. Thanks.vse/get-db?t=25-01-26"; proccmd="gawk --csv '{print $1 " " $2}' @tmpfile@ > @oidfile@" 15:38:11 oidurl="se/get-db?t=25-01-26"; proccmd="gawk --csv '{print $1 " " $2}' @tmpfile@ > @oidfile@" 15:38:44 bah. cat. 15:39:23 I'vebeen using se/get-db?t=25-01-26"; proccmd="gawk --csv '{print $1 " " $2}' @tmpfile@ > @oidfile@" 15:39:45 'me gives up 15:40:57 sign. This. https://www.wireshark.org/download/automated/data/manuf.gz 15:41:17 <[tj]> what are you trying to do? 15:41:37 <[tj]> there is a web oui look up with the wireshark data here: https://www.wireshark.org/tools/oui-lookup.html 15:44:14 No, I need it downloaddabke so I can read it in whatever fom it ar arrives in and ad it to be datbase. 15:48:51 <[tj]> gzcat manuf.gz | grep FreeBSD 15:48:51 <[tj]> 58:9C:FC FreeBSDFound FreeBSD Foundation 15:51:10 ghoti: I made a Rust crate for that last week, if you look in the tools folder here there is a script to download them all: https://github.com/erk-/macnuf 16:22:12 I have a VPS on DO. Loopback jails are fine. I now created a VNET jail. First I created `bridge0` with address 172.16.0.1/24. The VNET jail (172.16.0.2) (its epair) is the only member of the bridge. In `pf.conf`, i have `int_if="bridge0"` and a rule `nat on $ext_if from $int_if:network to any -> ($ext_if:0)`, plus at the bottom `pass in on $int_if`. It nearly works. `host`/`ping`/`nc` cooperate. `fetch`/`pkg` no. Any ideas? 16:22:15 https://paste.debian.net/plain/1350382 16:34:57 so I am wiping some disks and I run smart extended test on one, and then I go to wipe it clean for use and I get constant "Operation not permitted", and when I try to gpart it "Device busy" 16:35:16 this disk is not mounted, it is not in use, yet I cant write to it 16:35:30 securelevel is at -1 16:36:17 any ideas? 16:36:34 I have tried rebooting, same issue 16:37:18 all done as root* 16:42:05 erk: Haven't done any rush before. Tnis is tne consumer: https://github.com/chvostek/shelltools/blob/master/narp 16:42:26 s/sh/st/ 16:43:41 hmmm weird, so I can delete one of the parts on it, but the second is not permitted, and its a ms-basic-data hmmm 16:43:56 I cant dd over the disk, I cant touch it 16:50:19 scoobybejesus: I'd make try it in your home lab, where you can see traffic and get pcaps from multiple perspectives. Not sure what might be missing. Might be worth revisiting https://docs.freebsd.org/en/books/handbook/firewalls/ 16:52:26 mason: Unfortunately, i got it working in my homelab first (fresh install on a tiny atomic pi), and i don't have this SSL issue there. But I do have another homelab box i could try it on 16:54:05 And, yeah, i've been reading through that chapter, and I've been trying to experiment with pf.conf. I'll experiment more. It does seem like the NAT'ing has something to do with it. I was wondering whether I needed to disable TSO on the public interface, or something like that, but it's a bit outside my realm of experience 16:54:16 I appreciate the reply 17:01:27 homelab ifconfig interface options, `options=8209b` versus digitalocean `options=4c07bb`. 17:02:49 what do you see in tcpdump on bridge0 or your ext if when you try to use fetch or pkg? even something like fetch https://google.com doesn't work? 17:12:55 (might as well disable TSO and LRO, though) 17:14:13 polarian: weird, i remember that has happened to me when a VM has opened the device, but that's not the case for you right? 17:14:49 i wonder if something at startup is opening the device 17:15:52 same error for `fetch https://google.com` 17:16:19 what error do you have? Operation timed out? but nc works for a tcp connection? 17:17:32 here's tcpdump during that fetch: https://paste.debian.net/plain/1350399 17:17:55 looks normal 17:18:23 the paste from above shows that it's an SSL error. along the lines of `0020E1224A070000:error:0A000438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:1605:SSL alert number 80` 17:18:35 ah sorry i never saw your messages about any ssl error 17:19:04 i see now 17:20:39 well, then it sounds like an SSL problem. i don't know what to do about that, but "SSL alert number 80" sounds relevant. the only thing that comes to mind, is the ca_root_nss package 17:21:12 hmm, looking up that error it sounds like it's something else 17:23:35 hm.. you gave me an idea... checking... 17:24:58 the host and working jails were returning the time in UTC. this vnet jails was returning in EST. i ran tzsetup to choose UTC. no luck 17:26:56 a stackoverflow post points to part of the TLS RFC that indicates that "alert number 80" is "internal_error" i.e " internal_error: An internal error unrelated to the peer or the 17:27:00 correctness of the protocol (such as a memory allocation failure) 17:27:03 makes it impossible to continue. 17:27:31 so it doesn't sound like it has anything to do with time, and even then, a problem would be time being wrong, not just a different time zone 17:29:03 and the error is in "ssl3_read_bytes"... so maybe somehow it cannot allocate memory for the response data 17:30:00 From top in the jail `Mem: 512M Active, 2452M Inact, 820M Wired, 39K Buf, 133M Free` 17:31:40 maybe try `openssl s_client` with some verbosity and manually perform an HTTP request 17:31:47 i forget the syntax 17:36:07 maybe openssl s_client -security_debug_verbose google.com:443 17:36:16 https://paste.debian.net/plain/1350400 is just -debug 17:38:21 and security_debug_verbose https://paste.debian.net/1350401/ 17:42:26 nothing in those are interesting to me. same error. i disabled tso and lro and no change 17:45:49 not sure what to make of it. clearly something happens pretty near the start when it's trying to read data from the peer. when i do it, it reads quite a bit but on yours it stops after only 7 bytes read 17:47:19 it seems like a number of people on the web have encountered this error though, so that or people in #openssl or similar might know more 17:50:49 jmnbtslsQE: nope... its a base freebsd install just for wiping disks, it wiped the other disk just fine... 17:51:00 nothing should be using it 17:51:22 unless... the first disk I wiped I had plugged into a different sata port 17:51:26 let me try swapping them around again 17:51:37 this will just swap the adax identifiers 17:51:43 but hey ho its worth a shot 17:52:10 s/identifiers/block devices/ 17:52:13 sorry I am half asleep 17:53:57 thanks for digging a bit on this jmnbtslsQE. it would be nice to have a vnet jail or two on my VPS, but this is a roadblock 17:56:42 scoobybejesus: it seems like it's actually being sent by the peer: https://www.rfc-editor.org/rfc/rfc8446#page-85 17:56:56 so, pretty strange, since you're seeing it anywhere you try 17:57:40 that almost makes me wonder if it's some kind of defective MITM attack. but i don't know much about TLS 17:58:27 polarian: OK 17:59:04 scoobybejesus: maybe your openssl version is too old. i see people on the web talking about that 17:59:27 though, i would think that version issues would be handled in the protocol by some other means 17:59:44 OpenSSL 3.0.15 3 Sep 2024 (Library: OpenSSL 3.0.15 3 Sep 2024) 17:59:54 heh, OK 18:01:38 strange that in your tcpdmp though, your client sends data first, then only reads 8 bytes. not consistent with what's in the openssl dump. so, not sure what to make of that, maybe i'm missing something 18:02:16 oh, nevermind it is consistent. nevermind 18:02:46 because in openssl s_client it says it writes first then reads. 18:03:19 well, then it sounds like some kind of openssl-related issue somehow. your client sends some data, and the server responds with a fatal "alert" error, surely #openssl will have something to say about it 18:08:41 and i guess you're not getting the same issue from the host, only from the jail. 18:09:15 well, i'm definitely curious to hear of whatever the resolution is 18:10:08 from a VNET jail at home with the same networking config (its epair is the only member of the bridge, and the bridge's traffic is NAT'd out the external interface) https://paste.debian.net/plain/1350404 18:10:34 yeah that's similar to what i see 18:11:22 yeah, and it's similar on the VPS host. only this VNET jail, NAT'd out, is having this issue (again, all on 14.2-RELEASEp1) 18:12:30 OK 18:13:15 when i can spend some more time on this, i will be asking #openssl. i appreciate your help. if there's a resolution (please please), i'll let you know 18:13:23 OK great 19:04:29 that is so weird... 19:04:34 jmnbtslsQE: works 19:04:49 if the disk is ada0 it doesn't allow me to write, but if it is ada1 it does 19:04:58 weird edge case I found maybe? 19:05:22 maybe freebsd is going based on the install, when I installed the system the disk I installed to was ada0, so when the identifier is moved to ada1 freebsd gets confused? 19:36:27 that's nice, apparently postgres GSSAPI finally got fixed to use MIT Kerberos so you can build it again 19:43:08 polarian: what device are you booting off of? 19:45:44 jmnbtslsQE: ada0 which then became ada1 19:45:46 HDD 19:46:05 because device identifiers are based off the sata slot 19:48:15 that happens 19:48:35 you should use labels and don't write into any ada* 19:49:58 device numbers aren't fixed! 19:51:21 good that it didn't allow you to write to boot disk 19:51:59 but if it's not mounted, you could very easily do it 19:54:03 if all other ids are off, you could still use smart serials and so on to verify what device it is, that's if you can't differenciate it from size maybe 19:56:22 ketas: no... its not the problem 19:56:27 the identifier changed, no biggie 19:56:40 the bootloader simply looks for the boot partition and boots the loader no problem 19:56:43 there are smartctl -x, diskinfo -v, gpart show, glabel status at your disposal 19:56:45 the loader knows where to boot 19:56:46 oh 19:56:57 ada0 was the identifier when I installed with a single HDD 19:57:03 when I installed a second, the identifier switched 19:57:14 ada1 was now the boot, ada0 was the disk I wanted to erase 19:57:19 I couldn't write to ada0 19:57:21 it wouldn't let me 19:57:27 it was the right disk, it wouldn't let me... 19:57:35 why? 19:57:37 dunno 19:57:47 I switched the sata cables over, and as ada1 I coulud write to the HDD 19:57:51 because it had zpool imported? 19:57:54 eh 19:57:55 nope 19:57:57 empty disk 19:58:00 looked like old windows install 19:58:09 you can write to there always 19:58:09 dont really care its a second hand disk I am prepping for install 19:58:30 geli + /dev/zero write over the disk and a extended smart test 19:59:19 I am just curious now *why* I couldn't 19:59:35 i use custom procedures, with ideas from https://www.reddit.com/r/DataHoarder/comments/qtbte3/comment/hkjxx8a/ 19:59:45 I wonder if freebsd assumed ada0 was the boot disk or something 19:59:52 it was not mounted, in use by any process etc 19:59:55 and it was "Busy" 20:00:06 and trying to dd to it you get "Operation not permitted" 20:00:26 then it was wrong disk? 20:00:41 nope 20:00:43 it was the right disk 20:00:44 there are no other safeguards there 20:00:46 thats the thing! 20:00:51 I double checked 52 times 20:00:54 it was the right disk 20:00:59 geom disk list + smartctl -a 20:01:02 it was the right disk 20:01:08 * polarian is not insane 20:01:08 polarian: i missed the start of this conversation, what were you trying to do? 20:01:15 ivy: dd the disk :) 20:01:25 did you delete the partitions and label first? 20:01:37 (gpart destroy) 20:01:42 you can dd into partitioned disk too 20:01:53 if it's not mounted in any way 20:02:30 if it is, there is sysctl kern.geom.debugflags=0x10 for you 20:02:37 that allows it all 20:02:39 also ketas that reddit thread is a lot more indepth, I haven't the patience, if I did I would do a few random overwrites, I am just doing a basic check that the platters are still working (smart extended test will detect if there is something broken) and wiping any existing data, I don't need to but I feel its a good thing to do for the previous owner who left their windows install on the damn 20:02:41 disk unencrypted 20:02:45 ivy: couldn't 20:02:50 "Device busy" 20:02:56 now you could ruin boot disks too 20:03:24 I am still curious why freebsd wouldn't let me write to the correct disk if it was ada0 20:03:47 i'm not aware of any such bug 20:04:05 except if it was a wrongbdevice 20:04:29 s/b/ / 20:09:58 polarian: not sure. maybe swap from your fstab was specified with the identifier, and it happens to be that partition number? 20:10:23 /etc/fstab doesn't exist :) 20:10:39 OK 20:11:23 I did check for that one 20:11:30 ketas: I checked many MANY times 20:11:52 the boot drive is 500GB the wipe one is 1TB 20:12:01 I made 100% sure 20:16:59 unsure then 20:17:23 just brain is more likely cause than cpu 20:17:34 would be fun if it's bug 20:58:23 this wiki seems a bit outdated https://wiki.freebsd.org/arm/Ampere 20:59:40 who can I reach out to for updates? 20:59:52 *to update* 21:00:06 afaik you can just create an account and update it yourself 21:00:27 otherwise, reach out to Mark Linimon 21:33:14 ketas: fine I will try it again with another disk, see what happens :P 21:37:46 jbo: can't make account there 21:38:27 i bet you can have one tho 21:41:35 https://wiki.freebsd.org/Wiki/About 21:43:16 oh, there it was 21:43:24 still manual register 21:43:58 i guess there are too many idiots nowadays 21:45:35 this is not the first page there that's outdated, too 21:47:33 had idea to update but somehow didn't request access eh 21:47:38 contributors are always very welcomed :) 21:49:03 yes 21:49:49 i filed my 10+y old patches as pr's, but now i'm kind of stuck 21:49:56 eh 21:54:03 >10 years old PRs should just be closed tbh 22:12:59 jbo: nonono, i had patches sitting around locally on disk(s) for over a decade, i looked and found noone implemented those in time between, found good feedback for all of them, but then it felt like too much wor 22:13:03 k 22:13:15 even for those small things 22:13:48 one was suggested to add as a new boot flag which seems waaay top much to chew 22:13:52 aye 22:13:58 s/top/too/ 22:14:33 hell knows what else sits around like this 23:00:45 new boot flag to what?