How to Run Containerized Bluetooth Applications With BlueZ

Fleeting

• External reference: https://medium.com/omi-uulm/how-to-run-containerized-bluetooth-applications-with-bluez-dced9ab767f6

How to run containerized Bluetooth applications with BlueZ

docker, bluetooth

In short this is not simple, because it needs:

1. the bluetooth device not to already be handled by the host
2. the user to have rights to run dbus, hence root priviledges
3. the container to access NET_ADMIN priviledges
4. to manually wait for the bluez service to have started, without much help from the service manager

— https://medium.com/omi-uulm/how-to-run-containerized-bluetooth-applications-with-bluez-dced9ab767f6

BlueZ runs in a process called bluetoothd. It mounts the Bluetooth adapter(s) using the Host Controller Interface (HCI), in most cases the adapter hci0, which is the default one of a Bluetooth-capable device with a single adapter.

— https://medium.com/omi-uulm/how-to-run-containerized-bluetooth-applications-with-bluez-dced9ab767f6

Applications can communicate with bluetoothdusing the interprocess message bus D-Bus, more precisely, the system D-Bus:

— https://medium.com/omi-uulm/how-to-run-containerized-bluetooth-applications-with-bluez-dced9ab767f6

goal is to containerize our nodejs app and include all necessary services like BlueZ and D-Bus in the container

— https://medium.com/omi-uulm/how-to-run-containerized-bluetooth-applications-with-bluez-dced9ab767f6

container does not automatically start the necessary services like dbus and bluetooth, they need to be started manually before launching the application

— https://medium.com/omi-uulm/how-to-run-containerized-bluetooth-applications-with-bluez-dced9ab767f6

container needs to be able to directly communicate with the Bluetooth adapter, which is handled as a network interfacethe container needs to be able control the adapter administratively

— https://medium.com/omi-uulm/how-to-run-containerized-bluetooth-applications-with-bluez-dced9ab767f6

–net=host –privileged

— https://medium.com/omi-uulm/how-to-run-containerized-bluetooth-applications-with-bluez-dced9ab767f6

need to make sure is that no application owning the Bluetooth adapter we intend to use is running on the host. For example, if the bluetoothd service is active, the adapter will not be visible to the container, as it is already owned by a process.

— https://medium.com/omi-uulm/how-to-run-containerized-bluetooth-applications-with-bluez-dced9ab767f6

Starting the dbus service requires super-user rights, as does communication to the bluetoothd process, which utilizes the system D-Bus.

— https://medium.com/omi-uulm/how-to-run-containerized-bluetooth-applications-with-bluez-dced9ab767f6

D-Bus allows us to configure the rights that each individual user has by placing a *.conf file in etc/dbus-1/system.d

— https://medium.com/omi-uulm/how-to-run-containerized-bluetooth-applications-with-bluez-dced9ab767f6

bluez service, which in some cases took unreasonably long to start.

— https://medium.com/omi-uulm/how-to-run-containerized-bluetooth-applications-with-bluez-dced9ab767f6

Bluetooth adapter is a network adapter. If we look at the list of privileges a container can receive, we can see that the NET_ADMIN capability allows it to “Perform various network-related operations.” — just what we need.

— https://medium.com/omi-uulm/how-to-run-containerized-bluetooth-applications-with-bluez-dced9ab767f6

replacing the –privileged flag with the –cap-add=NET_ADMIN start option:

— https://medium.com/omi-uulm/how-to-run-containerized-bluetooth-applications-with-bluez-dced9ab767f6

Permalink