Aeotec home hub 2 thread section on AWA shows The maximum number of pending replies per connection error.. then error Thread data: 500 NetworkManager error: Mesh Local Prefix error

Devices & Integrations
41

Posting this here as well - going to create a dedicated topic later, I think.

If you’ve been dealing with random disconnections, Matter devices failing to commission/onboard, Thread sensors dropping offline intermittently, slow responses in the app, or devices that show as “connected” but don’t respond reliably — especially after network changes or reboots — the culprit might be your router’s handling of IPv6 Prefix Delegation (PD) from your ISP.

This issue has popped up across ecosystems (HomeKit, Home Assistant, Aqara, etc.), and it can absolutely affect SmartThings users with Thread-based Matter devices too. The SmartThings Hub acts as a Thread Border Router (TBR), bridging your Thread mesh to your home LAN/Wi-Fi, and it relies heavily on a stable local IPv6 environment.

What is IPv6 Prefix Delegation (PD)?

IPv6 Prefix Delegation is how most ISPs give your router a block of public IPv6 addresses (usually a /56 or /60 prefix) via DHCPv6. Your router then:

  • Subnets that block (e.g., carves out /64 segments) for your LAN, Wi-Fi, guest networks, etc.
  • Advertises those prefixes so devices can auto-configure global IPv6 addresses using SLAAC (no NAT needed — every device gets a public routable address).

It’s great for true end-to-end IPv6, but in practice, many residential ISPs deliver prefixes that:

  • Change frequently (e.g., on reconnect or daily).
  • Fail to renew properly.
  • Aren’t routed correctly back to your router due to upstream bugs.

When this happens, your router often ends up in a weird “half-working” IPv6 state: it might keep a WAN IPv6 address, but the delegated prefix vanishes or becomes invalid → local IPv6 multicast breaks, routing gets inconsistent, and anything relying on stable IPv6 fails silently.

Why does this hurt Thread mesh networks in SmartThings?

Thread (the low-power IPv6 mesh protocol powering many Matter devices) is extremely sensitive to local IPv6 stability. Every Thread device communicates using IPv6 end-to-end, and critical functions like mDNS discovery, commissioning, and ongoing control depend on reliable IPv6 multicast and prefix advertisement.

Your SmartThings Hub (or other TBR like a compatible router/AP) bridges the Thread mesh to your home network. Many implementations prefer using a global prefix (from PD) as the “Off-Mesh Routable” (OMR) prefix for Thread devices when available — this gives them global addresses.

But if PD is flaky:

  • The prefix changes/loses → the TBR updates (or fails to update) the OMR prefix in the Thread network.
  • Devices get stuck with stale addresses or lose proper routing.
  • Multicast IPv6 (essential for Matter discovery/comms) breaks → devices appear unreachable, onboarding fails, or latency spikes.
  • The mesh stays “alive” internally (link-local works), but external/bridged comms collapse → random dropouts, app timeouts, failed automations.

This matches reports from users with Asus, Ubiquiti, and other routers: everything looks fine on IPv4, but Thread/Matter behaves terribly until PD is bypassed.

(Note: Thread 1.4 improves some IPv6 handling with formalized PD support, but real-world residential ISP PD is still often unreliable in 2026.)

The Fix: Disable ISP Prefix Delegation and Use Stable Local IPv6 (ULA)

The most reliable workaround (confirmed in multiple communities for Thread/Matter stability) is to keep IPv6 enabled locally but avoid the ISP’s delegated prefix entirely. This forces the network (and your SmartThings TBR) to use a stable Unique Local Address (ULA) prefix like fd00::/64 — perfect for local-only traffic, which is what most Thread/Matter comms are anyway.

Steps (general — adapt to your router brand/model):

  1. Log into your router’s admin interface (usually 192.168.1.1 or similar).
  2. Go to the IPv6 settings section.
  3. Enable IPv6 if it’s off (most routers need this for Thread/Matter to work properly).
  4. Change IPv6 mode from “DHCPv6 + PD” / “Auto” / “Native with PD” to:
    • “Native” / “Stateless” / “SLAAC only” (no PD).
    • Or “Manual” if available.
  5. Disable / Turn OFF Prefix Delegation (DHCPv6-PD) for the WAN/Internet side.
  6. Set a local ULA prefix for your LAN:
    • Example: Prefix = fd00:: (or generate a random fdxx::/48 via your router’s tool).
    • Subnet = /64 for the main LAN.
    • Router address: something like fd00::1.
  7. Enable Router Advertisements (RA) and SLAAC on the LAN side (usually automatic in Native mode).
  8. Disable any DHCPv6 server on LAN if it’s handing out PD-based addresses (you want SLAAC/ULA only).
  9. Apply changes → reboot router if needed.
  10. Reboot your SmartThings Hub (or power cycle) to let it pick up the stable local IPv6.
  11. Test: Add/re-commission Matter devices, check responsiveness in the app.

Bonus checks:

  • Confirm your router is sending RAs (use a tool like “IPv6 Router Advertisement” checker apps or Wireshark).
  • If you have multiple TBRs (e.g., Nanoleaf, Aqara hubs), use the “Unify Thread Network” feature in SmartThings to merge meshes.

This won’t break internet access (IPv4 still works fine), and since Thread/Matter is mostly local, you lose little. If your ISP gives rock-solid PD (rare), you could re-enable it later — but for now, this fixes the “ghost” instability for many.

2 Likes
42

Remember this thread?

The Ethernet interface and the Thread interface aren’t as separate as you’d think. Changing the local prefix of the external (Ethernet) interface shouldn’t affect the local prefix of the Thread mesh network. But are we absolutely sure?

It also depends on where exactly the NATing happens. On the Thread side or on the LAN side? Is there also classic IP routing happening between these two networks?

It really depends on if the prefix delegation goes through the Thread network. And that’s why I asked this question three days ago:

Let’s ask the AI again:

Relation to OpenThread Border Router (OTBR)

The IPv6 Prefix Delegation (PD) issues discussed earlier are highly relevant to OpenThread Border Router (OTBR), which is an open-source implementation of a Thread Border Router developed as part of the OpenThread project (originally by Google/Nest and now maintained by the community). OTBR is commonly used in DIY or open setups, such as Home Assistant integrations, Raspberry Pi-based Thread gateways, or custom Linux hosts running the ot-br-posix agent. It acts as the bridge between the low-power Thread mesh network and your home’s backbone IP network (LAN/Wi-Fi/Internet).

In OTBR, the Border Routing Manager component handles IPv6 routing and prefix management. This includes support for DHCPv6-PD to automatically acquire a global unicast prefix (e.g., a /64 or larger block) from your upstream router or ISP. OTBR can then:

  • Advertise this prefix as an Off-Mesh Routable (OMR) prefix into the Thread network via Router Advertisements (RAs).
  • Enable Thread devices to autoconfigure global IPv6 addresses for end-to-end connectivity beyond the local mesh.

