Matter / Thread - Failing commissioning

[fallow fiber]

Hey there, I guess this topic has been discussed quite a bit, but I didn't find a solution that worked for me, either on the net or this forum.
TL;DR : When I try to commission a device from the companion App, it fails at the "checking Wifi" step "ensure you are on the right Wifi..."

So let me explain,
I'm quite new (< 3 months) to HA, but not to domotic or techy stuff. This Matter / Thread protocol is driving me nut as there must be something I misunderstood and prevents me to fix it myself.

I had a AEOTEC Smarthub (Smartthings; which does Zigbee, Z-wave, Matter and Thread hub I wish I could use it without smartthings, it is a decent piece of tech) with 4 Matter (thread) EVE Energy smartplugs. It was working quite well. When I moved to HA and removed all my stuff from Smartthings I kept these 4 in Smartthings and integrated them with the addon (which worked quite OKish) until this PA token sheanigans which lead me to just drop Smartthing for a Cloudless Matter/thread solution so I bought a fresh new ZBT-1 usb stick set up with the thread only firmware.

I'm running HA on a Raspberry PI4 and it's up to date with current versions

I guess I've been through the tutorial the right way, ZBT-1 is set up, Matter server is up, Thread/Open Thread services are setup and I have a thread network
Linked some screenshots of the actual configuration

My network is as follow :

• ISP router (in France they rent you a router that they manage) 192.168.1.0 / 24 which provide both ETH and Wifi (SSID 1 on 2.4, 5 and 6Ghz)
  Only some devices are directly plugged to this router, like my computer, the raspberry hosting HA (eth), sometime my phone and my NAS
• An Asus ZenWifi mesh router which provides another set of SSIDs (SSDI2, SSID2_5Ghz, SSID2_5Ghz-2 (backhaul)) 192.168.50.0 /24
  Most Smart devices are using this network (IP cameras, TV, Hue, ...) Either wired or using the 2.4Ghz wifi and RPI is also connected to this Wifi to reach these devices it is also wired to the ISP in order to reach out the internet
• Hue is using Zigbee through the Hub I guess
  I'm living on the countryside in a big house, neighbors are far enough, wireless channels are all different and all this little world is A-OK.

I've ensured my phone and HA are sharing the same Thread credentials, ensured I'm connected to the same wifi than the RPI

Regarding Matter now, when I try to add a power plug from Devices/Add/Add a matter device/Scan QR it fails at the sharing wifi step, I guess it times out, I tried being on the ISP router wifi (just in case) and in the end, this device is thread only, I don't get why I need to sync WIFI credentials with it.
I'm quite lost as now, even adding this device to Smartthings seems to fail (But I guess it's because my phone isn't set to work with its Thread network)
I don't get much logs from Matter server either.

Any clue ?
I'd also like some teaching about what's happening during the commissioning, I hate to use something I don't get.
Regards

[turbid swallow]

Did you factory reset the Eve plugs before trying to commission them ? Also I notice you dont have a flat network, which is dangerous with Matter because the Ipv6 multicast traffic needs to be able to travel freely over layer 2. It cant be routed.

So at least make sure your phone is connected to the WiFi where also your HA lives

Also, range of ZBT-1 is rather limited so ensure that when you are commissioning the (first) device, make sure are close to both the HA server and the device with your phone

Commissioning of a new device (out of the box or factory reset) uses the QR code. The phone uses bluetooth to hand over the wifi or thread credentials to the device and then the device uses the network/IP connection to establish the secure connection with the matter server. Once the device is in the first Matter controller (fabric), you can no longer use that QR code for security reasons. If you liek to add the device to other ecosystems/controllers as well, then you "share" the device from controller A to B

[winged verge]

the reason why you must be on the same WiFi network as your Home Assistant setup when commissioning a Thread device is because ultimately, Thread utilizes IPV6 networking. It's all one network, not it's own thing like Zigbee.

[fallow fiber]

