BLE passkey pairing does not work without restarting HCI

I have an application where Raspberry pi 3b+ is in a central role and it provides GUI for controlling a peripheral device. The application registers pairing agent with dbus API and passkey pairing works well, when I am running this docker app on my desktop linux computer. But when I run the same app on Raspberry pi 3b+, the GUI does not show passkey prompt. Host OS dmesg prints “Bluetooth: hci0: security requested but not available”.

Only way I can get the pairing to work correctly is calling hciconfig hci0 down and hciconfig hci0 up on Host OS. I can’t call these from my application container, so any ideas how I could solve this problem?

Hello @emalinen you are trying to connect BLE over HostOS instead from a container, right? probably this is why you have this issue. We have seen this before.

I would recommend that you can use the DBUS block with the Bluetooth block to manage the Bluetooth over DBUS communication between containers.

Let us know if that works for you

Yes, I’m accessing host dbus from the container. I did have previously quite hard time figuring out how to run python websocket using asyncio event loop and dbus using GLib event loop in the same python application. I solved the problem by replacing dbus library with dbus-next library. If I add the dbus block, does my dbus-next automatically access this bus instead of the host bus?

Seems like the dbus image is not available “Error: pull access denied for balenablocks/dbus, repository does not exist or may require ‘docker login’: denied: requested access to the resource is denied”. I am logged in.

Actually I just got the problem solved by setting “Powered” to off and on using the dbus API, but I would prefer not to do this.

If I add the dbus block, does my dbus-next automatically access this bus instead of the host bus?

The dbus client usually defaults to the bus specified by the DBUS_SYSTEM_BUS_ADDRESS or DBUS_SESSION_BUS_ADDRESS environment variables, depending on which bus you’re connecting to. The dbus-send command, for instance, uses these to decide what bus to connect to. If you’re using a library to talk to dbus, there may be an API for choosing how to connect which is specific to that library, but generally, you can set these variables and expect it to work.

Seems like the dbus image is not available “Error: pull access denied for balenablocks/dbus, repository does not exist or may require ‘docker login’: denied: requested access to the resource is denied”. I am logged in.

This is a pretty new block that was developed just a few weeks ago, it seems we’re not building and shipping this image in our repository yet. I’ll push this along and see what we can do to remedy this. In the mean time, you can add this block as a submodule in your project, and specify it using the build: directive in your docker-compose.yml.

We’ve been doing some work recently around making dbus on balenaOS more accessible and better documented, so this should become easier soon.

Adding dbus block using the build directive and exporting DBUS_SYSTEM_BUS_ADDRESS solved the problem without any changes to my original app. Thanks for the help!

Great to hear!