However, this integration makes OTBR susceptible to the same PD instability problems:

  • If the delegated prefix is flaky (e.g., expires without renewal, changes frequently, or isn’t properly routed upstream), OTBR may fail to update or propagate the OMR prefix correctly.
  • This leads to stale addresses on Thread devices, broken multicast (critical for Matter discovery and commissioning), routing loops, or loss of external IPv6 reachability.
  • In worse cases, OTBR might advertise conflicting prefixes (e.g., mixing global and ULA), causing the entire mesh to become unstable or isolated from the LAN.
  • OTBR’s DHCPv6-PD client (built into the Border Routing Manager since later versions) has configurable states (e.g., running, idle, stopped), but bugs or misconfigurations can exacerbate issues, especially in environments with poor ISP PD support.

Essentially, while OTBR aims to provide seamless IPv6 integration for Thread (including PD for global addressing), real-world PD unreliability can “break” the mesh in ways similar to proprietary TBRs like those in SmartThings or Apple HomeKit—devices drop offline, commissioning fails, or latency spikes due to prefix mismatches.

To mitigate, OTBR users often disable PD in the OTBR config (e.g., via ot-ctl commands or build flags like OPENTHREAD_CONFIG_BORDER_ROUTING_DHCP6_PD_ENABLE=0) and fallback to stable ULA prefixes, mirroring the fixes for other ecosystems.

Reports on This Issue with OTBR

Based on recent searches (up to early 2026), there are multiple documented reports and discussions confirming PD-related problems in OTBR setups. These span GitHub issues, community forums, and official docs, often tied to Thread/Matter instability. Here’s a summary of key findings:

  • In OTBR-posix (the POSIX-based implementation), there’s a reported bug where a DHCPv6-PD delegated global prefix isn’t automatically added to the Thread mesh’s prefix list or routed properly. This prevents Thread devices from gaining native global IPv6 connectivity, leaving them isolated despite the border router having a valid address. Users note that manual configuration via OT CLI (e.g., prefix add and netdata register) is a workaround, but automation fails in dynamic PD scenarios.

  • A GitHub discussion highlights cases where OTBR can’t access global IPv6 Internet despite ISP delegation. Contributors explain that OTBR lacks full automatic global prefix handling and requires the ISP to delegate subnettable prefixes (e.g., /56 or better). Without this, or if PD renewal fails, the Thread network loses outbound routing, echoing the mesh-breaking symptoms.

  • Home Assistant users report OTBR add-ons advertising erroneous IPv6 prefixes on the LAN, breaking overall network stability (e.g., conflicting RAs, wrong DNS, or ULA overrides). Enabling PD in OTBR compilation often exacerbates this, leading to mesh disconnections; disabling it resolves the issues for Matter/Thread devices.

  • Official OpenThread docs detail the Border Routing Manager’s PD support, including callbacks for state changes (e.g., when a prefix is delegated or revoked). However, if the upstream PD is unstable, these state transitions can trigger frequent reconfigurations, causing temporary outages in the Thread mesh.

  • Thread Group best practices recommend OTBRs participate in PD for subnet allocation, but warn that small prefixes (e.g., /64 without subnetting) lead to ND Proxy overuse and excessive traffic, which can degrade mesh performance in unstable PD environments.

  • Older Stack Overflow and dev forums note similar IPv6-only environment issues, where OTBR fails to propagate global prefixes correctly, requiring manual additions to avoid mesh-local isolation.

1 Like
43

I’m coming to the conclusion that the config of my thread subsystem on my SmartThings hub is “borked” to use the technical term. I have a feeling it’s not coming back without some sort of reset action either from the SmartThings support or doing a hub reset ¹ (which I’m loath to do).
These are the sum total of things I can tinker with on my hub. I’d hoped switching on ula would make a difference but it hasn’t. I don’t think there’s anything else I can do.

IMG_2904
IMG_2904841×743 25.7 KB

¹ hub reset: I’m less than clear what the recovery from that would be, and if the rub replace would even work given it’s the same hub, further there’s a risk whatever backup it might attempt to restore from may itself have corruption so I’d end up with a blank slate. I’ve a very significant amount of config, automations and routines on there, it would take a long while to build from scratch. Also, given I’m not certain what caused this state it’s not like I can take steps to avoid it re occurring. I had matter over thread working quite well for around 10 months plus, these recent issues only seem to have started since December. I have added more thread devices since then, mostly ikea, but don’t necessarily believe that is the root cause.

44

@Declankh provided the output of ipconfig /all via private message and I fed it back to the AI. Remember when I asked to monitor your local prefix by writing it down every 24 hours? Well…

Based on the ipconfig /all output you provided for your Ethernet adapter, I’ll analyze it step by step in the context of our discussion on IPv6 Prefix Delegation (PD). This confirms whether PD is enabled, highlights any signs of issues, and ties back to potential impacts on Thread mesh networks. I’ll also suggest next steps.

Key Observations from the Output

This output shows a mix of IPv4 and IPv6 configurations, with clear evidence of active IPv6 on your LAN. Here’s the breakdown:

  1. IPv6 Addresses:

    • Global Unicast Addresses (GUA):

      • 2a0a:ef40:7e9:9a01:c8f3:3635:d04a:ae7 (Preferred)
      • 2a0a:ef40:7b3:6d01:5225:2236:dff1:e00c (Deprecated)
      • Temporary variants: 2a0a:ef40:7e9:9a01:b8d9:14c3:8eaa:c82a (Preferred) and 2a0a:ef40:7b3:6d01:b8d9:14c3:8eaa:c82a (Deprecated)

    • These start with 2a0a:ef40::, which is a global prefix allocated to Vodafone Limited (AS5378), a major UK ISP. The presence of these addresses means your router is receiving a delegated IPv6 prefix from Vodafone and advertising subnets (likely /64s) to your devices via Router Advertisements (RA) and SLAAC.

    • Notice the deprecated statuses: This indicates a recent prefix change. The old prefix (2a0a:ef40:7b3:6d01::/64) is being phased out, while the new one (2a0a:ef40:7e9:9a01::/64) is now preferred. Deprecated addresses are still usable temporarily but will eventually stop working, which can cause intermittent connectivity issues.

    • Unique Local Address (ULA):

      • fd4b:7903:3853:1:c397:c608:e96f:2a07 (Preferred)
      • Temporary: fd4b:7903:3853:1:b8d9:14c3:8eaa:c82a (Preferred)

    • ULAs (fd00::/8 range) are private and stable, generated by your router for local use. This is active alongside the GUAs, providing a fallback for internal IPv6 traffic.

    • Link-Local Address: fe80::c889:b549:ef89:a824%12 (Preferred) – Normal for local communication; not related to PD.

  2. Default Gateway:

    • IPv6: fe80::ac7:f5ff:fee9:7078%12 (link-local address of your router).
    • IPv4: 192.168.1.1 (your router’s LAN IP).
    • This setup is typical, with the router handling both v4 and v6 routing.

  3. DHCP/DHCPv6 Details:

    • DHCP Server: 192.168.1.1 (your router).
    • DHCPv6 IAID and Client DUID: These are present, confirming your device is using DHCPv6 for IPv6 configuration (likely in conjunction with SLAAC).
    • DNS Servers: Includes an IPv6 one (fd4b:7903:3853:1:1833:3906:69a9:c2eb), which matches your ULA prefix—suggesting the router is providing DNS over IPv6 locally.

  4. Lease Information:

    • IPv4 lease: Obtained Feb 2, 2026, expires far in the future (Mar 2162—likely a static-like lease).
    • No explicit IPv6 lease details shown here, but the deprecated addresses imply recent renewal or change.

