[Linux] Proper handling of BlueZ D-Bus service restart #30792
Labels
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
Reproduction steps
Problem
On Linux (and some other platforms) Bluetooth communication is provided via BlueZ which is a D-Bus service. It is possible that such external service will crash. In most cases BlueZ is governed by systemd, which will restart the service. Anyway, the application which communicates with BlueZ needs to properly handle such situation (e.g. the D-Bus ID of the services changes, so any cached objects need to be updated). Also, it is required to restart BLE advertisement and re-register GATT application.
Solution
In case of short BlueZ outage (few ms) the case is simple, we can reload BLE subsystem in the SDK and everything should work fine.
However, what should be done in case where BlueZ will be off-line for longer period or Bluetooth dongle is unplugged (in that case BlueZ is on-line, but there is no adapter available)? The simplest solution would be to crash Matter application since BLE functionality can not be provided. Alternatively, we can notify SDK core that BLE is not available, so every component which relies on BLE can return proper error (in case of controller, even user can be notified about such fact) and wait for the BLE subsystem to be back on-line. There is also case where BLE adapter is not available during Matter app startup, but might be available later.
Platform
raspi
Platform Version(s)
master
Type
Manually tested with SDK
(Optional) If manually tested please explain why this is only manually tested
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: