After updating balena OS, bluetoothctl can not be used

When updating to Balena OS v2.38.0 of raspberry pi3, Bluetooth dongle can not be used as a controller with bluetoothctl at service of multicontainer application.
Originally, v2.32.0 was able to use with bluetoothctl.
I believe the following changes in BalenaOS are affecting, but I’m not sure.

docker-compose.yml

version: '2'
volumes:
  resin-data:
services:
  service1:
    build: ./service1
    labels:
      io.balena.features.kernel-modules: '1'
      io.balena.features.firmware: '1'
      io.balena.features.dbus: '1'
    privileged: true
    network_mode: host
  service2:
    build: ./service2
    depends_on:
      - service1
    labels:
      io.balena.features.balena-socket: '1'
      io.balena.features.kernel-modules: '1'
      io.balena.features.firmware: '1'
      io.balena.features.dbus: '1'
      io.balena.features.supervisor-api: '1'
    privileged: true
    network_mode: host
    volumes: 
      - 'resin-data:/var/lib/bluetooth'

How can I use bluetoothctl?

1 Like

Hi there,

Thanks for getting in touch. We’d like to try and determine exactly what may be causing this, and have determined there was a Bluetooth change post v2.36.0. Could you please try version v2.36.0+rev2 on your device and see if this works or not. This will help us narrow down what may be happening.

Best regards, Heds

2 Likes

Thank you for your reply. I tried it with Balena OS v2.36.0, but I could not use bluetoothctl.

I think that the cause is that the host OS’s systemd bluetooth service grabs the Bluetooth dongle attached to the device.

I want to know how to get the container’s bluetooth service, not the Host OS.

Thanks for the extra details. We have passed this internally and will get back to you soon.

2 Likes

Hi, we’d like to try and reproduce this issue internally. Would you be able to provide a minimal reproduction of the issue, perhaps as a public GitHub repo or something similar?

Sorry, for delay.
I am a colleague of t.higashi. I will answer instead.
We apologize for not showing git repo.
But We provide as much information as possible.

Our Docker baseimage is resin/raspberrypi3-buildpack-deps:stretch.
And, Such code is written in Dockerfile of the container in the top question, we need to install bluez.

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
      bluez \

We will try to do Bluetooth pairing with bluetoothctl command with some option in the container.
And the following differences are seen by OS.

balenaOS 2.32 or less

  • Bluetoothctl is started on the container and the pairing information is displayed.
  • Pairing information is output to /var/lib/bluetooth on the container side.
  • The pairing information is not output to /var/lib/bluetooth on the host side.

balenaOS 2.36.0 + rev2 or more

  • Bluetoothctl starts on the container, but the pairing information is not displayed.
  • Pairing information is not output to /var/lib/bluetooth on the container side.
  • The pairing information is output to /var/lib/bluetooth on the host side.

Hi,
I just tried to reproduce the problem on our side.
I used the following Dockerfile as a simple test case.

FROM resin/raspberrypi3-buildpack-deps:stretch

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
      bluez

ENTRYPOINT [ "/bin/bash" ]

When running DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket bluetoothctl in the resulting container and in the interactive shell the commands scan on + connect <ADDRESS> + pair <ADDRESS> works just fine on balenaOS 2.38.0+rev1. Also info <ADDRESS> works fine. The /var/lib/bluetooth folder in the container is not populated.

I tried the same procedure with the same Dockerfile on balenaOS 2.32.0+rev1 and it was the exact same behaviour. There is no /var/lib/bluetooth folder in the container, but bluetoothctl works just fine.

bluetoothctl communicates via DBUS with the host OS daemon, and the host OS daemon stores it’s state in /var/lib/bluetooth you should not install or run your own bluetooth daemon in the container.

I’m afraid without a concrete example that reproduces your issue, we won’t be able to help you. We don’t need to see your application code, just the smallest possible example, that reproduces this issue.

I hope this helps.

Sorry, for delay.
It was solved by setting the following.
DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket

Thank you.