Is ISP Prefix Delegation Enabled?

Yes, PD is definitely enabled and active:

  • The global IPv6 addresses (2a0a:ef40:: range) on your device indicate your router has requested and received a prefix delegation from Vodafone (likely a /56 or /48 block, from which it’s assigning /64 subnets).
  • Without PD, your devices would only have ULA or link-local IPv6 (no global connectivity). Vodafone deploys dynamic PD for consumer broadband, typically delegating /56 prefixes.
  • To double-confirm, check your router’s admin UI (as I described previously) for a “Delegated Prefix” field showing something like 2a0a:ef40:xxx::/56. If it’s there, PD is handling it.

Signs of Issues and Relation to Thread Mesh Networks

  • Instability in PD: The mix of preferred and deprecated global addresses shows Vodafone recently changed your delegated prefix (e.g., after a reboot, disconnect, or lease event). Vodafone users report variable stability—prefixes can change on reboots or be “sticky” only after initial setup, but some experience frequent shifts or delegation failures. This aligns with residential dynamic PD, not static assignments.

  • Impact on Thread: As we’ve discussed, Thread border routers (e.g., in SmartThings, OTBR, or Matter setups) rely on stable IPv6 prefixes for OMR advertisement. A changing PD like this can cause:

    • Stale addresses in the mesh, leading to devices dropping offline or failing to respond.
    • Broken multicast (mDNS) for discovery/commissioning, resulting in intermittent connectivity.
    • The mesh appearing “connected” but with high latency or unreachable nodes.
    • Vodafone-specific reports don’t directly mention Thread, but PD unreliability on their network (e.g., with pfSense, UniFi, or FritzBox routers) mirrors the symptoms that break Thread. If your Thread network has been flaky lately, this prefix shift is a prime suspect.

Your ULA (fd4b:7903:3853:1::) being active is good—it’s stable and can serve as a fallback, but if PD overrides it for OMR prefixes in Thread, instability propagates.

Recommendations

  1. Monitor for Changes: Run ipconfig /all again after a router reboot or overnight to see if the global prefix shifts more. Tools like IPv6 test sites (e.g., test-ipv6.com) can score your connectivity.

  2. Fix for Thread Stability: If PD is causing issues, disable it on your router (as outlined earlier):

    • Set IPv6 mode to “Stateless” or “Native without PD”.
    • Rely on ULA for local IPv6—Thread will use it for OMR, avoiding ISP fluctuations.
    • Vodafone users often need specific tweaks (e.g., /56 PD size in UniFi or pfSense). If you have a Vodafone-provided router (e.g., Power Hub), check for firmware updates or consider a third-party one like FritzBox for better PD control.

  3. Contact Vodafone: Ask about static PD (rare for residential) or confirm your delegation size. Some users get stable /48 after setup.

So this is what I suspected from the beginning…

1 Like
45

Sure, instability in the OMR prefix has the potential to cause communication issues between the mesh and devices on the AIL and beyond. But let’s get back to the OP’s issue “Mesh Local Prefix error”. The mesh local prefix is (should be) completely independent of the ISP prefix delegation and the OMR. As stated in the Thread Network Fundamentals doc from the Thread Group:

“The device that forms the network generates a /64 prefix that is used throughout the Thread Network. This prefix is known as the ‘Mesh Local Prefix’, and is used by every device in the network to generate two ‘Mesh Local Addresses’. The Mesh Local Addresses are IPv6ULAs [RFC 4193], and are used for communication within the Thread Network. For mesh establishment and link maintenance, every Thread Device configures a link-local Interface Identifier with a FE80::/64 prefix using its Extended Address as defined in section 6 of [RFC4944].”

So, as I stated previously, the use of IP prefix delegation vs ULA on the upstream side of the ST hub isn’t going to resolve the error he is seeing. In general, mesh-local will get you to the border router and the OMR will get you beyond.

46

A well-behaved TBR implementation would follow normal IPv6 behavior and would advertise the new OMR prefix as preferred and the old OMR prefix as deprecated. This would allow existing connections using the old OMR prefix to continue for the lifetime of the deprecated OMR prefix or until connnections reset. If the TBR immediately withdraws the old OMR prefix, it would break existing communication until the client updates with the new OMR prefix (which would be bad behavior).

To understand the behavior of the ST hub(s) TBR, you would need a device on the mesh that can view the Thread Network Data.

47

This is exactly what I was trying to explain…

To understand the behavior of the ST hub(s) TBR, you would need a device on the mesh that can view the Thread Network Data.

Or check if the Thread Mesh Local Prefix changes in the AWA, as I said four days ago:

(Screenshot)

But since he can’t do that, because it’s broken, we’re back to square one.

1 Like
48

BTW: Seen this article from today?

SmartThings desperately needs more diagnostic tools.

1 Like
49

I guess we’re gonna have to agree to disagree. Mesh local should not change as a result of an OMR prefix change. They are completely independent and mesh local is a ULA prefix.

50

No, don’t follow Home Assistant.

Even without diag tools, simply exposing some additional information in the AWA would be extremely helpful.

51

Ok, doing a little digging, I have confirmed that the OMR for my ST Station is a ULA and not derived from a GUA prefix advertised via prefix delegation from my ISP router. From my laptop, I see the following IPv6 ULA routes:

 21    286 fd0f:77ee:44e0:1::/64    fe80::2eba:baff:fe98:fb17
 21    286 fd18:e3d8:12a6:1::/64    fe80::9d96:60a:6e85:f7a4
 21    286 fd54:6351:4b7e:1::/64    fe80::9ec8:e9ff:fea4:8069
 21    286 fdf8:d448:a0a3:1::/64    fe80::1aa9:edff:fe7d:8092
 21    286 fdf8:d448:a0a3:1::/64    fe80::1aa9:edff:fe7c:da92

