moby: Bluetooth socket can't be opened inside container

Is there any way to access the bluetooth hardware without --net=host?

It seems that the linux kernel currently does not allow containers to create bluetooth sockets (see this kernel patch for more info https://patchwork.kernel.org/patch/9898285/).

One workaround would be to switch bluetooth processes inside the containers back to the host net namespace without impacting the rest of the containers processes (eg. sshd).

To do that:

1. bind mount /proc/1/ns/net inside the container

docker run --mount type=bind,source=/proc/1/ns/,target=/rootns my/image

1. Inside the container, use nsenter to bring some processes back to the root net namespace

nsenter --net=/rootns/net my/bluetooth/process args

or alternatively, LD_PRELOAD the following shared object before executing bluetooth processes inside the container

#define _GNU_SOURCE

#include <errno.h>
#include <fcntl.h>
#include <linux/limits.h>
#include <sched.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>

int netns_fd;

__attribute__((constructor))
static void netns_enter() {
	int ret;
	const char *message;
	char *netns_path = getenv("NETNS_ENTER");
	if (!netns_path) {
		message = "NETNS_ENTER is not set\n";
		goto error;
	}
	netns_fd = open(netns_path, O_RDONLY);
	if (netns_fd < 0) {
		message = strerror(errno);
		goto error;
	}
	ret = setns(netns_fd, CLONE_NEWNET);
	return;
error:
	write(1, message, strlen(message));
}

__attribute__((destructor))
static void netns_leave() {
	close(netns_fd);
}

gcc -fPIC -shared -Wl,-soname,netns_enter.so netns_enter.c -o netns_enter.so
LD_PRELOAD=$(pwd)/netns_enter.so NETNS_ENTER=/rootns/net /bluetooth/process/path args

This way you can still use docker port binding for non bluetooth processes inside the container. Pitfall : if the bluetooth process tries to bind to some port it would do so in the host net namespace (as if --net=host was used to start the container).

Hi there,

I needed to get Bluetooth LE working inside a container and I managed to get it up and running with the following container opts: docker run -ti --privileged --net=host debian:jessie --name bletest /bin/bash

Then a small example:

# apt-get update && apt-get install -y bluez bluetooth usbutils
[...]
# service dbus start
[ ok ] Starting system message bus: dbus.
# service dbus status
[ ok ] dbus is running.
# hciconfig hci0
hci0:   Type: BR/EDR  Bus: USB
        BD Address: 00:1A:DE:AD:BE:EF  ACL MTU: 310:10  SCO MTU: 64:8
        DOWN
        RX bytes:0 acl:0 sco:0 events:0 errors:0
        TX bytes:0 acl:0 sco:0 commands:0 errors:0
# hciconfig hci0 up
# hciconfig hci0
hci0:   Type: BR/EDR  Bus: USB
        BD Address: 00:1A:DE:AD:BE:EF  ACL MTU: 310:10  SCO MTU: 64:8
        UP RUNNING PSCAN
        RX bytes:0 acl:0 sco:0 events:0 errors:0
        TX bytes:0 acl:0 sco:0 commands:0 errors:0
# hcitool lescan
LE Scan ...
BC:6A:DE:AD:BE:EF (unknown)
BC:6A:DE:AD:BE:EF LeDevice
BC:6A:DE:AD:BE:EF (unknown)
BC:6A:DE:AD:BE:EF LeDevice
BC:6A:DE:AD:BE:EF (unknown)
^C
# bluetoothd -dn
bluetoothd[209]: Bluetooth daemon 5.23
bluetoothd[209]: src/main.c:parse_config() parsing main.conf
bluetoothd[209]: src/main.c:parse_config() Key file does not have key 'DiscoverableTimeout'
bluetoothd[209]: src/main.c:parse_config() Key file does not have key 'PairableTimeout'
bluetoothd[209]: src/main.c:parse_config() Key file does not have key 'AutoConnectTimeout'
bluetoothd[209]: src/main.c:parse_config() Key file does not have key 'Name'
bluetoothd[209]: src/main.c:parse_config() Key file does not have key 'Class'
bluetoothd[209]: src/main.c:parse_config() Key file does not have key 'DeviceID'
bluetoothd[209]: src/main.c:parse_config() Key file does not have key 'ReverseServiceDiscovery'
bluetoothd[209]: src/gatt.c:gatt_init() Starting GATT server
bluetoothd[209]: src/adapter.c:adapter_init() sending read version command
bluetoothd[209]: Starting SDP server
bluetoothd[209]: src/sdpd-service.c:register_device_id() Adding device id record for 00......
[...]

And here bluetoothd seems to be happy…

I am trying to figure out why the --net=host is needed here. I could understand that the container need --privileged rights, but not to be connected to the host network…

YES!!! Thanks!!! Confirmed this --net=host configuration also works with the armv7/armhf-ubuntu:trusty version as well. I can replicate this.

On a side note, following @jfrazelle thoughts that privileged might not be required, I also tested without this option, and I also got it running.

Summary: both the following let BLE work on a rpi2, with stock armhf Ubuntu 14.04 & docker 1.6.2: docker run -it --net=host --name bletest armv7/armhf-ubuntu bash docker run -it --privileged --net=host --name bletest armv7/armhf-ubuntu bash

@herver MANY THANKS

@TeoTN I was able to get this working inside docker swarm, in a service… docker service create --name mi_atc_reader --cap-add NET_ADMIN --network host mi_atc_reader (refer to https://github.com/AdysTech/mi_atc_reader)

I’ve found out the hard way that --net host or rather network_mode: host doesn’t work with Docker Swarm. Is there any way to access Bluetooth from within docker swarm containers?

Hey guys, I created a bluetooth docker image. I can get bluetooth to work inside of python3 with bluez.

https://hub.docker.com/r/don41382/rpi-python3-with-bluetooth/

Cheers Felix

@marcoh00 , can you also look at bluepy, specifically at https://github.com/IanHarvey/bluepy from @ianharvey and bluepy-helper https://github.com/IanHarvey/bluepy/blob/master/bluepy/bluepy-helper.c which is a little C program that interfaces with Bluetooth? There might be a reasonable way to proxy that through to a container.