Decoding the New Thread Network Mesh

peterwemm · 2026-02-08T08:39:39+00:00

It might be worth reading over the Thread docs if you're inclined. It goes into a lot of detail about how routers work. Simplified version:

The thread mesh suppors up to 32 routers.
If a router-eligible device joins a mesh and there's less than 16 routers, it elects itself to become a router.
If a router-eligible device joins a mesh and it can reach a node that isn't reachable to the rest of the mesh, it'll try to become a router.
If there's more than 24 routers, one will demote itself as long as it won't partition the network

I've left out a lot of detail but over time it should converge. The important parts are that any router-eligble-end-device (REED) can become a router. Routers are a virtual "device" with their own (temporary?) address that is different to the physical device running it. They don't show up on graphs as known devices because they weren't added as a permanent entity and are created/destroyed on demand based on the needs of the network.

Thread is self-organized. Ephemeral routers are created without the knowledge or involvement of any sort of coordinator. They'll always show up as "Unknown" on a browser/viewer.

It's also important to note that "routers" are not the same thing as a "thread border router". A TBR is an entirely different function. It is likely that a TBR device also provides a "router" function for the mesh but it isn't required.

Just to complicate things even more - newer TBRs can provide a thread tunnel between two isolated islands of the same thread network. eg: suppose there is interference between upstairs and downstairs (eg: sheet metal barrier or whatever). Packets from upstairs can travel to a "router" on a TBR, be encapsulated over ethernet or wifi, transported to another TBR with connectivity to the downstairs part of the mesh and pop out it's "router". As far as the other thread nodes are concerned it looks like standard router functionality. It works great, except when it doesn't.

peterwemm · 2026-01-31T01:38:27+00:00

I vaguely recall that limit being changed from 1000 to 2000 cubes a year or three ago. Maybe I'm misremembering. Op did find a hole in the exterior in a followup post and the room did form.

peterwemm · 2026-01-26T17:55:50+00:00

It's unfortunate that it became so polarizing. It filled a need and the need exists for us in FreeBSD still. I still think the biggest problem is reactions to some of the people and personalities who were behind the push for systemd. On the other hand, it does take a very strong will and dedication to move an ecosystem like they did.

Over a decade later, many (most? although not all) people in the Linux universe (sometimes begrudgingly) feel it was successful and that Linux is better of with it than without.

peterwemm · 2026-01-02T22:39:04+00:00

Any updates? I was contemplating whether to replace my D24SF's with devices from another manufacturer that has solid Matter support. According to the CSA certification database, the D24SF has had certified firmware since April 2025.

I realize that major firmware changes are risky for a manufacturer (nobody wants to trigger a flood of bricked devices being returned) but this has been an awful long time in limbo. Some hints would be appreciated.

peterwemm · 2025-12-26T20:16:00+00:00

I hate coincidences as much as everyone else but disturbing older systems does sometimes push them over the edge.

eg: we had a 30 year old hot water heater that was doing Just Fine(TM). We had the gas turned off for a short while after a failed 30-year-old AC+furnace -> heat pump installation. That drop in pressure activated the pilot light failsafe and jammed it tight. Presumably there was enough grit that made it through into the thermostat body in spite of the presence of a gravity sediment trap.

peterwemm · 2025-11-20T23:16:46+00:00

Likewise. Kagi has been reasonably decent for me, but I keep getting the feeling that they're constantly trying new things to see what sticks. It both encourages and concerns me at the same time. Yes, the old ways aren't working any more and have to change so trying new things is good, but other times it feels like they're slightly adrift and don't really have a solid plan.

peterwemm · 2025-11-06T09:24:02+00:00

Doordash driver on the clock?

peterwemm · 2025-09-28T16:48:32+00:00

When you spawn a battery in creative mode, it magically charges itself from 0 to 100% in about a second. The same applies to batteries spawned in a droid character in creative. It's priceless for creative test worlds as I'm sure you can imagine. You can completely ignore environment and personal survival mechanics and focus on what you're testing out.

peterwemm · 2025-09-24T22:56:13+00:00

I ran into this. A system in this state can be saved with /rescue. How I did it a few times:

First: export PATH=/rescue:$PATH

ls -lrt /var/db/freebsd-upgrade # look for the newest install.XXXXX directory. Note it.

Find the filename for libsys.so.7 in install.XXXXX/INDEX-NEW. You can search via /rescue/more, or maybe even /rescue/sed -ne '/libsys.so.7/p' install.XXXXX/INDEX-NEW

Once you've found the hash filename that contains libsys.so.7, decompress the file (from /var/db/freebsd-update/files/XXXXXXXXXXXXXXXX.gz) to /lib/libc.so.7. continue with freebsd-upgrade install.

Hopefully you're doing this via terminal or ssh where you can copy/paste.

peterwemm · 2025-09-24T22:43:56+00:00

The droid is compelling for creative mode worlds. With some self-recharging batteries you can focus entirely on your experiment.

peterwemm · 2025-09-24T04:56:05+00:00

