Bumble inside a docker container without using bluetooth from host?

[vChavezB]

This might not be an issue but its more of a discussion (PS. It would be nice to have a discussions page to ask questions)

I have already seen the advantages of bumble for my use cases which is emulating BLE GATT interfaces from Iot Device firmware for integration tests (e.g. a Linux BLE Gateway or a Phone application). As I really like to automate everything I was interested in doing integration tests within Docker.

However, to use docker container (linux) with Bluez as far as I know you need access to the Bluetooth from host PC, otherwise you will get the error

Can't open HCI socket.: Address family not supported by protocol

Which happens when Bluez opens an HCI socket [1].

For a practical solution I have found out that I need to set up for my CI/CD a runner (either Gitlab or Github) that has access to the Bluetooth host even though I am not going to use real hardware rather bumble to create a virtual hci.

So I was wondering if there is a way to have a real virtual bluetooth bluez driver running on docker to use bumble. Its not that big of a problem but I rather run everything virtually with default runners (spawned by Github or Gitlab) rather than having a dedicated server to run my virtual bluetooth integration tests.

This came to my thought in the sense that if bumble already allows virtualization of bluetooth why not in Bluez in Docker, somehow (?).

Thanks for reading, I come more from an Embedded background so I might be ignorant on virtual solutions for bluetooth. Open for suggestions.

[barbibulle]

This should be possible.
Unfortunately, there does not seem to be an option to tell bluetoothd to use an HCI transport other than an HCI socket (socket(PF_BLUETOOTH, SOCK_RAW | SOCK_CLOEXEC | SOCK_NONBLOCK, BTPROTO_HCI), so we need to allow the docker container to create such a socket.
It should be possible if the docker host offers an implementation of HCI sockets (so, essentially, running Linux), and using the host networking mode of Docker (--net=host), along with the right permissions (--cap-add=SYS_ADMIN --cap-add=NET_ADMIN I think). If the host is macOS or Windows, that won't work.
Then, on the host, you need to ensure that creating the HCI socket will work, which means that there needs to be an HCI device visible to the kernel, but not used by the host's bluetoothd. This is simple, you can prevent bluetoothd from using a specific HCI device.
Finally, you need to connect the host's HCI socket to Bumble. This can be done by using Bumble's VHCI transport.

[vChavezB]

there does not seem to be an option to tell bluetoothd to use an HCI transport other than an HCI socket

Yes, I was checking the linux kernel BT stack and what I understand is that to communicate with linux hci drivers (virtual or physical) it registers two custom bluetooth socket types for hci and l2cap. Hence hciconfig and other bluez utilities communicates with these sockets to access the kernel hci interfaces through the bt stack.
user app <--dbus-->bluez < -sockets [hci,l2cap]--> kernel bt stack < --- > hci drivers

So as you said then I need to give access with --cap-add=SYS_ADMIN --cap-add=NET_ADMIN or better only to /var/run/dbus/ and ensure that the linux host is compiled with CONFIG_BT and that the bluetooth deamon is running.