Peter Wemm

Roaming FreeBSD/Linux/Kernel/Networking/Container/Security/CDN/Cloud/k8s/etc troublemaker.
Long time FreeBSD developer.
Ex-Yahoo! Quietly working on FreeBSD at $newjob.

Last Notes

2026-05-10 03:34:10 UTC

Remember the old 2600Hz thing and how much money it cost AT&T? In hindsight, it was so obviously dumb to put control signalling and user-data in the exact same channel. We'd learn from that, right? It's so obviously a terrible idea that can never work safely that we'd never do something that dumb again, right? RIGHT?!
Oh wait. That's pretty much standard operating procedure with AI agents. Just jam it all in the same context, what could possibly go wrong?! Surely it'll be OK this time, right?
*Bangs head on desk*

2026-05-05 04:30:11 UTC

I got a bit of joy after watching people use AI coding agents and trying to shoehorn it into their "Agile" processes. I'm starting to get my hopes up that this is a perfect storm that might actually slay Fake-Agile. Fake-Agile, you ask? Every company that I've seen that implements "Agile" has a wildly different thing that has little in common with what Agile set out to achieve. It's a different beast entirely that seems more optimized to delay and diffuse responsibility than speed up. Fake-Agile is an abomination.
And now, people are absolutely swamping it with AI-generated stuff. I've seen AI-generated tickets, leading to AI-generated user-stories, leading to AI generated code, leading to AI-generated reviews, and of course AI-generated approvals. It seems like there's a 10x increase in volume and I don't think many people actually read it any more. People are even starting to not even bother to pretend.
Maybe the facade can be just torn down? Just(tm) pair-program with an AI stack and be done with BS.
Nah, it'll never happen. Managers like their metrics too much, and developers develop metrics rather than products.

2026-02-22 02:22:52 UTC

- reply

Sure, but those are for people with the right accent etc. Walking around with a "kick me!" sign on is significantly riskier for some.

2026-02-22 00:47:23 UTC

Next challenge: think of better SSID names. I'm probably going to keep "virus.exe" for some things. "FBI Surveillance Van" has an awkward vibe these days.

2026-01-25 21:09:56 UTC

- reply

@nprofile…9atz heh. I was thinking of something less extreme. I was just going to boot from a ramdisk, import the pool, rename a bunch of volumes to a BE style setup and set properties. I do have to use a recursive style setup though and remember to use -r.
My biggest worries are that the mount scripts do things in the right order so volumes don’t overlay sub volumes. I’ve had problems like that on other systems so I’m apprehensive about it.

2025-07-29 17:20:38 UTC

- reply

Eww. Eww. I'm so sorry.

2025-07-27 17:29:38 UTC

I have a strange issue when enabling dhcp option 108 / nat64 / etc on my #ipv6-mostly home network. I don't quite know what to make of it.
I use the apalrd fork of tayga to do NAT64. This is working great. Of note: my nat64 translator is using the well known prefix and is configured to allow access to my internal rfc1918 network. I'm using kea-3.0 for dhcp option 108 support. As a result, no ipv4 addresses are assigned to apple/android devices and they activate their clat to use with my nat64 translator. dns64 is available as well for my #FreeBSD jails etc (which also have no ipv4 but may need to reach github etc). This is all working fine.
EXCEPT.. I have a couple of tp-link tapo C125 cameras in homekit-secure-video mode. Mostly for pet doors etc. They don't seem to like to work in ipv6-only mode even though they did acquire an ipv6 address. These are working fine with apple home and do the motion detection / record video / etc thing. I can browse the recorded video just fine. So far so good..
However, if I try to check *live video* (vs icloud recorded), then the apple gear seems to try to talk to it via ipv4 directly - without having an ipv4 address on that vlan. When looking at a phone that is involved, I see the local clat (on 192.0.0.2) and all the ipv6 addresses. And yet, it seems to be sending direct 192.0.0.2 -> 10.0.0.41 (the camera) packets on the network. Which of course, replies and the replies go to the freebsd router which drops them because they're garbage.
Thoughts:
* I know I'm not supposed to allow a nat64 on the private well-known prefix to reach back into rfc1918 space. That's fine for carrier stuff really dumb for a home network.
* Everything in the apple universe seems perfectly happy with this arrangement and uses clat/nat64 just fine.. EXCEPT live video on those couple of cameras. Is this just apple being weird?
* Kea is giving a dhcp4 reply of: "dns: 10.0.0.1, subnet mask: 255.255.255.0, option 108: 1800 seconds.". This is a bit strange. It's not assigning a pool address, nor a fixed reservation.. so why the subnet mask?
* I am wondering if perhaps the apple stuff has some workaround kludges for the nat64 spec's handing of well-known-prefix vs rfc1918 space? Maybe it is doing something like sniffing mdns or dhcp replies for other devices and using that to infer what the local network is?
* Older versions of Kea don't do dhcp option 108 properly - they tell the client to "turn off the ipv4 stack but also use this ipv4 address". Maybe apple inadvertently rely on this kind of quirk? I'm wondering if homekit secure video might have used the ipv4 address that older kea would have assigned anyway. I'll check that out in a while.
Does anyone recognize this? I'm going to tinker with the stuff I mentioned above. I figure its a long shot but maybe somebody might have an "AHA! that's easy, just do X, Y and Z!"

2025-07-20 18:26:19 UTC

oookay. I backtracked a little and let the sddm greeter run in an x11 session but have it still launch a plasma6 kwin_wayland session on my #FreeBSD desktop.
Surprise: pressing ctrl-C inside a terminal window kills the entire desktop environment. umm. ...
Worse, pressing ctrl-Z inside the window freezes everything.
You know, I think I will go and watch TV for a bit. Murderbot seems about right.

2025-07-20 09:32:20 UTC

This is O_o from chatgpt. It had #FreeBSD specific advice that I didn't find in the handbook, nor with a couple of hours of searches. I didn't tell it that I was using FreeBSD, it came up with this on its own. Its advice was HIGHLY on point.
https://soc.crashed.org/media/1f2a6ead-f340-417c-bb4a-7234da4b3691/image.png

2025-07-18 10:34:22 UTC

I think I'm prepared to tempt Murphy and call my #FreeBSD vnet jail renovation a huge success. It uses the new FreeBSD-15+ vlan-aware bridge system. It is simpler, MUCH faster to start, and so far: reliable + robust. I am really liking the bridge/vlan overhaul.
Background: Long ago, I overdid my home network vlan setup with 16 vlans. The servers have trunked ports. My jail hosts have vnet jails that exist in one or more of several vlans.
Originally, I'd create vlan interfaces and attach to the trunked ethernet port. Then one bridge per vlan. And the jail epairs would be attached to the appropriate bridge. Management was error prone. The structure was jail epairs <-> vlan100bridge <-> host vlan100 -> ethernet. The host vlan100 had the ethernet as a parent and was added as a member to the bridge.
Later on I switched to SR-IOV VFs by giving each vnet jail its own VF. This was fragile to put it mildly. A parallel jail start was practically guaranteed to cause several VFs to brick and require a restart. Slow sequential starts with lots of sleeps mostly avoided this. It still broke occasionally at runtime when the driver and/or firmware would break. I've given up on this.
Now: I'm using the new vlan-aware bridge system. It now has jail epairs <-> bridge0 <-> ethernet. The ethernet is a member of the bridge. The vlan interfaces for the host have the bridge as a parent device, not a member. Tag encapsulation, access control etc is now a first class function of bridge0. There's one single bridge for the switching domain instead of one bridge per vlan.
I like it!

2025-07-18 09:44:25 UTC

Protip: don't give all your #FreeBSD vnet jails the same MAC address.

2025-02-14 17:00:54 UTC

AMD PCI passthrough on #FreeBSD for #bhyve is being a PITA with SR-IOV ethernet VFs. Wondering aloud: has anyone here actually seen this work?
This facility is disabled by default and you have to turn it on during early boot. I have done this. Of note, it has been disabled since it was committed ~7 years ago. This makes me suspicious.
While writing this (Rubber Duck debugging FTW) I just realized that I missed a problem: the host is on a vlan tagged port and the switch will drop untagged packets; and the VF wasn't set up for a vlan. Argh!
However, while I chase that down, it would be really useful to hear that somebody is actually using the AMD amdvi PCI passthrough on FreeBSD. Or has seen it work recently.
I'm in this rabbit hole because my initial setup with bhyve/tap/bridge/etc has trouble with the guests doing ethernet mac shenanigans. The guests are swapping mac addresses between themselves (eg: kube-vip, metallb, etc) and by the time this comes out the other side of the if_bridge, packets have the wrong mac on them.
I could just(tm) switch the host to proxmox, but where would the fun be in that? I'm way too stubborn to go there yet.

2025-02-13 19:53:59 UTC

Dumb question for folks using #bhyve on #FreeBSD - are there any established cloud-init data generators for guests that could be used here?
I'm not talking about the cloud-init in the guest, but rather something to generate server-side templates for bhyve guests to use.
I have something I kludged together for my purposes to inject ssh keys, host names, etc. I'm using openstack config-drive metadata because it's what I was familiar with but it's kind of inconvenient. (For the unfamiliar, its an extra tiny block device containing either a fat or iso9660 fs, with json/yaml/files/etc inside).
I figured I should ask if I'm missing something that has already been done. Thoughts?
Slightly irritating: the openstack config drive MUST have the label "config-2". FreeBSD's makefs and libarchive will not do this. cdrtools mkisofs will allow this slightly-illegal name. I may have done a sed on the makefs-generated file system.

2022-11-25 01:35:14 UTC

Belated #introduction after an instance move.
I've been a #FreeBSD developer since 1995. Within the project I've worked on many things - I'm a troublemaker. I looked after the CVS tree from '95 onwards. I'm mostly to blame for the src/contrib/* construct in FreeBSD. I did a lot of the early (pre-5.0) SMP work. I wrote large chunks of or landed the a.out->ELF move along with /boot/loader and LKM->KLD kernel module system in 3.0. I've helped with the Itanium and Alpha architecture ports. I did the CVS->SVN migration (and yes, I always assumed it was a stopgap and I'm glad the final move to git is complete). I did all of the original AMD64 port in a short period of time - boot loader->kernel->multi-user was about 2-3 weeks, and the rest of the essentials all the way up to X11 and Seamonkey/Firefox over the next few months. It is my fault that time_t was 64 bit from day 1 in FreeBSD/amd64 and why there is no lib64 - I (foolishly) assumed that 32 bit i386 would be entirely gone by now. I built the post-2012 FreeBSD developer cluster and faux-CDN.
I worked for Yahoo for 22 years. I've bred tropical fish. I'm a licensed ham radio operator. I snowboard. I fly Hang Gliders - sometimes even competitively. I'm a sucker for a decent video game like Factorio, Satisfactory etc. These days I'm also owned by a cat so I'm likely to post cat photos.
I have a strong interest in #infosec; and after having spent about five years in the Linux universe at Yahoo I've finally made my way back to #FreeBSD - it's about time.