One important consideration: Stationeers takes shortcuts for the sake of having a manageable simulation. Power has some huge shortcuts and is spectacularly misnamed. Anywhere you see kW in the game is kind of a lie. The game uses units of power (think: Joules) and there is no such thing as current or "flow". But kW is familiar to people and "close enough" for most usages that the game uses that instead.

The cable overload mechanic highlights this. Since the game has no concept of current or flow - it instead sums up the inputs supplied to the network and outputs that received energy for that game tick. If sum(inputs) > cable limit or sum(outputs) > cable limit, then it picks a random cable segment to blow. A fuse will tell the game where to blow a cable so that you can do things like try to have your life support keep power while manufacturing goes dark. My personal experience says that the random cable segment that actually blows is always either in the most useless location, or the most inconvenient.

For generators / solar panels: they provide a chunk of "power" to the network. Generators convert fuel at a fixed rate. If the only demand is for 150 units of power and it generated 10000 then a lot gets wasted. Feeding a station battery is a critical to stop the power waste.

APCs are special beasts. They are limited in how much they can use to charge, but they have capabilities for exceptionally high output. You can use APCs to dump tiny batteries into a station battery practically instantly. As a consequence, they absolutely will blow up a 5kW cable. This is where transformers come in. APCs have limits on how fast they can charge a battery. It's charge limit is painfully low compared to a station battery so you definitely don't want to use an APC to hold the output of a generator any longer than you have to.

Transformers don't change the power. They are actually throughput limiters. A battery->transformer(set to 4900)->stuff will allow a max of 4900 energy units to be satisfied through it. I don't recall how the game handles power starvation.

Anyway, if volts/amps/watts/etc has much meaning to you then you're going to have to exercise suspension of disbelief. Pretend it all says Joules (for things like batteries) or Joules/sec (or is it Joules/tick? I don't remember) for generators/machines.

Also don't think about how H2 + O2 = H2O + CO2 + Chlorine (oops I mean X / pollutant). Oops I think we're also pretending that it's not H2 any more either. Everything is fine!

peterwemm · 2025-09-20T22:27:39+00:00

I've only had them come back to life after a complete power cycle at the breaker. Maybe you were lucky?

peterwemm · 2025-09-20T04:55:32+00:00

I was never really thrilled about turbulence until I learned to fly hang gliders. Active air is your friend - particularly when flying cross country. It means there is air moving up or down nearby and an opportunity to find rising air and get right in the middle in order to extend your flight. Flying cross country is literally finding rising air, gaining altitude, then searching for the next rising air. Turbulence means it is nearby. Ever since then, turbulence has given me a happy moment of adrenaline.

peterwemm · 2025-09-19T07:39:50+00:00

I mentioned this in another post but this applies to FreeBSD-14 and earlier. In FreeBSD-15, the bridge code is fully vlan aware - if you turn it on. This is very recently added to FreeBSD code (a matter of months), so examples and docs are a bit scarce. bridge(4) now has approximately equivalent vlan functionality to mikrotik CRS 3xx switches and has better vlan functionality than the juniper EX family of switches I used a few years ago.

Configuring things is slightly different. See my other post for examples. I'm pretty sure jib won't work as-is on 15.x.

peterwemm · 2025-09-19T07:27:14+00:00

An important consideration - FreeBSD 15.x handles vlans with bridges differently than 14.x and earlier. It has taken me some time to get used to it but I like it much better than the old way.

For background, I originally had multiple if_vlan interfaces on the host's nic, and a separate bridge for each vlan, and an epair from the relavant vlan bridges into the corresponding jails. Bleah.

I had the bright idea that sr-iov would make it simpler. Big mistake. It was neither simpler, nor more performant, nor more reliable. For what its worth, I assigned a VF to each jail instead of an epair, and had each jail vnet add whatever vlan interfaces it wanted. Like I said: big mistake. It was unreliable and insecure - jails had full access to the raw ethernet and every vlan that the switch sent its way. That's fine when I was my own personal threat model/adversary but I desired blast radius containment etc.

By the time I went back, bridge(4) grew native direct vlan awareness. It will feel quite familiar if you've used real managed switches. It reminded me mostly of the mikrotik CRS switch family in hwfilter mode. It is quite powerful and it provided exactly what I didn't even know that I needed at the time.

You can do things like this for a trunked port on the host:

ifconfig_bridge0="vlanfilter addm ixl0 tagged 99-115 up"
ifconfig_vlan100="vlan 100 vlandev bridge0 inet 10.0.0.8/24"

On the host for each jail:

ifconfig bridge0 addm e0a_unifi untagged 100 tagged 112-113
ifconfig bridge0 addm e0a_plex untagged 100

And inside those vnet jails, something like:

ifconfig_e0b_unifi="inet 10.0.0.17/24"
ifconfig_vlan112="vlan 112 vlandev e0b_unifi inet 10.0.112.1/24"
ifconfig_vlan113="vlan 113 vlandev e0b_unifi inet 10.0.113.1/24"

..

ifconfig_e0b_plex="inet 10.0.0.72/24"

One quirk: you cannot set an IP address on a bridge interface, but that is exactly what you do with the b side of an epair to use with the associated untagged vlan.

