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.
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.
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.
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.