SMLIGHT SLZB-06MG26U - OTBR IPv6 backbone forwarding breaks after every reboot (Thread + OTBR on device mode)

Configuration Matter/Thread
,
1

Hi,

I want to share a reproducible bug I found with the SMLIGHT SLZB-06MG26U in "Thread + OTBR running on device" mode, in case others are hitting the same wall — and to get visibility from anyone involved with the Thread integration.

Setup:

  • SLZB-06MG26U, SLZB-OS v3.3.3.dev4, Radio FW 20260416 (Thread BR)
  • HA 2026.6.3, dual-NIC (one NIC in IoT VLAN, one in home VLAN)
  • Thread network on Channel 26, Matter-over-Thread devices: IKEA GRILLPLATS socket + remote

The Bug:

After any SLZB reboot (software reboot, power cycle, or OTBR toggle in the SMLIGHT UI), the Thread mesh comes back up correctly — OTBR reports "leader", devices rejoin, REST API works — but IPv6 backbone forwarding is completely broken.

The OMR prefix (fdfe:f65f:6697:1::/64) is no longer advertised via Router Advertisement on the backbone Ethernet interface. Infrastructure hosts (including HA) lose the route, and even after manually re-adding it, OTBR does not forward packets. Matter-over-Thread devices become unreachable in HA.

Confirmed reproduction:

After reboot — ping to SLZB's own OMR address from HA:
ping6 -c3 -I enp0s19 fdfe:f65f:6697:1:61dd:a8f6:b818:6eed
→ 100% packet loss

After fresh radio firmware flash (NVM clear + reflash 20260416):
ping6 -c3 -I enp0s19 fdfe:f65f:6697:1:61dd:a8f6:b818:6eed
→ 0% packet loss, ~1ms RTT

This cycle reproduces 100% of the time. Fresh flash = works. Any reboot = broken.

Likely cause:

Looking at the boot log, OTBR initializes ~8 seconds after network up, but the SLAAC address (from backbone RA) arrives ~27 seconds after OTBR init. OTBR may be setting up backbone routing before the infrastructure prefix is known, resulting in a permanently broken state.

HA is not the cause — tested with HA core stopped, same result.

This appears to be the same class of bug that radio FW 20260416 was supposed to fix ("fix problems with OTBR starting after device reboot"), but the fix is incomplete — it doesn't cover all restart paths.

I have filed a detailed bug report with SMLIGHT on GitHub: OTBR IPv6 Backbone Forwarding Fails After Reboot (Thread + OTBR on Device Mode) · Issue #14 · smlight-tech/slzb-os-scripts · GitHub

Has anyone else seen this? And @agners or others involved in the Thread integration — is there anything on the HA side that could help work around this (e.g. triggering an OTBR re-init via REST API)?

2

First, Pinging people is a problem and doesn't get you any friends.

VLans combined with Matter are always going to be a hassle due to the IPv6 requirements.
Matter & Thread Deep Dive

3

Thanks for the feedback — fair point on the ping, noted.

On the VLAN/IPv6 point: I understand that combination often causes headaches, and I'd normally agree. But in this case the network config isn't the variable — the only thing that changes between working and broken state is whether the radio firmware was freshly flashed or not.

Same VLAN, same pfSense config, same HA setup, same Thread dataset. Fresh flash → ping6 0% loss, ~1ms RTT, devices online. Any subsequent reboot (no config change whatsoever) → 100% packet loss. Every single time.

The boot log shows OTBR initializing ~8s after network up, but the SLAAC address only arriving ~27s later. That timing gap is what I believe causes the broken state — OTBR sets up backbone routing before the infrastructure prefix is available, and never recovers. That's an initialization sequence issue in the firmware, not a VLAN routing issue.

I've also filed a ticket with SMLIGHT support directly (in addition to the GitHub issue) so they can look at it on their end.

4

I think there was a note about something like that in the latest HA core release.

I am not sure it is related, but it mentions something about extended addresses being lost when OTBR is restarted.