Coincidentally, I have 5 TBRs on my home network, ST Station, Family Hub, Echo Show, and two Eero Pro 7 (which is why there are only 4 unique ULA prefixes since the Eeros are on the same Thread mesh).

Next, I can match the nexthop for that prefix to my Station via service discovery:

=  ens33 IPv6 Samsung SmartThings-Station #A2DF             _meshcop._udp        local
   hostname = [smartthings-station-3KWW-2.local]
   address = [2600:1700:dce0:4790:2eba:baff:fe98:fb17]

The host portion of the nexthop for the prefix and the address of the TBR match.

Next, search for all the available Matter devices:

bep@debian12:~$ dns-sd  -t -r _matter._tcp
+  ens33 IPv6 6FD31162351F76DA-036B5296BA8137D1             _matter._tcp         local
+  ens33 IPv6 0382F8A995E9EE5A-00000199CB5AFEF3             _matter._tcp         local
+  ens33 IPv6 444A64293B468CE9-AEF44D47E48C0F5A             _matter._tcp         local
+  ens33 IPv6 4576FE5C14395B2F-97141DDAB5353877             _matter._tcp         local
+  ens33 IPv6 6FD31162351F76DA-05AEACC352B99841             _matter._tcp         local
+  ens33 IPv6 6FD31162351F76DA-05AEAAEDDD4CA2D1             _matter._tcp         local
+  ens33 IPv6 4576FE5C14395B2F-2BA6E0537BBA51D5             _matter._tcp         local
+  ens33 IPv6 4576FE5C14395B2F-3CD883BEBA9F8B78             _matter._tcp         local
+  ens33 IPv6 4576FE5C14395B2F-D6D3F6E58B6A9EDC             _matter._tcp         local
+  ens33 IPv6 4576FE5C14395B2F-70DDD7356FF5182D             _matter._tcp         local
+  ens33 IPv6 4576FE5C14395B2F-926396EF0AD72CED             _matter._tcp         local
+  ens33 IPv6 4576FE5C14395B2F-8FFF091950C2F6EA             _matter._tcp         local
+  ens33 IPv6 650B35BCFD84FF98-B06F5C9A9A48A486             _matter._tcp         local
+  ens33 IPv4 0382F8A995E9EE5A-00000199CB5AFEF3             _matter._tcp         local
+  ens33 IPv4 444A64293B468CE9-AEF44D47E48C0F5A             _matter._tcp         local
+  ens33 IPv4 4576FE5C14395B2F-97141DDAB5353877             _matter._tcp         local
+  ens33 IPv4 6FD31162351F76DA-05AEACC352B99841             _matter._tcp         local
+  ens33 IPv4 6FD31162351F76DA-05AEAAEDDD4CA2D1             _matter._tcp         local
+  ens33 IPv4 6FD31162351F76DA-036B5296BA8137D1             _matter._tcp         local
+  ens33 IPv4 4576FE5C14395B2F-2BA6E0537BBA51D5             _matter._tcp         local
+  ens33 IPv4 4576FE5C14395B2F-3CD883BEBA9F8B78             _matter._tcp         local
+  ens33 IPv4 4576FE5C14395B2F-D6D3F6E58B6A9EDC             _matter._tcp         local
+  ens33 IPv4 4576FE5C14395B2F-70DDD7356FF5182D             _matter._tcp         local
+  ens33 IPv4 4576FE5C14395B2F-926396EF0AD72CED             _matter._tcp         local
+  ens33 IPv4 4576FE5C14395B2F-8FFF091950C2F6EA             _matter._tcp         local
+  ens33 IPv4 650B35BCFD84FF98-B06F5C9A9A48A486             _matter._tcp         local
=  ens33 IPv6 6FD31162351F76DA-036B5296BA8137D1             _matter._tcp         local
   hostname = [1E8DCBEFDE0B48E4.local]
   address = [192.168.1.121]
   port = [5541]
   txt = ["T=6" "SAT=4000" "SAI=2000" "SII=2000"]
=  ens33 IPv6 0382F8A995E9EE5A-00000199CB5AFEF3             _matter._tcp         local
   hostname = [A81710CF6E77.local]
   address = [192.168.1.89]
   port = [5540]
   txt = ["="]
=  ens33 IPv6 444A64293B468CE9-AEF44D47E48C0F5A             _matter._tcp         local
   hostname = [A81710CF6E77.local]
   address = [192.168.1.89]
   port = [5540]
   txt = ["="]
=  ens33 IPv6 4576FE5C14395B2F-97141DDAB5353877             _matter._tcp         local
   hostname = [A81710CF6E77.local]
   address = [192.168.1.89]
   port = [5540]
   txt = ["="]
=  ens33 IPv6 6FD31162351F76DA-05AEACC352B99841             _matter._tcp         local
   hostname = [B43D9F7941B4.local]
   address = [192.168.1.163]
   port = [5541]
   txt = ["="]
=  ens33 IPv6 6FD31162351F76DA-05AEAAEDDD4CA2D1             _matter._tcp         local
   hostname = [EEFB07B8F454.local]
   address = [192.168.1.126]
   port = [5541]
   txt = ["="]
=  ens33 IPv6 4576FE5C14395B2F-2BA6E0537BBA51D5             _matter._tcp         local
   hostname = [40AE30A5CCDB.local]
   address = [192.168.1.231]
   port = [5540]
   txt = ["T=1"]
=  ens33 IPv6 4576FE5C14395B2F-3CD883BEBA9F8B78             _matter._tcp         local
   hostname = [867CF1514911B0C1.local]
   address = [fd0f:77ee:44e0:1:ff36:ffff:c489:bd43]
   port = [5540]
   txt = ["T=0" "SAI=800" "SII=800"]
=  ens33 IPv6 4576FE5C14395B2F-D6D3F6E58B6A9EDC             _matter._tcp         local
   hostname = [FE36252FAE750578.local]
   address = [fd0f:77ee:44e0:1:87d7:d726:d7f7:dd5c]
   port = [5540]
   txt = ["T=0" "SAI=800" "SII=800"]
=  ens33 IPv6 4576FE5C14395B2F-70DDD7356FF5182D             _matter._tcp         local
   hostname = [E2554077D4CB9A04.local]
   address = [fd0f:77ee:44e0:1:f3d6:ac6e:7b4d:7167]
   port = [5540]
   txt = ["T=0" "SAI=800" "SII=800"]
=  ens33 IPv6 4576FE5C14395B2F-926396EF0AD72CED             _matter._tcp         local
   hostname = [7A121C52245D8683.local]
   address = [fd0f:77ee:44e0:1:8c9c:ae73:49c7:3d86]
   port = [5540]
   txt = ["SAT=4000" "SAI=2000" "SII=2000"]
