build(docker): Add thread radio support in docker#201
build(docker): Add thread radio support in docker#201Lakshmi97-velampati wants to merge 6 commits intomainfrom
Conversation
Add an optional otbr-radio Docker container that connects a Silicon Labs BRD2703 xG24 Explorer Kit to the Barton devcontainer via D-Bus, enabling Thread integration testing with real hardware. - Dockerfile.otbr-radio: builds image with cpcd and otbr-agent compiled for CPC transport; uses the URL spinel+cpc://cpcd_0?iid=1&iid-list=0 to handle both unicast and broadcast Spinel frames - compose.otbr-radio.yaml: compose overlay that shares a D-Bus socket volume with the barton service and maps RADIO_DEVICE at the same path on both the host and container sides - otbr-radio-entrypoint.sh: writes a fresh cpcd config on every start (uart_device_file, uart_hardflow: true), waits for "Daemon startup was successful" before launching otbr-agent, and auto-detects BACKBONE_IF from the host default route at runtime - setupDockerEnv.sh: auto-detects the backbone interface via ip route and writes it to docker/.env; Refs: BARTON-359 Signed-off-by: mvelam850 <munilakshmi_velampati@comcast.com>
There was a problem hiding this comment.
Pull request overview
Adds an optional “real USB radio” Thread Border Router path for Barton’s Docker-based dev environment by introducing an otbr-radio sidecar container (cpcd + otbr-agent) that shares a D-Bus socket volume with the main barton container, enabling Thread integration testing against real BRD2703 hardware.
Changes:
- Add an
otbr-radioDocker image + entrypoint that brings up D-Bus, Avahi, cpcd, then otbr-agent over CPC (spinel+cpc://). - Add a Compose overlay to run
otbr-radiowith host networking/privileges and share/var/run/dbuswithbarton. - Extend tooling/docs:
dockerw -Tflag,.envvariables (RADIO_DEVICE,BACKBONE_IF), and setup instructions.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| docs/THREAD_BORDER_ROUTER_SUPPORT.md | Adds end-to-end documentation for simulated vs real-radio Thread setup, including USB-IP guidance. |
| dockerw | Adds -T flag to include the OTBR radio compose overlay and start the otbr-radio service. |
| docker/setupDockerEnv.sh | Writes optional RADIO_DEVICE and BACKBONE_IF into docker/.env, with backbone IF auto-detection. |
| docker/README.md | Documents the new compose overlay and the -T flag. |
| docker/otbr-radio-entrypoint.sh | New entrypoint that orchestrates D-Bus, Avahi, cpcd, and otbr-agent startup for CPC-based RCP. |
| docker/Dockerfile.otbr-radio | New build for cpcd + otbr-agent (Silabs GSDK transport/CPC) and D-Bus policy. |
| docker/compose.otbr-radio.yaml | New compose overlay that runs otbr-radio privileged with host networking and shares D-Bus socket volume with barton. |
kfundecmcsa
left a comment
There was a problem hiding this comment.
I have a couple open questions, but requesting changes for the title. This effort should fall into the build commit type, not feat
Updated |
|
Be sure to take this PR out of draft when you are ready for re-review. |
Agent-Logs-Url: https://github.com/rdkcentral/BartonCore/sessions/20251167-75e5-411a-b21e-5827b40fcf35 Co-authored-by: Lakshmi97-velampati <190572788+Lakshmi97-velampati@users.noreply.github.com>
|
@cleithner-comcast and @kfundecmcsa : you have comments that are still open. Please review the responses/changes and mark them resolved if satisfied. |
@tleacmcsa yes, you can try this. |
|
Marked comments resolved |
| if [ ${#OTBR_RADIO_COMPOSE[@]} -gt 0 ]; then | ||
| notice "Starting otbr-radio container (cpcd + otbr-agent)..." | ||
| docker compose -f "${COMPOSE_FILE}" "${OTBR_RADIO_COMPOSE[@]}" up -d otbr-radio | ||
| notice "otbr-radio container started in the background." | ||
| EXTRA_ENV="${EXTRA_ENV} -e DBUS_SYSTEM_BUS_ADDRESS=unix:path=/var/run/otbr-dbus/system_bus_socket" | ||
| fi |
There was a problem hiding this comment.
dockerw -T unconditionally injects DBUS_SYSTEM_BUS_ADDRESS after docker compose ... up -d otbr-radio, but up -d can succeed even if otbr-radio immediately exits (e.g., missing/invalid RADIO_DEVICE). In that case the Barton container will be pointed at a private socket that may be stale/unserved, leading to confusing connection failures/timeouts. Consider verifying otbr-radio is running/healthy (or that the private D-Bus socket is accepting connections) before exporting the env var and launching the Barton container, and fail fast with a clear message if the radio container didn’t start correctly.
| echo "[otbr-radio] Starting private D-Bus system bus at ${DBUS_SYSTEM_BUS_ADDRESS}..." | ||
| mkdir -p "${DBUS_DIR}" | ||
| if [ -S "${DBUS_SOCKET_PATH}" ]; then | ||
| echo "[otbr-radio] Removing stale D-Bus socket ${DBUS_SOCKET_PATH}..." | ||
| rm -f "${DBUS_SOCKET_PATH}" | ||
| fi | ||
| dbus-daemon --system --fork --nopidfile --address="${DBUS_SYSTEM_BUS_ADDRESS}" | ||
| echo "[otbr-radio] Private D-Bus started." |
There was a problem hiding this comment.
The private dbus-daemon is started (and creates ${DBUS_SOCKET_PATH} in the shared volume) before validating RADIO_DEVICE. If validation fails and the container exits, the socket file can remain in the volume even though no daemon is serving it, which can cause clients to try to connect to a dead bus. Consider validating RADIO_DEVICE (and other required preconditions) before starting D-Bus, and/or adding a trap to remove ${DBUS_SOCKET_PATH} on early exit/shutdown.
Add an optional otbr-radio Docker container that connects a Silicon Labs BRD2703 xG24 Explorer Kit to the Barton devcontainer via D-Bus, enabling Thread integration testing with real hardware.
Refs: BARTON-359