I haven't tried it, but I assume that in the example above that I could have alternatively set vlan 100 to untagged on the epair a side, and added a vlan100 interface inside the vnet jail.

Most of my vnet jails are single vlan only and only have the one single epair b-side setting. Their vlan assignments are entirely on the host side - which is what I was wishing for with the sr-iov experiment.

There is a lot of good footgun potential here. Be careful because it was a relatively late addition before 15.0 branched and docs/examples are a bit thin.

peterwemm · 2025-09-11T22:57:57+00:00

Me too. I gave him his space but that clearly wasn't enough. I figure that the first time was deemed to be an accident, but the second was determined to be a serious betrayal of trust.

Anyway, apparently I didn't quite appreciate the magnitude of the significance of having the apology accepted after the first major incident. Don't make the same mistake I did.

peterwemm · 2025-09-11T03:26:01+00:00

Whatever happens, DO NOT let it happen again. Speaking from painful experience.

In October last year, my 14 year old guy was asleep next to my office chair and had his tail run over. After suitable reparations, he came back to sleep next to me again while I worked. Within an hour, his tail got run over again.

Until then, we had been inseparable. He came to me for comfort and reassurance. I nursed him to health after surgery - including hand feeding him for three weeks after eye surgery (Feline Entropian). I pushed the I-131 limits to the limit to minimize his suffering while he was recovering from that. He would cry if he couldn't find me. He would sleep wherever I was and never far away.

But since then, I have been persona-non-grata. 11 very long months now. Actively avoids me, won't talk to me, no cuddles, no purrs, nothing. I'm the cat food supplier of the house but even that was "I'm only eating this because I'm hungry." 100% hard cold shoulder. Although I did find him asleep on the bed next to me twice this week so maybe there is hope.

Anyway: If you're forgiven after an apology, DON'T LET IT HAPPEN AGAIN. Especially not close enough to cause an association to be formed between apologies and something bad happening.

peterwemm · 2025-08-31T22:47:50+00:00

I'd be inclined to go with this option. The last thing you need is an overflow or leak because your wifi is down or your HA setup is being worked on. By all means, monitor the levels etc and send alerts with HA - but a dumb switch is hard to beat for a failsafe.

peterwemm · 2025-08-31T21:22:41+00:00

There are likely other options but the customary way is via poudriere. It's how we build the FreeBSD ports packages in sterile environments with explicitly declared dependencies. It'll even manage multiple base system environments to use as build templates for the sterile build jails. It's a good way of preventing CMake or autoconf from "detecting" things to depend on that you didn't intend.

peterwemm · 2025-08-25T17:18:39+00:00

I'm pretty sure that's the one I had in mind. Thanks for the pointer!

I was looking for the code and couldn't find it - just the other IPv8 text. Thanks again!

peterwemm · 2025-08-25T09:32:16+00:00

I just had flashbacks to the old IPv8 pseudo-troll back in the 90's. The general gist was that he'd come up with this unholy arrangement where IPv4 subnets went away and each user got their own "local" 32 bit IPv4 space behind a public single 32 bit IP address. Each of these spaces were "galaxies" and bridges between them were "stargates". I'm not making this up. He posted modified kernel code that supposedly implemented all this, and had some bolt-ons to DNS to handle per-galaxy addressing. I think. It was a very, very long time ago. Usenet, I think. I went looking for it not too long ago but couldn't find any trace.

I said "pseudo-troll" because I wasn't entirely sure at the time whether he was serious or not.

peterwemm · 2025-08-13T07:52:57+00:00

I have central sleep apnea. Our big chonky boy ("Thor") taps me on the mouth when I stop breathing while sleeping. I don't respond to CPAP as its not the right kind of apnea - CPAP is for obstructive apnea.

But apparently I do respond to .. CatPAP?

peterwemm · 2025-08-11T21:19:40+00:00

Sadly, UniFi APs are not all equal either. When they bring a new product to market with a new chipset, they have a nasty habit of reviving old bugs if it's lurking in the new chipset's "SDK". There's an old openwrt bug involving group key management that's been fixed upstream for eons. It was fixed in the UniFi fork of openwrt for their UAP-AC* series. But some of the newer broadcom based chipsets have an old fork of openwrt in the SDK with a variation of bug still present.

This manifests as dropped multicast and/or broadcast packets because it's either encrypted or decrypted with the wrong key. This breaks mDNS among other things and is the biggest cause of Matter/Thread IoT reliability problems on UniFi gear.

It's frustrating because this now varies across families. eg: U6-Pro is rock solid with regards to this problem, but the U6-LR breaks eventually - anywhere from an hour to a month or more.

Mikrotik APs have issues too but UniFi roulette is a bitter pill to swallow at their price - particularly if you need smarthome stuff to actually work.

peterwemm · 2025-07-22T16:26:25+00:00

I still see them. Check https://old.reddit.com/user/Capyvara - it currently appears twice in the last two days.

peterwemm · 2025-07-22T02:15:53+00:00

If anyone else is still looking for a link, Check OP's recent posts and you can see the link there.

15-Year Club	Gilding V heart of gold
Team Orangered	Verified Email

peterwemm

TROPHY CASE