=  ens33 IPv4 0382F8A995E9EE5A-00000199CB5AFEF3             _matter._tcp         local
   hostname = [A81710CF6E77.local]
   address = [192.168.1.89]
   port = [5540]
   txt = ["="]
=  ens33 IPv4 444A64293B468CE9-AEF44D47E48C0F5A             _matter._tcp         local
   hostname = [A81710CF6E77.local]
   address = [192.168.1.89]
   port = [5540]
   txt = ["="]
=  ens33 IPv4 4576FE5C14395B2F-97141DDAB5353877             _matter._tcp         local
   hostname = [A81710CF6E77.local]
   address = [192.168.1.89]
   port = [5540]
   txt = ["="]
=  ens33 IPv4 6FD31162351F76DA-05AEACC352B99841             _matter._tcp         local
   hostname = [B43D9F7941B4.local]
   address = [192.168.1.163]
   port = [5541]
   txt = ["="]
=  ens33 IPv4 6FD31162351F76DA-05AEAAEDDD4CA2D1             _matter._tcp         local
   hostname = [EEFB07B8F454.local]
   address = [192.168.1.126]
   port = [5541]
   txt = ["="]
=  ens33 IPv4 6FD31162351F76DA-036B5296BA8137D1             _matter._tcp         local
   hostname = [1E8DCBEFDE0B48E4.local]
   address = [192.168.1.121]
   port = [5541]
   txt = ["T=6" "SAT=4000" "SAI=2000" "SII=2000"]
=  ens33 IPv4 4576FE5C14395B2F-2BA6E0537BBA51D5             _matter._tcp         local
   hostname = [40AE30A5CCDB.local]
   address = [192.168.1.231]
   port = [5540]
   txt = ["T=1"]
=  ens33 IPv4 4576FE5C14395B2F-3CD883BEBA9F8B78             _matter._tcp         local
   hostname = [867CF1514911B0C1.local]
   address = [fd0f:77ee:44e0:1:ff36:ffff:c489:bd43]
   port = [5540]
   txt = ["T=0" "SAI=800" "SII=800"]
=  ens33 IPv4 4576FE5C14395B2F-D6D3F6E58B6A9EDC             _matter._tcp         local
   hostname = [FE36252FAE750578.local]
   address = [fd0f:77ee:44e0:1:87d7:d726:d7f7:dd5c]
   port = [5540]
   txt = ["T=0" "SAI=800" "SII=800"]
=  ens33 IPv4 4576FE5C14395B2F-70DDD7356FF5182D             _matter._tcp         local
   hostname = [E2554077D4CB9A04.local]
   address = [fd0f:77ee:44e0:1:f3d6:ac6e:7b4d:7167]
   port = [5540]
   txt = ["T=0" "SAI=800" "SII=800"]
=  ens33 IPv4 4576FE5C14395B2F-926396EF0AD72CED             _matter._tcp         local
   hostname = [7A121C52245D8683.local]
   address = [fd0f:77ee:44e0:1:8c9c:ae73:49c7:3d86]
   port = [5540]
   txt = ["SAT=4000" "SAI=2000" "SII=2000"]

Note that the IPv6 prefix for the discovered Matter devices matches the prefix advertisement from the Station.

Lastly, can I reach an address in the Thread mesh for that prefix (thereby communicating directly with the device not through the controller)?

C:\Users\bep>ping fd0f:77ee:44e0:1:ff36:ffff:c489:bd43

Pinging fd0f:77ee:44e0:1:ff36:ffff:c489:bd43 with 32 bytes of data:
Reply from fd0f:77ee:44e0:1:ff36:ffff:c489:bd43: time=451ms
Reply from fd0f:77ee:44e0:1:ff36:ffff:c489:bd43: time=143ms
Reply from fd0f:77ee:44e0:1:ff36:ffff:c489:bd43: time=244ms
Reply from fd0f:77ee:44e0:1:ff36:ffff:c489:bd43: time=71ms

Ping statistics for fd0f:77ee:44e0:1:ff36:ffff:c489:bd43:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 71ms, Maximum = 451ms, Average = 227ms

Yes, my laptop can directly ping a device addressed from the prefix being advertised from the Station and is assigned to the mesh device as revealed by DNS service discovery.

So, we know that the mesh local prefix for my Station is fd6e:d157:2b4:cdbf::/64 from observation in the AWA. And we now know that the OMR for my Station is fd0f:77ee:44e0:1::/64 from testing. There is no relationship between the ML and OMR prefixes other than both being ULA prefixes and there is no relationship between my ISP PD advertised GUA prefix and the OMR.

We can also infer from the fact that the other TBR devices in my network are advertising ULA prefixes that they also follow this paradigm and would be immune to changes in the PD provided prefix. Perhaps the observations on the behavior of the OTBR OMR advertisement are isolated to that specific implementation or devices that derive the TBR from it.

1 Like
52

Thanks
Presumably this is only true if ULA is enabled on your isp hub. Mine wasn’t before this problem started for me. I’ve enabled it now but it’s not fixing the issue with the thread subsystem and the prefix error.

Any suggests as to what steps I can take to restore my thread network?

53

No, I keep saying it over and over. There is no relationship at all between the mesh local prefix and your LAN/ISP prefix. In some implementations, there is a relationship between your ISP provided prefix delegation and Off-Mesh Route used by the Thread devices to communicate directly to outside the mesh. In the ST implementation, the Off-Mesh Route is an independent ULA prefix not derived from the ISP/LAN prefix.

