#Could use some help to get Thread working on my network

1 messages · Page 1 of 1 (latest)

calm birch
#

Hello there! I am slowly going mad over my network setup, trying to get a Matter over Thread LED Dimmer working.

I've tried almost anything and don't know anymore what troubleshooting should be done next.

My setup is:

  • Home Assistant Yellow, running latest HAOS, Matter Server, OTBR and Thread.
    • WLAN is setup for IPV4 and IPV6
    • Ethernet is disabled (only used for POE)
  • Unifi AC Lites running only one 2.4GHz network
  • No VLAN's
  • IPV6

Using mDNS discovery app, I can see my OTBR on my mobile phone.

The Matter Server logs show a lot of:
(Dummy-2) CHIP_ERROR [chip.native.DIS] Failed to reply to query: src/inet/UDPEndPointImplSockets.cpp:417: OS Error 0x02000065: Network is unreachable
CHIP_ERROR [chip.native.DIS] Failed to reply to query: src/inet/UDPEndPointImplSockets.cpp:417: OS Error 0x02000063: Cannot assign requested address

The OTBR logs show a lot of:
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::841:11ff:fefa:b420/veth4f3a597/29
2026-01-20 12:32:36.242 (Dummy-2) CHIP_ERROR [chip.native.DIS] DNSSD packet parsing failed (for SRV records)
2026-01-20 12:32:36.243 (Dummy-2) CHIP_ERROR [chip.native.DIS] DNSSD packet parsing failed (for non-srv records)

I think there's something wrong with my network setup or mDNS.

But I don't know what troubleshooting step I should do next. Can you please advise me on that?

calm birch
#

What I've tried so far:

  • Change about any setting in my Unifi setup (toggle IGMP Snooping, toggle MDNS Forwarding, )
  • Change phones used to commission the LED Dimmer
  • Cleared Google Play Services Cache
  • Changed network settings in Home Assistant
  • Changed location of the LED Dimmer closer to my Home Assistant Yellow
  • Read about any topic and thread related to these errors, and tried every advised solution
  • Commission using the web interface of the Matter Server

Trying all these different things, made me a kind of clueless about where to go now

civic sand
#

what error messages specifically are you seeing on the phone when you try to set up the device?

#

the particular errors you get, or the point during commissioning when the error happens, hints at which part of the system isn't working

calm birch
#

The commissioning fails at the "checking network connectivity" step.

The error is "cannot connect to thread network".

I cannot make sense of the logs, although it might contain something useful:

20:14:16.203 [N] RouterTable---: Allocate router id 62
20:14:18.364 [N] MeshForwarder-: Dropping (reassembly queue) IPv6 UDP msg, len:313, chksum:0abd, ecn:no, sec:yes, error:ReassemblyTimeout, prio:normal, rss:-80.0, radio:15.4
20:14:18.364 [N] MeshForwarder-: src:[fd74:4d83:fc31:60a0:6d2:14cd:ca3b:abe]:49155
20:14:18.364 [N] MeshForwarder-: dst:[fd74:4d83:fc31:60a0:529c:24d:1f4a:785]:53536
20:15:46.353 [N] RouterTable---: Release router id 62

civic sand
#

Ok. so that message on the phone means that the phone is unable to talk to the matter device via the thread border router.

#

is the phone on the same subnet/vlan as the thread border router?

#

it will not work otherwise, because the phone needs to receive ipv6 router announcements from the TBR in order to be able to route traffic to the thread devices.

#

mdns relay is not sufficient for thread. the mdns might be working (it might relay an ipv6 address for the thread device) but that's not helpful if there's no route to pass traffic to that ipv6 address.

calm birch
#

Okay, that might be the direction. I'm not using any VLAN's, so that should not be the problem. I'll try and reboot my phone and HA, next to one of the access points. Let's see if that makes any difference

civic sand
#

if you have any multicast enhancement related features on the wifi network, try toggling that, they can prevent ipv6 router announcements from working.

#

Also, I've heard reports from some people that if ipv6 is disabled in unifi network equipment, it might be blocking ipv6 router announcements from other devices.

calm birch
#

Unfortunately rebooting both devices on my desk didn't solve the problem.

IPV6 is enabled in my unifi network. I've disabled all multicast featuers, but will toggle them anyway, just to be sure.

civic sand
#

You should be able to see on your phone that it has an IP address in the fd40:e40c:98ff::/64 subnet advertised by the thread border router if everything is working

#

none of the messages in your otbr add-on logs look problematic - it looks like the device you're trying to commission is joining the thread network, but the phone is unable to talk to it via the thread border router so it times out and leaves the thread network again.

#

running an mdns browser app on the phone and confirming that the _meshcop._udp service advertised by the TBR is visible is a good test too.

calm birch
#

My phone is able to see the TBR.

civic sand
#

Oh, i was looking at the wrong prefix. fd2b:ce86:70ab:7694::/64 is the correct one, yeah

calm birch
#

It has no IP Address in the fd40 subnet. Only in the fd2b subnet.

49d.17:03:56.721 [C] P-SpinelDrive-: Software reset co-processor successfully
00:00:00.045 [N] RoutingManager: BR ULA prefix: fd40:e40c:98ff::/48 (loaded)
00:00:00.045 [N] RoutingManager: Local on-link prefix: fd2b:ce86:70ab:7694::/64

Is that where things go wrong?

civic sand
#

one of the prefixes is used for the thread network, the other one is advertised on the lan, and I always get mixed up between the two of them

calm birch
#

Can't blame you for that, I can't make anything out of IPV6

civic sand
#

so that all looks correct, I would expect the matter device commissioning to be getting further than it is :(

calm birch
#

Hmm, that would be an explanation for this behaviour indeed. Unfortunately there's only Android devices in here, so I can't test for that...

calm birch
#

Never knew about this Android settings option. But it seems my phone does not discover the Thread network...

calm birch
#

Thinking about the above, I tried to bypass my android phone by directly connecting through the web interface. Both on the Python and JS Matter Server addons. They fail for different reasons, but I think there's something wrong in my network. Both logs are attached (the Matter JS also spits some errors for my three connected Matter over WiFi devices). What am I missing?

calm birch
#

Wow, many, many thanks to all people allowing the OTBR Thread Beta 1.4 functionality. Although commissioning didn't go flawless, I managed at last by fiddling around a lot. But the main result is: the dimmer is working 🥳

civic sand
#

yep, the new Beta version of OTBR switches to a different mDNS implementation which works around the android bug. glad to hear it fixed the issue.

calm birch
#

Well, it did, kind of. I had the joy of playing around with it for two minutes. And synce then it's gone offline. Don't know what happened. Will start troubelshooting againg tomorrow, first going to get some sleep. But still: thanks for all the efforts on this

civic sand
#

yeah, there's a few things to do to check this, but the most obvious causes would be 1. someone turned off a lightswitch and powered off the light, or 2. thread network interference or range issues :/

calm birch
#

Well, the first one can be ruled out pretty quickly: I was the only one at home, and the dimmer switch is a mains powered built in dimmer, so it can't be turned off.

The second one would be strange, since the Yellow about one meter apart from the dimmer for testing purposes.

I tried to do a channel monitor scan, which gave me this result:
docker exec addon_core_openthread_border_router ot-ctl channel monitor enabled: 0 Done

I don't know what that means, but it seems wrong to me.