• Eve was factory reset : 10s push, auto detected by the phone while in commissioning mode
• Yep Phone is on the same network, And it's exactly the same configuration (network wise) than the aeotec hub was (separate networks, phone on SSID2, hub plugged to 192.168.50.0 network)
• Range wise, the plug is in the same room as the RPI+ZBT-1, let's say 1.5m appart, I was able to commission it with the aeotec hub 20m away

@winged verge , Well ok, it uses IPv6 but why would it use this Wifi to do that, What's the point of having a dongle with an antena if ultimately the thread networks runs on SSID2 over IPv6 ?

[winged verge]

because your phone does not have a thread radio, not usually anyways

so your phone verifies your network connection through wifi

[turbid swallow]

One thing to double check (it should be set by default but still good to check): Within HA settings, system, networking, ensure IPv6 is set to automatic on the main interface

[fallow fiber]

it is

I was going to post a screenshot but /host/info seems to be screwed 😄 I'm restarting the RPI

[fallow fiber]

It makes sense indeed

[turbid swallow]

When commissioning a device using your phone, the Matter SDK of the operating system on your phone (so Android or iOS) is doing the first steps of the whole process. Then when the phone has managed to setup the device, it will hand it over to the Matter controller. It is in this step that often troubles happen if the networking is preventing the IPv6 multicast traffic

[winged verge]

ok so like, is your phone connected to your ISP-provided gateway (which you say your Home Assistant setup is connected to) or your IoT router

[turbid swallow]

We do have an alternative though where the initial commisisoning is also done by the HA server. It does however require a bluetooth stick in the HA server

[winged verge]

it has to be on the former

[fallow fiber]

I tried that also, commissioning from both wifi networks, I even splitted my ISP Wifi to ensure I was on 2.4GHz

[winged verge]

i honestly don't know what happens when Home Assistant is connected to two different networks at the same time. That sounds messy

[fallow fiber]

Yep that's my last resort, but I wished to do that "the proper way"

[turbid swallow]

That won't work well, we have no clue what interface to use

[fallow fiber]

To be fair, it works quite well, I did that to manage the routing to external in a more convenient way while keeping my devices in another network

[fallow fiber]

Well it worked flawlessly with Smartthings though

[turbid swallow]

Smartthings is not Home Assistant

[fallow fiber]

Yup, I mean networkwise/thread wise

[winged verge]

perhaps in your scenario, commissioning via the matter-python-server web ui might be the best bet.
Apple/Google's matter commissioning processes work well for most people but unfortunately they're diagnostic black boxes and they really assume you have a rather uncomplicated network

[turbid swallow]

You need a single network interface on the HA host for Matter to work in a predictable way

[turbid swallow]

It will, but the issues will return if he ever may add more border routers

[fallow fiber]

Either this, or I have to re reset my thread creds and go the "google way"

then share my devices

[turbid swallow]

You will run into teh same troubles with multiple network interfaces

We can not handle that very well

[winged verge]

well to be fair, many issues arise when one tries to add more border routers to the thread mesh, regardless of how you go about it lol

[turbid swallow]

We have some plans to make the interface configurable but currenty we dont have hat

[fallow fiber]

Is it a protocol issue or an implementation issue in HA atm ?

[turbid swallow]

If there is a strong RF link between all "segments" multiple border routers will work. If that is not the case....🔥

[winged verge]

i guess it works if all your TBRs are from the same vendor but that's not reality for most people and that's the core issue

i've got two apple tbrs, a google tbr, and a skyconnect in my house and right now i'm basically only using the skyconnect because i can't join anything else up. really wish 1.4 would get here already!

[turbid swallow]

It's a bit more nuanced than that but yeah, in general interoperability with Thread is crap.
https://github.com/home-assistant/core/issues/134231#issuecomment-2604219962

[turbid swallow]

We simply do not support having multiple network interfaces on your HA host when using Matter.
So you should try to avoid that to make this work reliable. Maybe some day we have an extra setting to manually set the multicast interface but that is not the case today.

We use the primary interface btw now statically

[fallow fiber]

to answer that

