Bluetooth need "network_mode:host" to be visible in container

Product support balenaOS
1

Hi!
Superviser version : 10.6.27
Host Os version : balenaOS 2.47.0+rev1
Board : Raspberry pi 3 B 1.2
Bluetooth device : on-board Bluetooth or a simple Bluetooth dongle

I’ve been facing this problem for a week now where I want to have a beacon scanner in a node-red container and the Bluetooth device(s) that i use are not visible inside my container but they are visible from the host.

The label “[…].dbus” : 1
I have the “DBUS_SYSTEM_BUS_ADDRESS” inside the docker-compose and my dockerfile set up
The container is privileged

To know if I see my devices, I log onto the host and the container and I use the command “hcitool dev” that list the MAC of my device.
On the host, i see :

Devices:
    hci0    DE:AD:BE:EF:00:00

But the same operation in container return :

Devices:

To workaround this problem, i found that I could add "network_mode: “host” " to my docker-compose file. This solve this issue but this is not a viable solution for me as I need the network between my containers to still work.

On the container, i now see :

Devices:
    hci0    DE:AD:BE:EF:00:00

To validate my finding, I use node-red and a beacon scanner node, when the network mode is host, i got data, if network_mode is commented, the node doesn’t work.

The problem I see is that I shouldn’t need to change the network mode to be able to see my Bluetooth devices

This is the stripped down version of my docker-compose and dockerfile that i use to test this. normally, I got other container with that.

DockerCompose:

version: “2.1”
services:
local_mqtt:
environment:
- BROKER_IP=changeme
build: ./local_mqtt
ports:
- 1883:1883

bluetooth:
build: ./bluetooth
privileged: true
labels:
io.balena.features.dbus: 1
network_mode: “host”
# devices:
# - /var/run/dbus:/var/run/dbus
environment:
- “DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket”
ports:
- 1880:1880

Dockerfile

FROM balenalib/%%BALENA_MACHINE_NAME%%-debian-node:12.7-build
ENV DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket
#Update the image and dependencies
RUN apt-get update
RUN apt-get install -y python-rpi.gpio
RUN apt-get install bluetooth bluez libbluetooth-dev libudev-dev
RUN setcap cap_net_raw+eip $(eval readlink -f which node)
.### Upload the node-red flows, settings and install packages
…
CMD [“npm”, “start”]

5

Hi,
hcitool dev will not use dbus to look for the adapter, could you please check whether the adapter is listed in the output of bluetoothctl list?

7

Using this command give me my device MAC,
So we can conclude that the device is visible to the container but either with my nodes like ‘node-red-contrib-beacon-scanner’ or with python lib like pybluez, both use hci (I think).

pybluez give me this error :

device_id = _bt.hci_get_route()
OSError: [Errno 97] Address family not supported by protocol’

and the node give me this one :

EAFNOSUPPORT, Address family not supported by protocol

15

Hey,
The container has to use network_mode: host in the docker-compose file to use BT over hci. It also breaks communications with other containers.
Have you tried to set the other containers to host mode so they can communicate?
I’ll ask some teammates to see if there is another way to do that.

18

Hi @MTolba,
If you do find an alternative, it would be nice but to answer your question, yes it does, (just need to put everything in localhost). but it would be nice if I could have a bridge of some sort so I could still isolate my other containers.

@everybody who stumble across this;
To access bluetooth over HCI we need network_mode = host in a composed setup.

Network mode
Setting network_mode to host allows the container to share the same network namespace as the host OS. When this is set, any ports exposed on the container will be exposed locally on the device. This is necessary for features such as bluetooth.

Here is a list of post from across internet over the same issue :
Balena_Linked_issue
StackOverflow_issue
Github_issue
So I don’t think we can bybass this problem

Possible solution with bluetoothctl : here

19

Hi there – thanks for the additional info. Let us know if bluetoothctl works for you – it would be interesting to see if it can serve as a workaround in this situation.

All the best,
Hugh