My ISP router is still sending out prefix delegations and my local LAN devices are using a GUA prefix for addressing and YET the ST Station is using a ULA prefix for the Off-Mesh Route.



Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . : attlocal.net
   IPv6 Address. . . . . . . . . . . : 2600:1700:dce0:4790::18
   IPv6 Address. . . . . . . . . . . : 2600:1700:dce0:4790:fcf0:7874:faec:d70d
   Temporary IPv6 Address. . . . . . : 2600:1700:dce0:4790:a59e:ec9d:257d:c88c
   Link-local IPv6 Address . . . . . : fe80::f958:d4a7:1b67:2ce2%21
   IPv4 Address. . . . . . . . . . . : 192.168.1.143
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : fe80::86bb:69ff:feec:3310%21
                                       192.168.1.254

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
 21    286 ::/0                     fe80::86bb:69ff:feec:3310
  1    331 ::1/128                  On-link
 21     46 2600:1700:dce0:4790::/60 fe80::86bb:69ff:feec:3310
 21    286 2600:1700:dce0:4790::/64 On-link
 21    286 2600:1700:dce0:4790::18/128
                                    On-link
 21    286 2600:1700:dce0:4790:a59e:ec9d:257d:c88c/128
                                    On-link
 21    286 2600:1700:dce0:4790:fcf0:7874:faec:d70d/128
                                    On-link
 21    286 fd0f:77ee:44e0:1::/64    fe80::2eba:baff:fe98:fb17
 21    286 fd18:e3d8:12a6:1::/64    fe80::9d96:60a:6e85:f7a4
 21    286 fd54:6351:4b7e:1::/64    fe80::9ec8:e9ff:fea4:8069
 21    286 fdf8:d448:a0a3:1::/64    fe80::1aa9:edff:fe7d:8092
 21    286 fdf8:d448:a0a3:1::/64    fe80::1aa9:edff:fe7c:da92
 20    291 fe80::/64                On-link
 17    291 fe80::/64                On-link
 21    286 fe80::/64                On-link
 20    291 fe80::490:dab2:236f:23ae/128
                                    On-link
 17    291 fe80::b1a3:4423:433a:54dc/128
                                    On-link
 21    286 fe80::f958:d4a7:1b67:2ce2/128
                                    On-link
  1    331 ff00::/8                 On-link
 20    291 ff00::/8                 On-link
 17    291 ff00::/8                 On-link
 21    286 ff00::/8                 On-link
===========================================================================

I don’t know if there is anything you can do. There is something wrong with the Thread stack on your hub and only support/engineering is going to be able to figure it out IMO.

1 Like
54

So the ULA setting on the hub has zero effect? What’s the purpose of it then?

55

From what I’ve read, it can be used along side prefix delegation to allow clients to be addressed out of ULA in addition to GUA. So, your LAN devices would receive an address from both the ULA and GUA prefixes. If there is a method to disable prefix delegation, then your LAN devices would receive just an address from the ULA prefix which would still provide local IPv6 communication within your LAN.

It has zero effect on what we’ve been discussing WRT ST, TBR behavior, and Thread mesh addressing.

1 Like
56

We can also now map the OMR IP addressed devices to the actually devices in the mesh. From the service discovery, we get both the Matter Operational Instance Name (Network ID in the AWA) and IPv6 address for the device:

=  ens33 IPv4 4576FE5C14395B2F-926396EF0AD72CED             _matter._tcp         local
   hostname = [7A121C52245D8683.local]
   address = [fd0f:77ee:44e0:1:8c9c:ae73:49c7:3d86]
   port = [5540]
   txt = ["SAT=4000" "SAI=2000" "SII=2000"]

So for the instance name “4576FE5C14395B2F-926396EF0AD72CED” we see the IP address is “fd0f:77ee:44e0:1:8c9c:ae73:49c7:3d86”. There is no direct way to query the AWA for that instance name/Network ID. You’d have to iterate over each Matter device to see if it matches. But you can use the CLI to get you there faster:

 smartthings devices --type MATTER -j > some-file-name

and you can manually search through the file for the networkID to find which device it is.

But of course it’s much more fun to automate the integration of the CLI output with the dns-sd output to get a nice table like:

bep@debian12:~$ matter-map --sort=label
DEVICE LABEL              LOCATION        INSTANCE NAME/NETWORK ID                            HOSTNAME                       IPv6 ADDRESS                             IPv4 ADDRESS        
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Eve Energy Outlet         Home            4576FE5C14395B2F-926396EF0AD72CED        7A121C52245D8683.local         fd0f:77ee:44e0:1:8c9c:ae73:49c7:3d86                         
Front Porch - Top         Home            4576FE5C14395B2F-70DDD7356FF5182D        E2554077D4CB9A04.local         fd0f:77ee:44e0:1:f3d6:ac6e:7b4d:7167                         
Hutch Right - Top         Home            4576FE5C14395B2F-3CD883BEBA9F8B78        867CF1514911B0C1.local         fd0f:77ee:44e0:1:ff36:ffff:c489:bd43                         
Living Room Front - Top   Home            4576FE5C14395B2F-D6D3F6E58B6A9EDC        FE36252FAE750578.local         fd0f:77ee:44e0:1:87d7:d726:d7f7:dd5c                         
Smart Color Night Light   Home            4576FE5C14395B2F-97141DDAB5353877        A81710CF6E77.local                                                      192.168.1.89        
Tapo Mini Plug            Home            4576FE5C14395B2F-2BA6E0537BBA51D5        40AE30A5CCDB.local                                                      192.168.1.231       
Deck                      Lake House      A8CDF21E11FC069F-9CA8A41CF664B1E4        UNKNOWN                                                                                     
Dining Room Light         Lake House      A8CDF21E11FC069F-771D88250C1D4E2B        UNKNOWN                                                                                     
Family Room Light         Lake House      A8CDF21E11FC069F-53B1459994E462CA        UNKNOWN                                                                                     
Fireplace                 Lake House      A8CDF21E11FC069F-2D7E9B3B07FDF5BB        UNKNOWN                                                                                     
Front Porch               Lake House      A8CDF21E11FC069F-F9DF408D70F1F14F        UNKNOWN                                                                                     

#!/usr/bin/env python3

import subprocess
import json
import sys
import re
from collections import defaultdict

# ---------------- helpers ----------------

def run(cmd):
    return subprocess.check_output(cmd, text=True, stderr=subprocess.DEVNULL)

def get_locations():
    locations = json.loads(run(["smartthings", "locations", "-j"]))
    id_to_name = {}
    name_to_id = {}

    for loc in locations:
        id_to_name[loc["locationId"]] = loc["name"]
        name_to_id[loc["name"]] = loc["locationId"]

    return id_to_name, name_to_id

def get_matter_devices(location_id=None):
    cmd = ["smartthings", "devices", "--type", "MATTER", "-j"]
    if location_id:
        cmd += ["--location", location_id]

    devices = json.loads(run(cmd))
    results = []

    for d in devices:
        network_id = d.get("matter", {}).get("networkId")
        if not network_id:
            continue

        results.append({
            "label": d.get("label", "UNKNOWN"),
            "instance": network_id,
            "locationId": d.get("locationId"),
        })

    return results

def get_dns_sd_data():
    output = run(["dns-sd", "-t", "-r", "_matter._tcp"])
    lines = output.splitlines()

    data = defaultdict(dict)
    current = None

    instance_re = re.compile(r"=\s+\S+\s+(IPv4|IPv6)\s+(\S+)\s+_matter\._tcp")

    for line in lines:
        m = instance_re.match(line)
        if m:
            current = m.group(2)
            continue

        if not current:
            continue

        if "hostname =" in line:
            data[current]["hostname"] = line.split("[")[1].split("]")[0]
        elif "address =" in line:
            addr = line.split("[")[1].split("]")[0]
            if ":" in addr:
                data[current]["ipv6"] = addr
            else:
                data[current]["ipv4"] = addr

    return data