[turbid swallow]

You are running Home Assistant OS on the pi right ?

[fallow fiber]

yup

I could try to flatten my network by making the Asus Router join the same network and the same IP range as my ISP router though

I'd rather not only for 3 plugs ^^

one other thing, I could try to unplug my eth - ISP, plug the rpi on the asus router

and i'll NAT / TCP port forward from ISP router to asus - port forward to the rpi to ensure it is still reachable from companion

[turbid swallow]

That sounds like a more future prooof solution. Just a single ethernet link on the pi on your home network

[obsidian tree]

iPhone 15 and newer have Thread radios. Newer iPads do as well. I had trouble pairing some Matter devices from my iPhone 14 Pro Max. As soon as I tried with a 10th gen iPad, everything paired without a hitch.

[fallow fiber]

Well thanksfully, my asus router has some premade settings to join an existing network and it went flawlessly (mostly... I just had to re-enroll my Sonos surround)

Didn't retry yet, but to be sure, I don't need Wifi enabled on the RPI hosting HA, are we ok with that? I just need IPv6 on eth

[fallow fiber]

Well I tried with one quite new iPad without success (out of despair :D)

[turbid swallow]

yes, no wifi enabled on the pi. Just the ethernet interface

[fallow fiber]

Well I tried with only one flat LAN and wifi disabled on rpi without more success

I have two lines that kinda triggers me :

025-02-02 01:54:03.519 (Dummy-2) CHIP_PROGRESS [chip.native.DIS] mDNS broadcast full failed in 1 separate send attempts.
2025-02-02 01:54:03.519 (Dummy-2) CHIP_ERROR [chip.native.DIS] Failed to advertise records: src/inet/UDPEndPointImplSockets.cpp:421: OS Error 0x02000065: Network is unreachable

And this one

2025-02-02 01:54:03.519 (Dummy-2) CHIP_DETAIL [chip.native.DIS] Warning: Attempt to mDNS broadcast failed on wlan0: src/inet/UDPEndPointImplSockets.cpp:421: OS Error 0x02000065: Network is unreachable

Well wlan is disconnected... I did restart the matter server but not HA though

[turbid swallow]

You need to restart the whole HA host

[fallow fiber]

restarting, I'll let you know

...

home assistant took ages to reboot

😄

For a moment I though I was going to spend the afternoon making it boot again

I still have this message in the logs on init, I don't know if I should take care atm, I'll try a commission

2025-02-02 14:24:55.310 (Dummy-2) CHIP_PROGRESS [chip.native.DIS] mDNS broadcast full failed in 1 separate send attempts.
2025-02-02 14:24:55.310 (Dummy-2) CHIP_ERROR [chip.native.DIS] Failed to advertise records: src/inet/UDPEndPointImplSockets.cpp:421: OS Error 0x02000065: Network is unreachable

Not much success,

