openthread-br: locate the RCP dongle through otbr-rcp

[LorbusChris]

Should land after #30091, whose commits this branch includes until it merges; the change here is the last commit only.

The protocol handler required a hand-written radio_url, so pointing the border router at its dongle meant knowing which ttyACM the kernel had picked, and a replug that renumbered the device broke the interface until someone edited the config.

Bring over the otbr-rcp wrapper from the matter-openwrt packaging: when no radio_url is set, the handler resolves the dongle by its USB properties (a cdc_acm interface on a device whose product string names OpenThread), with an rcp option to pin a bus position or a fixed serial device, and optional firmware install and update through handler plugins. Discovery runs in the setup phase rather than under the launched command, since a flash can take minutes and must not race the bounded wait for the agent's ubus object.

A missing dongle fails setup with the restart block every failure needs, netifd retrying immediately and without backoff otherwise. The USB hotplug handler brings such interfaces up again when a device binds, keyed on the recorded RCP_NOT_FOUND error so interfaces an administrator took down on purpose stay down. An explicit radio_url keeps today's behaviour and overrides all of this.

option	meaning
rcp '/dev/ttyACM0'	fixed serial device, no discovery
rcp '2-1'	USB bus position, resolved to whatever serial device it currently exposes
rcp 'any' (default)	pick a dongle by its USB product string
uart_baudrate, uart_flow_control	appended to the resulting URL
rcp_firmware_update	run firmware handler plugins when one recognises the device (none ship with this package)

The wrapper's canonical home is project-chip/matter-openwrt, where its selection invariants are under review in project-chip/matter-openwrt#57; this copy mirrors that state and follows it. The same commit ships in the Turris OS packaging of this package. A LuCI follow-up exposing these options exists and opens once this lands (branch).

Testing

Package builds in the openwrt SDK (x86_64) with the full patch stack; both shell files pass sh -n. The identical commit runs on Turris Omnia hardware via the Turris OS packaging.

[openwrt]

Formality Check: Suggestions Available

We checked this pull request against the contribution guidelines. Here is what needs your attention:

⚠️ STYLISTIC WARNINGS & SUGGESTIONS

Package Release Audit:

• ⚠️ Package net/openthread-br version updated from '2f3c799c7463c8f674754e65c53f78bc0bbcbd58' to '2026.08.0', but PKG_RELEASE was not reset to 1 (currently: '2')

---

_{Something broken? Consider reporting an issue.
Running version 0e15d1c deployed on 2026-08-12 22:36:32 CEST}

[openwrt-ai]

Reviewed the four commits on this branch; the notes below are all on the last one (896a913), since the first three are #30091's. All four commit messages match what their diffs actually do.

Nothing here looks like a merge blocker. The two worth a decision before merge are the rcp_firmware_update default, which is opt-out in the code but documented as opt-in and now reachable from configs that never mentioned an RCP at all, and the eval of otbr-rcp stdout, which hands the documented firmware-handler plugin API a root shell in netifd's proto handler. The uart_flow_control default is a question rather than a finding. The rest are a doc/behaviour mismatch and two nits.

PKG_RELEASE is left to the formality bot.

---

Generated by Claude Code