# ---------------- main ----------------

def main():
    sort_key = "label"
    reverse = False
    location_arg = None

    args = sys.argv[1:]

    positional_args = []

    for arg in args:
        if arg == "--sort":
            print("Error: --sort requires a value (e.g. --sort=hostname)", file=sys.stderr)
            sys.exit(1)

        elif arg.startswith("--sort="):
            sort_key = arg.split("=", 1)[1]

        elif arg == "--reverse":
            reverse = True

        elif arg.startswith("-"):
            print(f"Unknown option: {arg}", file=sys.stderr)
            sys.exit(1)

        else:
            positional_args.append(arg)

    # ---- positional argument validation ----
    if len(positional_args) > 1:
        print("Error: only one location name may be specified", file=sys.stderr)
        sys.exit(1)

    if positional_args:
        location_arg = positional_args[0]

    valid_sorts = {
        "label", "location", "instance", "hostname", "ipv4", "ipv6"
    }

    if sort_key not in valid_sorts:
        print(f"Invalid sort key: {sort_key}", file=sys.stderr)
        print(f"Valid options: {', '.join(sorted(valid_sorts))}", file=sys.stderr)
        sys.exit(1)

    id_to_name, name_to_id = get_locations()

    location_id = None
    if location_arg:
        location_id = name_to_id.get(location_arg)
        if not location_id:
            print("Unknown location", file=sys.stderr)
            sys.exit(1)

    devices = get_matter_devices(location_id)
    dns_data = get_dns_sd_data()

    records = []
    for d in devices:
        dns = dns_data.get(d["instance"], {})
        records.append({
            "label": d["label"],
            "location": id_to_name.get(d["locationId"], "UNKNOWN"),
            "instance": d["instance"],
            "hostname": dns.get("hostname", "UNKNOWN"),
            "ipv6": dns.get("ipv6", ""),
            "ipv4": dns.get("ipv4", ""),
        })

    records.sort(key=lambda r: r.get(sort_key, ""), reverse=reverse)

    grouped = defaultdict(list)
    for r in records:
        grouped[r["location"]].append(r)

    print(
        f"{'DEVICE LABEL':<25} {'LOCATION':<15} {'INSTANCE NAME/NETWORK ID':<40} "
        f"{'HOSTNAME':<30} {'IPv6 ADDRESS':<40} {'IPv4 ADDRESS':<20}"
    )
    print("-" * 180)

    for location in sorted(grouped):
        for r in grouped[location]:
            print(
                f"{r['label']:<25} "
                f"{r['location']:<15} "
                f"{r['instance']:<40} "
                f"{r['hostname']:<30} "
                f"{r['ipv6']:<40} "
                f"{r['ipv4']:<20}"
            )

if __name__ == "__main__":
    main()

The script will pull all MATTER devices from the API, but you have to be local to retrieve the DNS discovery info. The script takes an argument of the location name to filter for only a single location, e.g. Home or “Lake House”.

3 Likes
57

TLDN; Does anyone have the combination of smarthings + vodafone isp + vodafone powerhub + more than 28 thread devices? Chatgpt is suggesting that the issue/ I’m sceptical.
Second question if you have more than 28 thread devices and have swapped to a 3rd party router for fibre which play nicely with smartthings.

I have engaged with smartthings engineering team and they are looking into the issue.
in the meantime ive gone down a chat gpt rabbit hole

There are no mdns or igmp settings on the hub and ChatGPT says I have too many devices for the hub to deal with, is it really treating thread as a DOS attack? Ive searched regular google for others with the same issue and drawn a blank so I’m looking at chat GPT in the interim.
Plausible or bullshit ? Hard to know with ai.
I’d buy and install a new 3rd party router if i had any confidence the vodafone hub was the issue, but at this stage I feel I’m in a dark room, looking for a black cat, that isn’t there.

chat gpt snippet
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
At 28–29 Matter/Thread devices, your network is generating a significant amount of mDNS (Multicast DNS) traffic. Because your Vodafone Hub has IGMP Snooping disabled, it likely views this constant chatter as a “broadcast storm” and is dropping those packets to protect its own CPU. This is why you are seeing the “Ignoring mod pit” error.

To support a large-scale SmartThings and Matter ecosystem, you need a router that can intelligently handle multicast traffic

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dowload of what is showing in my vodafone hub log
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Date Time Category Severity Log Details
04.02.2026 01:45:33 data Error failed to send packet: Address family not supported by protocol
04.02.2026 01:45:33 data Error failed to send packet: Address family not supported by protocol
04.02.2026 01:45:26 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:25 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:24 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:22 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:22 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:22 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:20 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:20 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:19 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:19 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:18 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:18 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:18 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:18 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:18 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:17 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:17 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:17 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:17 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:17 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:16 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:16 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan
04.02.2026 01:45:16 lan Warning Ignoring MLD pkt on non snooping enabled bridge interface lan

58

If there was evidence that you have a working Thread stack on your ST hub, I might be willing to go down that path. Right now, there is no evidence you have a working Thread stack since the AWA is showing you the error regarding the mesh local prefix.

What kind of computers do you have on your local LAN and do you have some basic Linux skills? The tools I used to figure out how the Off-Mesh Route is implemented on the ST hub could tell us a lot about the state of your environment. Minimally, if you have a Windows laptop, you can look at your route table using “netstat -r -n | more” and scroll down to the IPv6 routes. If the TBR is functioning properly on your ST hub, you’ll see a route that looks something like one of these:

 21    291 fd0f:77ee:44e0:1::/64    fe80::2eba:baff:fe98:fb17
 21    291 fd18:e3d8:12a6:1::/64    fe80::9d96:60a:6e85:f7a4
 21    291 fd54:6351:4b7e:1::/64    fe80::9ec8:e9ff:fea4:8069
 21    291 fdf8:d448:a0a3:1::/64    fe80::1aa9:edff:fe7d:8092
 21    291 fdf8:d448:a0a3:1::/64    fe80::1aa9:edff:fe7c:da92

The FD routes are the ULA routes advertised to the LAN that are used by Thread mesh devices for Off-Mesh Prefix addressing. If you have a Linux computer or can install a Linux distribution on Windows using WSL (or run a VM), we can take a look at some service discovery to see whether the TBR service is being announced on the LAN and whether any Matter device service announcements are present.

The messages on your router regarding MLD mean that it is ignoring multicast messages that are used by IPv6 routers to identify nodes on a local link that want to receive specific multicast traffic. So, yes it might be ignoring mDNS discovery requests or mDNS announcements but that wouldn’t affect the operation of other devices on the LAN or the mesh. The whole point of mDNS is that there is no requirement for a central DNS server/authority in order to discover devices that offer services.