here are the logs (I obfuscated some data I didn't felt confident sharing ^^)

It still fails at the sharing wifi creds step

The only thing I could try is to remove my other SSID (I left the ISP Wifi on)

but well, HA isn't connected to wifi and my phone used for the commissioning isn't connected to this one

[turbid swallow]

ipv6 enabled on the primary network interface ? Just set to automatic

Maybe it got disabled

[fallow fiber]

Seems good to me

[fallow fiber]

I dont know why I have this many different ipv6 fields though, its set to automatic and I'm not knowledgeable on this protocol (yet) to set it manually right 😉

[fallow fiber]

So I did some testing,
bonjour on my computer actually returns me some entries :

dns-sd -B _services._dns-sd._udp
Browsing for _services._dns-sd._udp
Timestamp A/R Flags if Domain Service Type Instance Name
13:46:49.952 Add 3 22 . _tcp.local. _hue
13:46:49.952 Add 3 22 . _udp.local. _trel
13:46:49.952 Add 3 22 . _udp.local. _meshcop
13:46:49.952 Add 3 22 . _tcp.local. _airplay
13:46:49.952 Add 3 22 . _tcp.local. _raop
13:46:49.952 Add 3 22 . _tcp.local. _spotify-connect
13:46:49.952 Add 3 22 . _tcp.local. _sonos
13:46:49.952 Add 3 22 . _tcp.local. _smb
13:46:49.953 Add 3 22 . _tcp.local. _ftp
13:46:49.953 Add 3 22 . _tcp.local. _device-info
13:46:49.953 Add 3 22 . _tcp.local. _home-assistant

I guess this means my network is mDNS compliant

But I noticed under the IPv6 tab on my ISP router configuration that the given IP doesn't reflect the gateway in HA

Could this be linked ?

DNS match with the prefix, first ipv6 of eth0 too but not gateway, again, maybe ipv6 is completely different to ipv4 and I'm mislead ...

[turbid swallow]

Matter is IPv6 mdns, not IPv4 mdns. So your network is IPv4 mdns compliant, that does not mean at all matter will work.

[turbid swallow]

You can try to disable IPv6 completely on your network gear. That way everything will purely work on link local (neighbour) discovery.

[fallow fiber]

I tried that, doesn't seems to have any effect

[turbid swallow]

I'm out of options sorry. Maybe somebody else has more ideas. Thread is a mess and even the slighest hiccup in your network can make a difference between working on epic fail.

[fallow fiber]

Damn

thanks for your help anyway 😄

I'll try disabling ISP wifi though I didn't do that yet

[turbid swallow]

Yeah, sorry. Try narrowing it down by simplifying the network until you found the culprit

[fallow fiber]

yup, didn't work either

I'm quite worried though, because
A- I can't commission them to google home anymore (maybe my phone's thread settings)
B- It worked just fine with aeotech smartthings, which acted pretty much the same as HA in this scenario, A local thread hub, it was just routing it to smarthings instead of HA

it's time to ask every AI chatbots and dig deep in the internet

[fallow fiber]

Well I've spent some time looking for mDNS issues, I've run a commissioning while looking for packets from my phone, I don't see much issues

