OTBR error - Failed to perform next registration and mDNSPlatformSendUDP got error 99

The two time sync should not be necessary unless it is bugged.
The second sync is just to check if it is bugged or not.

2 Likes

You saved my day, doing this and Nuki smart lock added (that is the only device I have right now!

Hey, thanks for the input and sorry for the long delay. Life came in between. :smiley: I just wanted to mention that I did what you suggested and have also updated to HA core 2025.9.1 and HA OS 16.2 but I still have the same messages in the logs. But the devices works without issue, sometimes the become unavailable for a bit (which is annoying) but I’m not sure it is related.

You’re a legend, saved my week. I had the same issue and this solved it, thanks!!!

You’re a legend, that solved my issue, thank you !

THANK YOU! That did it for me too (2x renewing thread credentials in Android app). Didn’t even look in this corner of the config. Using an old Sonoff E stick to play with Matter/Thread and the new Ikea Matter devices I thought everything is looking good, but could not add anything. And all of this after spending hours on using a Echo4 as the thread router, which failed misserably. Completely abandonded Echo as thread router and tried the Sonoff. Sonoff is working now just fine.

Hey @WallyR,

Jumping into an older thread here, but you mentioned something here that caught my attention. I appear to have a working Thread installation, though I do see similar errors re: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ....

I do have HA multihomed, which is easy enough to disable, but I’d like to understand what the reason for this is and the impact. I have my network segmented to IoT devices with a different network policy, but it isn’t clear to me why that would impact my Matter-over-Thread devices.

Appreciate the insight here.

Just thinking it through, I could disable IPv6 on one of the interfaces on my HAOS host, but is this something that could be addressed in the software re: ensuring that the mDNS broadcasts are only sent on the appropriate interface? My read of this error message is that we’re trying to bind to a local address to send mDNS packets (I imagine on UDP:5353), but we’re conflicting with another service that’s also bound to this port? (Maybe I need to take this question upstream to the OTBR project.)

Thanks,
Ben

1 Like

I am not sure why it can not assign an address, unless the network is not actually set up at the time it tries to do it.

thank you so much! I have been bashing my head against the wall trying to get thread and matter to commission a device (Ikea push button bilresa with Sonoff MG24 flashed with thread firmware, OTBR ) and this step to sync credentials was the one thing that got it working.

Thanks again

“unless you really learn IPv6”
Just thinking out loud, are you referring to using fd00 next to fe80 and having the router forward mDNS packages across VLAN’s?

Currently I’m stuck trying to pair a Myggbett with HASS using OTBR and a ZBT-2, keep getting the error message saying I need to check if my phone is connected to wifi (wouldn’t be able to use the HASS app if it wasn’t) and that it cannot reach the device.

There are VLAN’s involved but the sync Thread-credentials under troubleshooting says “HASS and this device (Galaxy S20) are using the same network”. I also checked if forwarding mDNS works (on IPv4 with Chromecast yes), the packetcounters of the firewall rules (including the one for IPv6 mDNS) are increasing. Also added a rule to allow forwarding udp and tcp port 5540 between the VLAN’s.

Still no go, IPv6 internet access is a work in progress. my ISP offers it, but getting IPv4 alone (PPPoE over VLAN) to work was a pain in the arse on Debian.

HA, Matter server and phone needs to be on same IPv6 network.

And your router can not route mDNS unless it can run addons.
mDNS is using IPv6 packets that are not routable with standard IP routing.
If you think you are routing mDNS packets with standard IP routing, then you need to read up on IP routing again.

“And your router can not route mDNS unless it can run addons.”
The router is a computer running Debian :wink:

“If you think you are routing mDNS packets with standard IP routing, then you need to read up on IP routing again.”
Avahi-daemon is forwarding mDNS packets to other VLAN’s which (for example) makes ChromeCasts discoverable in other VLAN’s, thought it might work with this as well, though I haven’t tried with fd00-addresses yet.

Avahi daemon is an extra feature that is not a common thing for routers.
That is what I would call an addon.

This functionality being an addon aside, would forwarding mDNS requests to other VLAN’s (in theory) make linking Thread-sensors possible this way or is there more to it than that?

I don’t suppose anyone has a (Wireshark like) capture of the pairing process over the network?

With the security put into Matter you would probably not see anything usefull.
All is encrypted.

It would still let me see the used ports and protocols, that could give me a clue about what’s going on/wrong.

I would not really know where to start.
The way you pair a device with a mobile phone is by having the phone create a fake Thread network, join the new device and then join the fake Thread network with the HA network.

The problem with capturing the packets is how all these connections are made between the different parts. Some parts are on WiFi, some are on Ethernet cable, some are in a docker network and some packets might be needed from just the normal running of the network, which might have already been transmitted before the pairing process gets started.
On top of that it is required to capture both unicast, multicast and broadcast packets, which will probably mean a capture that are contaminated with lots of unnecessary packets.

You first step should probably be to up the lot level on the Matter and Thread integrations, but beware that if you choose restart on the popup that comes after you save the settings to the changes, then itoght actually not save the new settings.
Pressing cancel and then restarting it manually afterwards seems to work.

@WallyR I just tried adding it without using the Home Assistant app → How to use Home Assistant to add Matter devices without a phone | Matter Alpha No luck with that method either :confused:

edit: scratch that, got it. 2 things: Entering the pairing code without “-” and use a BT-adapter that has not been added (just discovered) to Home Assistant.