Edit: Looks like you can get the service discovery tool dns-sd for Windows if you install Apple’s Bonjour Print Services. Once you install that package, you can try the following commands:

  • “dns-sd -B _meshcop._udp” - Searches for TBR being advertised on the LAN
  • “dns-sd -B _matter._tcp” - Searches for Matter capable devices on the LAN
  • “dns-sd -L [instance name] _matter._tcp” Returns the local DNS name of the specific service instance name. Instance names will be listed in the search for Matter devices
  • “dns-sd -G v4v6 [hostname].local” - Returns the IPv4 or IPv6 address of DNS name which is returned when querying the instance detail

And if everything is working as expected, you should be able to ping the device using its Off-Mesh Prefix address. In this case, the top outlet of my duplex Front Porch outlet.

Front Porch - Top         Home            4576FE5C14395B2F-70DDD7356FF5182D        E2554077D4CB9A04.local         fd0f:77ee:44e0:1:f3d6:ac6e:7b4d:7167

dns-sd -B _meshcop._udp
Browsing for _meshcop._udp
Timestamp     A/R Flags if Domain                    Service Type              Instance Name
21:11:06.756  Add     3 21 local.                    _meshcop._udp.            eero_thread #7957
21:11:06.757  Add     3 21 local.                    _meshcop._udp.            eero_thread #6FE0
21:11:06.757  Add     3 21 local.                    _meshcop._udp.            amazon #48E4 (37871)
21:11:06.757  Add     3 21 local.                    _meshcop._udp.            OpenThread BorderRouter #0B28
21:11:06.757  Add     2 21 local.                    _meshcop._udp.            Samsung SmartThings-Station #A2DF

dns-sd -B _matter._tcp
Browsing for _matter._tcp
Timestamp     A/R Flags if Domain                    Service Type              Instance Name
21:11:45.940  Add     3 21 local.                    _matter._tcp.             650B35BCFD84FF98-B06F5C9A9A48A486
21:11:45.941  Add     3 21 local.                    _matter._tcp.             4576FE5C14395B2F-926396EF0AD72CED
21:11:45.941  Add     3 21 local.                    _matter._tcp.             4576FE5C14395B2F-70DDD7356FF5182D
21:11:45.941  Add     3 21 local.                    _matter._tcp.             4576FE5C14395B2F-D6D3F6E58B6A9EDC
21:11:45.941  Add     3 21 local.                    _matter._tcp.             4576FE5C14395B2F-3CD883BEBA9F8B78
21:11:45.941  Add     3 21 local.                    _matter._tcp.             4576FE5C14395B2F-8FFF091950C2F6EA
21:11:45.942  Add     2 21 local.                    _matter._tcp.             4576FE5C14395B2F-2BA6E0537BBA51D5
21:11:46.043  Add     2 21 local.                    _matter._tcp.             6FD31162351F76DA-05AEAAEDDD4CA2D1
21:11:46.045  Add     2 21 local.                    _matter._tcp.             6FD31162351F76DA-05AEACC352B99841
21:11:46.057  Add     2 21 local.                    _matter._tcp.             6FD31162351F76DA-036B5296BBCCAFB1
21:11:46.064  Add     2 21 local.                    _matter._tcp.             6FD31162351F76DA-036B5296BA8137D1
21:11:46.228  Add     3 21 local.                    _matter._tcp.             4576FE5C14395B2F-97141DDAB5353877
21:11:46.228  Add     3 21 local.                    _matter._tcp.             444A64293B468CE9-AEF44D47E48C0F5A
21:11:46.228  Add     2 21 local.                    _matter._tcp.             0382F8A995E9EE5A-00000199CB5AFEF3


dns-sd -L  4576FE5C14395B2F-70DDD7356FF5182D _matter._tcp
Lookup 4576FE5C14395B2F-70DDD7356FF5182D._matter._tcp.local
21:13:30.411  4576FE5C14395B2F-70DDD7356FF5182D._matter._tcp.local. can be reached at E2554077D4CB9A04.local.:5540 (interface 21)
 SII=800 SAI=800 T=0

dns-sd -G v4v6 E2554077D4CB9A04.local
Timestamp     A/R Flags if Hostname                  Address                                      TTL
21:13:54.235  Add     2 21 E2554077D4CB9A04.local.   FD0F:77EE:44E0:0001:F3D6:AC6E:7B4D:7167%<0>  120

ping FD0F:77EE:44E0:0001:F3D6:AC6E:7B4D:7167

Pinging fd0f:77ee:44e0:1:f3d6:ac6e:7b4d:7167 with 32 bytes of data:
Reply from fd0f:77ee:44e0:1:f3d6:ac6e:7b4d:7167: time=233ms
Reply from fd0f:77ee:44e0:1:f3d6:ac6e:7b4d:7167: time=129ms
Reply from fd0f:77ee:44e0:1:f3d6:ac6e:7b4d:7167: time=115ms
Reply from fd0f:77ee:44e0:1:f3d6:ac6e:7b4d:7167: time=216ms

Ping statistics for fd0f:77ee:44e0:1:f3d6:ac6e:7b4d:7167:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 115ms, Maximum = 233ms, Average = 173ms
2 Likes
59

Output from discovery dns-sd on iOS, what does this tell me ?

SmartThings Hub #87A4._meshcop._udp.local.

hubv4-04022001721.local:49154
192.168.1.138:49154
192.168.1.137:49154
fd7e:1dd1:b99a:f2eb:5826:6bed:c90:fe37:49154
fe80::8de4:c637:b6de:2cf8%en0:49154
fd7e:1dd1:b99a:f2eb:ddc5:22be:4e86:554b:49154
fd4b:7903:3853:1:bfdf:12f1:d669:bb75:49154
fd4b:7903:3853:1:ea99:1da4:7058:f031:49154
2a0a:ef40:1782:3201:8518:4658:5029:1cb4:49154
2a0a:ef40:1782:3201:9a03:9b55:c25:2bb6:49154
fe80::fda9:8dfb:91c5:dc9d%en0:49154

at = <00006947 09cd0000>
bb =
dn = DefaultDomain
id = <e64e27e5 02e228d2 cb34152b 521b7150>
mn = Hub
nn = ST-4021230952
omr = <40fdd589 0af41600 01>
pt = <33bed978>
rv = 1
sb = <00000ab1>
sq = y
tv = 1.4.0
vn = SmartThings
xa = <d282f34e 681787a4>
xp = <7e1dd1b9 9ac2f2eb>

60

Quick question. Your 48 thread devices, how many tbrs do you have ?
Gemini ai is trying to suggest that 28/29 exceeds the limit for a single thread border router and suggests that could be part of the reason I’m having issues and the thread stack has collapsed. I’m extremely sceptical of this verdict.