I get this in Openthread border router
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface 192.168.1.88/end0/2
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface 192.168.1.88/end0/2
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface 192.168.1.88/end0/2
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::9c01:86ff:fe89:a632/vethfdc489c/26
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::9c01:86ff:fe89:a632/vethfdc489c/26
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::9c01:86ff:fe89:a632/vethfdc489c/26
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::9c01:86ff:fe89:a632/vethfdc489c/26
01:23:37.827 [W] Mle-----------: Failed to process Child ID Request: Security
01:24:09.335 [N] RouterTable---: Allocate router id 39
01:26:49.302 [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:96, chksum:0313, ecn:no, to:868de0dd378cb72c, sec:no, error:NoAck, prio:net, radio:15.4
01:26:49.303 [N] MeshForwarder-: src:[fe80:0:0:0:34b2:c15e:cf0c:fa64]:19788
01:26:49.303 [N] MeshForwarder-: dst:[fe80:0:0:0:848d:e0dd:378c:b72c]:19788
01:26:50.813 [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:96, chksum:ce01, ecn:no, to:868de0dd378cb72c, sec:no, error:NoAck, prio:net, radio:15.4
01:26:50.813 [N] MeshForwarder-: src:[fe80:0:0:0:34b2:c15e:cf0c:fa64]:19788
01:26:50.813 [N] MeshForwarder-: dst:[fe80:0:0:0:848d:e0dd:378c:b72c]:19788
01:26:51.692 [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:96, chksum:0643, ecn:no, to:868de0dd378cb72c, sec:no, error:NoAck, prio:net, radio:15.4
01:26:51.693 [N] MeshForwarder-: src:[fe80:0:0:0:34b2:c15e:cf0c:fa64]:19788
01:26:51.693 [N] MeshForwarder-: dst:[fe80:0:0:0:848d:e0dd:378c:b72c]:19788
01:28:23.709 [N] RouterTable---: Release router id 39
01:41:37.199 [N] RouterTable---: Allocate router id 39
01:42:14.681 [N] MeshForwarder-: Dropping (reassembly queue) IPv6 UDP msg, len:718, chksum:5bc7, ecn:no, sec:yes, error:ReassemblyTimeout, prio:normal, rss:-67.0, radio:15.4
01:42:14.681 [N] MeshForwarder-: src:[fd35:cc4a:66ad:e8a9:3d32:d3c:fd1d:f0d4]:49155
01:42:14.681 [N] MeshForwarder-: dst:[fd35:cc4a:66ad:e8a9:c839:e65c:6ad4:1ca5]:53540
01:43:46.935 [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:96, chksum:64ba, ecn:no, to:d63b0b5282c26d9c, sec:no, error:NoAck, prio:net, radio:15.4
01:43:46.935 [N] MeshForwarder-: src:[fe80:0:0:0:34b2:c15e:cf0c:fa64]:19788
01:43:46.935 [N] MeshForwarder-: dst:[fe80:0:0:0:d43b:b52:82c2:6d9c]:19788
01:43:47.932 [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:96, chksum:5b60, ecn:no, to:d63b0b5282c26d9c, sec:no, error:NoAck, prio:net, radio:15.4
01:43:47.933 [N] MeshForwarder-: src:[fe80:0:0:0:34b2:c15e:cf0c:fa64]:19788
01:43:47.933 [N] MeshForwarder-: dst:[fe80:0:0:0:d43b:b52:82c2:6d9c]:19788
01:43:49.377 [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:96, chksum:e5f8, ecn:no, to:d63b0b5282c26d9c, sec:no, error:NoAck, prio:net, radio:15.4
01:43:49.377 [N] MeshForwarder-: src:[fe80:0:0:0:34b2:c15e:cf0c:fa64]:19788
01:43:49.377 [N] MeshForwarder-: dst:[fe80:0:0:0:d43b:b52:82c2:6d9c]:19788
01:45:22.644 [N] RouterTable---: Release router id 39
Default: DNS Message from 192.168.1.15:5353 to 224.0.0.251:5353 length 4 too short

I'll look forward

[obsidian tree]

I commissioned 20 devices into HA. I had a helluva time getting 2 of them to commission. IPv6 is not required from your router as long as everything is in the same L2 broadcast domain (including your Matter controller). IPv6 has to be enabled with link local on the matter controller.

I was finally able to solve my issues. Turned out to be a bug in the access point on the 2.4Ghz band. I am using Ubiquiti equipment. I had a U7 Pro deployed where these two devices wouldn’t commission. The U6 pro that is in place for the rest of the devices worked great. I swapped the U7 pro for an old AC Lite and everything lit up on the first or second try.

[fallow fiber]

Well at the moment IPv6 isn't activated on both my routers (ISP one just sharing the ftth and acting as a main router and the Asus XT8 handling WIFI ssids)

I think I have something :

Logs on ASUS router :
Feb 3 18:08:39 lld2d[15813]: packetio_recv_handler: g_opcode 8 with seq=53395 (from realsrc=44:d4:54:62:31:50) is illegal; dropping
Feb 3 18:08:39 lld2d[15813]: packetio_recv_handler: g_opcode 8 with seq=53395 (from realsrc=44:d4:54:62:31:50) is illegal; dropping
Feb 3 18:08:39 lld2d[15813]: packetio_recv_handler: g_opcode 8 with seq=53395 (from realsrc=44:d4:54:62:31:50) is illegal; dropping
Feb 3 18:08:43 lld2d[15813]: packetio_recv_handler: g_opcode 8 with seq=53395 (from realsrc=44:d4:54:62:31:50) is illegal; dropping
Feb 3 18:08:43 lld2d[15813]: packetio_recv_handler: g_opcode 8 with seq=53395 (from realsrc=44:d4:54:62:31:50) is illegal; dropping
Feb 3 18:08:43 lld2d[15813]: packetio_recv_handler: g_opcode 8 with seq=53395 (from realsrc=44:d4:54:62:31:50) is illegal; dropping