Your host's network stack
The fault is in the machine running Home Assistant -- or in the machine running that machine. Nothing inside Home Assistant can show you this.
mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb
What it means. The mDNS responder tried to send discovery traffic out of an interface that has no usable address for it. On a host with more than one network interface, the responder picks the one with the default route -- which is often not the one your devices are on.
What to do. Set the interface explicitly. This is the OpenThread Border Router add-on's 'Backbone Network Interface' option, not a Matter Server setting -- the Matter Server add-on has no interface option at all (verified against its config.yaml on 2026-09-20). Choose the interface your devices are actually on. In one documented case the cause was having Wi-Fi and Ethernet both active on a fresh install, and the fix was setting this option to end0.
Seen in: community.home-assistant.io/t/1010466 (2026-05-15)
ENETUNREACH
What it means. Your host has no route to the Thread mesh. In the thread this came from, the host was fine and the border router was at fault: it kept advertising the prefix from a previous dataset, so the route being announced was not the one the devices were on. The author's words: HAOS is ready to consume these routes out of the box, so if the route is not there, the border router is not advertising it correctly. A host-side cause is possible too -- forwarding on while accept_ra is not 2, or a kernel without accept_ra_rt_info_max_plen -- but check the border router first.
What to do. If you have ever renamed your Thread network or regenerated its dataset, suspect a stale prefix first. Compare the prefix your border router advertises against the one your devices actually use: tcpdump -i <iface> -vv 'icmp6 and ip6[40] == 134' -c 3. If they differ, that is your answer and no host setting will fix it. The pre-flight check below covers the host-side causes.
Seen in: community.home-assistant.io/t/1019472
Address unreachable after PASE
What it means. The initial pairing handshake worked and then the connection could not be established. This is the signature of IPv6 being unavailable on the host -- or, on a virtual machine, on the hypervisor underneath it. Matter has no IPv4 fallback.
What to do. Check IPv6 on the machine running Home Assistant AND on its host. One documented case had net.ipv6.conf.all.disable_ipv6=1 set in /etc/sysctl.d/99-proxmox.conf on the Proxmox host; the VM inherited it and nothing inside Home Assistant could show it.
Seen in: community.home-assistant.io/t/1013449 (2026-06-10)
Checking connectivity to Thread network
What it means. Commissioning reaches this step and stops. In documented cases the container running Home Assistant had no IPv6 address at all, while the Thread network, the radio and the device were all healthy.
What to do. On Home Assistant OS or Supervised, run: ha docker options --enable-ipv6=true and restart. Then re-run the pre-flight check rather than trusting the command's success message -- one documented case reported enable_ipv6 as true while forwarding was still 0. One case also needed a USB Bluetooth dongle so the phone could commission over BLE instead.
Seen in: community.home-assistant.io/t/1006775 (2026-04-24), t/1020295 (2026-08-07)
OS Error 0x02000013: No such device
What it means. A socket operation was attempted on an interface that does not exist from the perspective of that process. Usually an interface name that changed, or a container that cannot see the host's interfaces.
What to do. Confirm the interface named in your Matter Server configuration still exists and is up. Interface names change when hardware is added or the host is virtualised.
Seen in: community.home-assistant.io/t/1010466 (2026-05-15)
addresses=[b'\xc0\xa8...']
What it means. The discovered address list contains an IPv4 address (\xc0\xa8 is 192.168) and no IPv6 address. Matter operates over IPv6 on the local link, so there is nothing usable here.
What to do. This is the same root cause as ENETUNREACH: no IPv6 route to the device. Run the pre-flight check below. If a Thread border router runs on this same machine, check IPv6 forwarding specifically -- one thread with this exact symptom is titled 'SOLVED - It was IPv6 forwarding'.
Seen in: community.home-assistant.io/t/953420 (2025-11-20)
Your local network
The fault is between devices: a switch, a router, VLAN separation, or multicast handling.
Discovery timed out
What it means. Multicast discovery never reached the device or never came back. Matter discovery uses link-local multicast, which by design does not cross network segments.
What to do. First check that unique-local addresses are routable between your Home Assistant host, your border router and your devices -- one person reported fc00::/7 not being routed as the thing that fixed it for them. Then check client isolation on the Wi-Fi and IGMP/MLD snooping on a managed switch. If your devices sit on a different VLAN from Home Assistant, note that link-local multicast is not designed to cross segments, so that part is working as intended even though it is inconvenient.
Seen in: community.home-assistant.io/t/990934 (2026-02-26), t/750324
The Thread radio or border router
The fault is in the radio hardware, its firmware, or the border router role.
Thread Border Router Required
What it means. The phone doing the commissioning cannot find a Thread border router it is allowed to use. This message has two quite different causes and the wording does not distinguish them: either the phone has no credentials for your mesh, or it has them and still cannot use the mesh. One thread shows the second shape clearly -- credentials synced, border router visible in the Thread panel, _meshcop._udp discoverable, and the error anyway. Nobody has established why. That thread is on iOS and has no replies, so treat the second case as an open question rather than a diagnosis.
What to do. First rule out the credential case, because it is the one with a known fix. On Android: Home Assistant Companion app > Settings > Companion app > Troubleshooting > Sync Thread credentials. On iOS the phone must reach a Thread-enabled Apple device. If you have already done that and still see this, you are in the second case, and honestly nobody has published a root cause for it. The pre-flight check below at least tells you whether your host can reach the mesh, which narrows it.
Seen in: community.home-assistant.io/t/1015572 (2026-06-29) — iOS, zero replies, no root cause established; credential fix from t/1013258
NoAck / SRP server DNS drop
What it means. Nobody has established the root cause of this one. What the log does tell you is the layer: NoAck on port 19788 is an 802.15.4 radio-layer message -- the border router transmitted to the device over the radio and got no acknowledgement. Your host's IPv6 settings cannot cause this, so if you have been changing those, you have been looking in the wrong place.
What to do. Treat this as a radio-layer problem, not a network one. Things worth trying, none of them confirmed to fix this particular failure: move the radio away from USB 3.0 ports and hubs using an extension cable, check whether more than one border router is advertising, and check for radio firmware updates. The thread this came from has three replies and no answer, so if you solve it, posting back is worth more than anything we can tell you.
Seen in: community.home-assistant.io/t/1015977 (2026-07-03) — three replies, no accepted answer as of 2026-09-20
The instructions are wrong
You followed a documented step and the documented step is incorrect.
Device '/dev/ttyS3' does not exist
What it means. You followed the official OpenThread Border Router add-on documentation, which tells you to set a dummy serial port of /dev/ttyS3 when using a network-attached radio. On most hosts that device does not exist and the add-on will not start. You did not do anything wrong.
What to do. On a Raspberry Pi 4 the fix reported by users is to uncomment enable_uart=1 in config.txt, which makes the port exist. Otherwise pick any tty that does exist on your host. This documentation line has been incorrect since at least April 2025 and, as of 2026-09-20, is still live.
Seen in: github.com/home-assistant/addons OpenThread DOCS.md, quote verified live 2026-09-20; community thread t/876769 (2025-04-12)