Release v3.1.1 — April 27, 2026

[jnilo1]

A small patch release on top of v3.1.0: friendlier flashing on routed networks, a safer flash_efr32.sh, one config key collapsed, and a round of UART-bridge hardening in the kernel. Upgrade is in-place — no manual config migration needed.

Backup and flash from any subnet (#88)

backup_gateway.sh and flash_install_rtl8196e.sh no longer demand that your host shares an L2 segment with 192.168.1.6 (the bootloader's hard-coded TFTP IP) just to do an SSH-only step. The L2 check now fires lazily, only at the moment it's actually needed (right before boothold, or in pure-bootloader mode), with an actionable hint:

sudo ip addr add 192.168.1.10/24 dev <iface>

If your gateway lives at 192.168.5.252 (or any routed address), ./backup_gateway.sh <gateway-IP> just works. The 192.168.1.x secondary IP is only needed for the flash phase itself, and only on the interface that already faces the gateway.

Reported by @skinkie.

flash_efr32.sh refuses to flash when the bridge is in use

If a TCP client already owns the in-kernel UART bridge (Z2M, ZHA, otbr-agent, …), the script now aborts with the peer's IP rather than silently kicking the existing client off the socket. Z2M wherever it lives — gateway, your laptop, a Pi, a NAS — /proc/net/tcp on the gateway sees them all.

radio.conf — one baud key

BRIDGE_BAUD and OTBR_BAUD are gone; FIRMWARE_BAUD is now the single source of truth, since both ends of a UART link must agree anyway. Existing v3.0.x / v3.1.0 configs keep working — the init scripts fall back to the legacy keys, and the next flash_efr32.sh run rewrites radio.conf cleanly.

OT-RCP three-case switching (ZoH / OTBR-host / OTBR-gateway) is simpler too: just add or remove MODE=otbr. No baud key to flip.

Kernel — UART-bridge hardening

Four correctness fixes in rtl8196e-uart-bridge (no operator-visible behaviour change in the normal path, but worth flagging for anyone tracking the driver):

• nrst_pulse no longer holds the global mutex across its 100 ms sleep — UART → TCP hot path stays responsive during EFR32 resets.
• status_led_brightness is now lock-protected like every other live-tunable param.
• TTY client_ops are saved/restored verbatim across arm/disarm (latent bug, fixed before any layered consumer like serdev could land between us and the port).
• Stale "hot path lives in IRAM" claims dropped from Kconfig and the late-initcall comment (placement was shelved long ago after measurement showed plain .text was sufficient at 892857 baud).

Upgrade

From v3.1.0 / v3.0.x — full upgrade over SSH:

./flash_install_rtl8196e.sh -y <gateway-IP>

Network, password, SSH keys, Thread credentials and radio.conf are preserved automatically. If your gateway is on a routed subnet, you can now run this without pre-adding a 192.168.1.x IP — the script will tell you when (and only when) it's actually needed.

Full changelogs

• RTL8196E platform CHANGELOG
• EFR32 firmware + tooling CHANGELOG

[olivluca]

After around 1 hour otbr stops working

I (re)started the gateway at 19:05 (the timezone is 2 hours off) in spite of these warning the gateway is visible in homeassistant

Apr 28 17:05:23 (none) user.warn otbr-agent[100]: [WARN]-UTILS---: /home/jnilo/hacking-lidl-silvercrest-gateway/3-Main-SoC-Realtek-RTL8196E/34-Userdata/ot-br-posix/ot-br-posix/src/rest/network_diag_handler.cpp:1300 lacking some attribue
Apr 28 17:05:24 (none) user.warn otbr-agent[100]: [WARN]-UTILS---: /home/jnilo/hacking-lidl-silvercrest-gateway/3-Main-SoC-Realtek-RTL8196E/34-Userdata/ot-br-posix/ot-br-posix/src/rest/network_diag_handler.cpp:1244 cannot get LeaderDatd
Apr 28 17:05:24 (none) user.warn otbr-agent[100]: [WARN]-UTILS---: /home/jnilo/hacking-lidl-silvercrest-gateway/3-Main-SoC-Realtek-RTL8196E/34-Userdata/ot-br-posix/ot-br-posix/src/rest/rest_devices_coll.cpp:232 - AddItem - 1a993f92be56e

then one hour later

Apr 28 18:01:10 (none) user.crit otbr-agent[100]: 00:55:46.878 [C] P-RadioSpinel-: Failed to communicate with RCP - no response from RCP during initialization
Apr 28 18:01:10 (none) user.crit otbr-agent[100]: 00:55:46.880 [C] P-RadioSpinel-: This is not a bug and typically due a config error (wrong URL parameters) or bad RCP image:
Apr 28 18:01:10 (none) user.crit otbr-agent[100]: 00:55:46.881 [C] P-RadioSpinel-: - Make sure RCP is running the correct firmware
Apr 28 18:01:10 (none) user.crit otbr-agent[100]: 00:55:46.882 [C] P-RadioSpinel-: - Double check the config parameters passed as `RadioURL` input
Apr 28 18:01:10 (none) user.crit otbr-agent[100]: 00:55:46.882 [C] Platform------: HandleRcpTimeout() at radio_spinel.cpp:2013: RadioSpinelNoResponse

restarting otbr works sometimes while other times a reboot is necessary, e.g. previously to the above I tried to restart otbr twice then I had to reboot:

Apr 28 17:03:58 (none) user.crit otbr-agent[1989]: 49d.19:56:17.964 [C] P-RadioSpinel-: RCP => [C] Platform------: Reset info: 0x3 (EXT)
Apr 28 17:03:58 (none) user.crit otbr-agent[1989]: 49d.19:56:17.966 [C] P-RadioSpinel-: RCP => [C] Platform------: Extended Reset info: 0x301 (PIN)
Apr 28 17:03:58 (none) user.warn otbr-agent[1989]: [WARN]-UTILS---: /home/jnilo/hacking-lidl-silvercrest-gateway/3-Main-SoC-Realtek-RTL8196E/34-Userdata/ot-br-posix/ot-br-posix/src/rest/network_diag_handler.cpp:1300 lacking some attrib4
Apr 28 17:03:58 (none) user.warn otbr-agent[1989]: [WARN]-UTILS---: /home/jnilo/hacking-lidl-silvercrest-gateway/3-Main-SoC-Realtek-RTL8196E/34-Userdata/ot-br-posix/ot-br-posix/src/rest/network_diag_handler.cpp:1244 cannot get LeaderDad
Apr 28 17:03:58 (none) user.warn otbr-agent[1989]: [WARN]-UTILS---: /home/jnilo/hacking-lidl-silvercrest-gateway/3-Main-SoC-Realtek-RTL8196E/34-Userdata/ot-br-posix/ot-br-posix/src/rest/rest_devices_Apr 28 17:03:58 (none) user.crit otbr-agent[1989]: 49d.19:56:17.964 [C] P-RadioSpinel-: RCP => [C] Platform------: Reset info: 0x3 (EXT)
Apr 28 17:03:58 (none) user.crit otbr-agent[1989]: 49d.19:56:17.966 [C] P-RadioSpinel-: RCP => [C] Platform------: Extended Reset info: 0x301 (PIN)
Apr 28 17:03:58 (none) user.warn otbr-agent[1989]: [WARN]-UTILS---: /home/jnilo/hacking-lidl-silvercrest-gateway/3-Main-SoC-Realtek-RTL8196E/34-Userdata/ot-br-posix/ot-br-posix/src/rest/network_diag_handler.cpp:1300 lacking some attrib4
Apr 28 17:03:58 (none) user.warn otbr-agent[1989]: [WARN]-UTILS---: /home/jnilo/hacking-lidl-silvercrest-gateway/3-Main-SoC-Realtek-RTL8196E/34-Userdata/ot-br-posix/ot-br-posix/src/rest/network_diag_handler.cpp:1244 cannot get LeaderDad
Apr 28 17:03:58 (none) user.warn otbr-agent[1989]: [WARN]-UTILS---: /home/jnilo/hacking-lidl-silvercrest-gateway/3-Main-SoC-Realtek-RTL8196E/34-Userdata/ot-br-posix/ot-br-posix/src/rest/rest_devices_coll.cpp:232 - AddItem - 1a993f92be5e
Apr 28 17:03:59 (none) user.warn otbr-agent[1989]: 00:00:01.921 [W] P-Daemon------: Failed to write CLI output: Broken pipe
Apr 28 17:04:26 (none) user.warn otbr-agent[1989]: 00:00:28.347 [W] P-HdlcIntface-: Error decoding hdlc frame: Parse
Apr 28 17:04:31 (none) user.warn otbr-agent[1989]: 00:00:33.337 [W] P-RadioSpinel-: radio tx timeout
Apr 28 17:04:31 (none) user.crit otbr-agent[1989]: 00:00:33.340 [C] P-RadioSpinel-: Failed to communicate with RCP - no response from RCP during initialization
Apr 28 17:04:31 (none) user.crit otbr-agent[1989]: 00:00:33.342 [C] P-RadioSpinel-: This is not a bug and typically due a config error (wrong URL parameters) or bad RCP image:
Apr 28 17:04:31 (none) user.crit otbr-agent[1989]: 00:00:33.343 [C] P-RadioSpinel-: - Make sure RCP is running the correct firmware
Apr 28 17:04:31 (none) user.crit otbr-agent[1989]: 00:00:33.344 [C] P-RadioSpinel-: - Double check the config parameters passed as `RadioURL` input
Apr 28 17:04:31 (none) user.crit otbr-agent[1989]: 00:00:33.346 [C] Platform------: HandleRcpTimeout() at radio_spinel.cpp:2013: RadioSpinelNoResponse
coll.cpp:232 - AddItem - 1a993f92be5e
Apr 28 17:03:59 (none) user.warn otbr-agent[1989]: 00:00:01.921 [W] P-Daemon------: Failed to write CLI output: Broken pipe
Apr 28 17:04:26 (none) user.warn otbr-agent[1989]: 00:00:28.347 [W] P-HdlcIntface-: Error decoding hdlc frame: Parse
Apr 28 17:04:31 (none) user.warn otbr-agent[1989]: 00:00:33.337 [W] P-RadioSpinel-: radio tx timeout
Apr 28 17:04:31 (none) user.crit otbr-agent[1989]: 00:00:33.340 [C] P-RadioSpinel-: Failed to communicate with RCP - no response from RCP during initialization
Apr 28 17:04:31 (none) user.crit otbr-agent[1989]: 00:00:33.342 [C] P-RadioSpinel-: This is not a bug and typically due a config error (wrong URL parameters) or bad RCP image:
Apr 28 17:04:31 (none) user.crit otbr-agent[1989]: 00:00:33.343 [C] P-RadioSpinel-: - Make sure RCP is running the correct firmware
Apr 28 17:04:31 (none) user.crit otbr-agent[1989]: 00:00:33.344 [C] P-RadioSpinel-: - Double check the config parameters passed as `RadioURL` input
Apr 28 17:04:31 (none) user.crit otbr-agent[1989]: 00:00:33.346 [C] Platform------: HandleRcpTimeout() at radio_spinel.cpp:2013: RadioSpinelNoResponse

[jnilo1]

Thanks for the bisection — swapping to NCP-UART-HW/115200 is exactly the right way to separate workload from hardware.

One thing on the silent console: that's expected, not a clue. The 6.18 kernel ships without CONFIG_SOFTLOCKUP_DETECTOR, CONFIG_DETECT_HUNG_TASK, CONFIG_PANIC_ON_OOPS, CONFIG_WATCHDOG or CONFIG_MAGIC_SYSRQ, and no watchdog driver is fed at runtime. So a kernel-level hang produces zero serial output by design — it doesn't rule out OTBR, it just means we can't see anything from there.

Worth keeping in mind: NCP-UART-HW vs OTBR is a large workload delta (no otbr-agent, no radvd, no ot-ctl, ~10–15 MB more free RAM, much less ttyS1 traffic), so identical hardware can behave very differently. If the NCP box stays up, that's strong evidence against a pure HW glitch but doesn't yet pinpoint which part of the OTBR stack is the trigger.

On my side I'm currently running OTBR with 15 paired devices on an unreleased v3.4.1 build, and after ~20h I haven't seen any stability issue so far. Different sample size from yours, but at least it's not a deterministic OTBR-on-this-hardware failure.

If you do get another hang before the NCP test concludes, the cheapest useful artefacts are: cat /proc/meminfo + free + top -b sampled every minute into /userdata/log/ (JFFS2, persistent — /var/log/messages is tmpfs and lost on reboot), and uptime at hang vs. anything that might correlate (RA cycle, sleepy-end-device wake, OTA, HA reconnect).

My current HA dashboard:

[olivluca]

When I was on 3.3.0 it took 3 days before hanging, I mean, it's totally random, and I have no devices in the thread network.
OTOH my main gateway managing my zigbee devices, still on 3.3.0, has been up 5 days (and that's beacause I flashed 3.3.0 5 days ago).
In any case if the rtl8196e has a hardware watchdog it could be a good idea to use it (as long there's a driver for it). A software watchdog would be probably useless.

[olivluca]

It's been up for 3 days now. If it lasts a couple more days I think I can exclude an hardware issue.

[olivluca]

After 5 days of uptime with the ncp/115200 firmware, yesterday I flashed 3.4.1 then the ot-rcp/460800 firmware and it lasted less than one day.
Now I flashed ot-rcp/115200 to see if it lasts longer.

[jnilo1]

Hi @olivluca . Sorry to learn that you are still experiencing problems with the ot-rcp/460800 setup. Mine has been working flawlessly for 5 days now with 15 matter devices attached to it. I am ready to help. Can I ask you to open an issue on your situation with all the relevant details and we will start from there ?
I am going to close this thread on the v3.1.1 release since I understand you are already on 3.4.1 ...

[olivluca]

Of course I'll let you know.
I can tell you that I have another gateway running v3.1.1 with the ncp firmware at 115200 and up until now has been stable (and I have zigbee devices joined to it).