Thread Claims Interoperability. Your Network Has Three Meshes.

I was debugging a Home Assistant Thread configuration when I ran dns-sd -B _meshcop._udp . and counted the results. Every ecosystem claims Thread. Matter unifies everything, they say. I have three separate Thread networks on the same physical network.

eero-thread-3d8a is eero's mesh, with three border routers. MyHome503847291 is Apple's, backed by a single Apple TV. AMZN-Thread-9e6b is Amazon's, with three Echo devices. None of them share traffic.

The Command Nobody Runs

Thread border routers broadcast their presence over mDNS under _meshcop._udp. Run the browse and you get every border router regardless of ecosystem:

dns-sd -B _meshcop._udp .

Each result is a border router instance name. To see the full TXT record for one of them:

dns-sd -L "eero_thread #3F2A" _meshcop._udp local

That gives you enough detail to reconstruct your full Thread topology:

nn=eero-thread-3d8a    ← network name
xa=3d8ab4c291e7f052   ← thread extended address
id=3d8ab4c291e7f052   ← device ID

The nn= field is the Thread network name. Every border router sharing the same nn= is on the same mesh. Group by nn= and you have your mesh count.

The xa= field — the Thread Extended Address, equivalent to a MAC at the Thread layer — is where instance names come from. eero_thread #3F2A has xa=...c4a93f2a. The suffixes match. Except for the Thread leader: Thread's election protocol assigns RouterID 0 to the winning node, giving it RLOC16 0x0000. That's why my gateway eero at 192.168.1.1 shows up as eero_thread #0000. Instance names change whenever Thread reassigns router IDs after a reboot or re-election. The hostname and IP are the stable identifiers.

None of this is in any smart home app.

Three Meshes, No Bridge

Thread devices on the same mesh route packets over 802.15.4 radio directly — no Wi-Fi, lower latency, fewer failure points. The assumption behind Thread is that your devices share a mesh.

They probably don't. A device on eero's mesh talking to one on Amazon's routes: Thread → eero border router → Wi-Fi → Amazon border router → Thread. Two extra hops, Wi-Fi back in the critical path, which is exactly what Thread was designed to avoid.

This is structural. Apple, Amazon, and eero each provision Thread credentials at setup time. Thread 1.3 has no mechanism for border routers from different vendors to merge meshes — the Connectivity Standards Alliance lists it as a known limitation. "Matter over Thread" performance depends on which mesh the communicating devices happen to share.

For battery-powered Thread devices it's worse. They're end devices — they sleep, wake, send a packet, sleep again. When they wake they contact their parent router on their own mesh. A sensor on Amazon's mesh is unreachable from an eero automation without going through Wi-Fi both ways, with no timing guarantee. Automations chaining across ecosystems will have gaps. The more ecosystems in the mix, the more gaps.

eero Joins Every Device Without Asking

Scanning _matter._tcp and grouping by hostname reveals the fabric picture:

dns-sd -B _matter._tcp .

For each result, resolve the hostname:

dns-sd -L "E0F4C2918B3A-00000000014B0CDA" _matter._tcp local

Then query the AAAA record to get the IPv6 address — Thread devices show a mesh-local fd prefix rather than an IPv4:

dns-sd -q A3E817F294C06B5D.local AAAA IN

Five of my devices each hold three fabrics:

A3E817F294C06B5D.local  FD8C:3A17:B294:0000:2E4F:91C3:7A08:D365
  Amazon Alexa     ← paired by user
  Apple Home       ← paired by user
  eero             ← auto-commissioned by eero

I never added these to eero. Matter commissioning is supposed to be deliberate — the commissioner initiates, the device responds, they exchange cryptographic credentials. eero does this automatically for every Matter device it can reach via mDNS.

The rationale is border router coordination: holding a fabric on every device lets eero steer which Thread mesh a device prefers. The side effect is that eero holds administrative access to every Matter device on your network regardless of which app you used to pair it.

eero also registers itself as a Matter device in the browse — raw MAC address as hostname, link-local IPv6 only, no IPv4, eero-only fabric. It's not a controllable device. It's eero claiming a seat in the fabric to manage border router priority. You'd never see it from the app.

One Echo on the Wrong Mesh

One Echo Studio showed up on a network called eero-thread-b7c1. An eero-named mesh, but the only border router on it was an Amazon Echo.

Amazon Echos create their Thread mesh on first setup and name it AMZN-Thread-XXXX. This one picked up a stale credential instead — probably a leftover from a previous reset — and had been running as an eero-named mesh with Amazon hardware ever since. Thread devices joining it were routing through Amazon's stack under an eero identity. Neither ecosystem handles that gracefully.

The fix is a factory reset. Fresh credentials, correct name, correct mesh. You'd never catch this from the Alexa app — it shows the device as connected and fine. dns-sd shows the nn= field and the OUI on the border router, and the mismatch is immediate.

Why I Commission via eero First

Given all this, the practical question is which ecosystem to use when first pairing a new device. I now default to eero, for three reasons.

First, eero has three border routers. Apple has one. If the Apple TV reboots, every device on its Thread mesh loses its border router. eero's mesh survives losing any single node.

Second, eero joins everything anyway. There's no configuration that prevents eero from auto-commissioning a Matter device onto its fabric. Fighting it is not possible. Accepting it means the question is just whether eero is the first fabric or the third.

Third, all five of my Thread-capable Matter devices carry IPv6 addresses in the FD8C:3A17:B294 range — eero's Thread mesh-local /48 prefix. That prefix is fixed for the life of the Thread network. Whatever fabric Apple or Amazon holds on those devices, eero's mesh is the one routing their packets. Pairing via eero first means the fabric that controls the device matches the mesh that moves its traffic. That alignment is the closest you can get to a clean setup under the current fragmentation.

The apps show which ecosystems have keys to a device. The network shows which mesh is doing the actual work. For most setups, those are different answers. Knowing which one is which changes how you approach commissioning.