Skip to content

feat(bluetooth): disable BLE pairing on the daemon adapter#1076

Closed
tfrere wants to merge 1 commit into
mobile-app-integration-lightfrom
light/feat-ble-no-pairing
Closed

feat(bluetooth): disable BLE pairing on the daemon adapter#1076
tfrere wants to merge 1 commit into
mobile-app-integration-lightfrom
light/feat-ble-no-pairing

Conversation

@tfrere
Copy link
Copy Markdown
Contributor

@tfrere tfrere commented May 4, 2026

Summary

Stacked on top of #1069 (mobile-app-integration-light). Carve-out from the umbrella draft #1070.

Every GATT characteristic exposed by the daemon (commands, responses, install_id, network status) is intentionally unencrypted because the information it carries is also broadcast in the BLE advertisement manufacturer data. There is therefore no security benefit in having the adapter accept SMP pairing requests, and the only user-visible side-effect of being pairable was an iOS / Android "Pair this accessory?" prompt the first time the mobile app connected.

This PR drops the NoInputNoOutput Just Works agent registration and sets the adapter to Pairable=False so the mobile OS no longer surfaces a pairing dialog. The NoInputAgent class itself is kept in the module for reference in case a future encrypted-write characteristic warrants re-enabling bonding.

Also includes a new diagnostic note at docs/known-issues/libnice-session-reuse-crash.md capturing the libnice session-reuse abort observed on the central / Wi-Fi WebRTC path - independent of pairing, but written up at the same time so the investigation is not lost.

Files

  • src/reachy_mini/daemon/app/services/bluetooth/bluetooth_service.py (+22 / -10): drop agent registration, set Pairable=False, update module docstring.
  • docs/known-issues/libnice-session-reuse-crash.md (NEW, +107): diagnostic write-up of an unrelated WebRTC libnice issue, documented for future debugging.

Test plan

  • First-time BLE connect from iOS: no "Pair this accessory?" system dialog appears.
  • First-time BLE connect from Android: same, no pairing prompt.
  • GATT read/write on existing characteristics (commands, responses, network status, install_id, robot_name) still works without pairing.
  • bluetoothctl show on the daemon's adapter reports Pairable: no.
  • No regression in BLE provisioning flow (WIFI_STATUS, WIFI_SCAN, WIFI_CONNECT).

Notes

  • Cherry-picked from 2958b079 on dev/mobile-app-integration. No conflicts.
  • The libnice doc is bundled because it was authored in the same commit upstream and is read-only documentation; if reviewers prefer it as a separate PR, happy to split.

Made with Cursor

Every GATT characteristic exposed by the daemon (commands, responses,
install_id, network status) is intentionally unencrypted because the
information they carry is also broadcast in the BLE advertisement
manufacturer data. There is therefore no security benefit in having
the adapter accept SMP pairing requests, and the only user-visible
side-effect of being pairable was an iOS / Android "Pair this
accessory?" prompt the first time the mobile app connected.

Drop the NoInputNoOutput Just Works agent registration and set the
adapter to Pairable=False so the mobile OS no longer surfaces a
pairing dialog. The NoInputAgent class is kept in the module for
reference in case a future encrypted-write characteristic warrants
re-enabling bonding.

Also document the libnice session-reuse abort observed on the
central / Wi-Fi WebRTC path under
docs/known-issues/libnice-session-reuse-crash.md so the diagnostic
work is not lost while we deal with it later.

Made-with: Cursor
@HuggingFaceDocBuilderDev
Copy link
Copy Markdown

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@tfrere
Copy link
Copy Markdown
Contributor Author

tfrere commented May 5, 2026

Closing for cleanup. Branch light/feat-ble-no-pairing remains on remote, can be reopened against mobile-app-integration-light if/when we want to ship BLE pairing hardening.

@tfrere tfrere closed this May 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants