Bluetooth serial port

Hello,

I’m trying to connect to a bluetooth device that is using bluetooth classic and using the Serial Port Profile. I’m trying this on a RPi 4, using balenaCloud builder and the OS is balenaOS 2.44.0+rev3. The bluetooth device is working fine with a regular debian stretch or buster installation on RPi3.
On balenaOS I get the following behaviour:
I’m logged in to the HostOS.
I can scan for devices.
I find my device.
I can pair it.
When I try to connect I get the following:

[bluetooth]# connect 00:12:6F:81:C7:CD
Attempting to connect to 00:12:6F:81:C7:CD
[CHG] Device 00:12:6F:81:C7:CD Connected: yes
[CHG] Device 00:12:6F:81:C7:CD ServicesResolved: yes
Failed to connect: org.bluez.Error.NotAvailable

What’s the cause of this?
I figure, before I can’t connect on the hostOS properly I don’t even have to try in one of my containers.

Just in case it’s important here’s the output of info 00:12:6F:81:C7:CD:

Device 00:12:6F:81:C7:CD (public)
        Name: Serial Adaptor
        Alias: Serial Adaptor
        Class: 0x00000680
        Icon: printer
        Paired: yes
        Trusted: no
        Blocked: no
        Connected: no
        LegacyPairing: no
        UUID: Serial Port               (00001101-0000-1000-8000-00805f9b34fb)

Thanks for any advice.

best,
eb

Hello @electrobusch,

Bluetooth Serial Port Profile (SPP) requires bluetoothd to be run with the --compat compatibility flag which is currently not supported on balenaOS. There is already an open issue with this feature request, we’ll keep you updated on it’s progress via this forum post.

In the meantime, in case you want to try it out, this are the required steps. Note however that it’s not advised to make this modifications on a production device since you will need to remount and edit the root file system.

1 ) Remount root fs as read-write: mount -o remount,rw /
2 ) Edit bluetoothd service file /etc/systemd/system/dbus-org.bluez.service:
- Add the --compat flag to the ExecStart command
- Add ExecStartPost=/usr/bin/sdptool add SP after the ExecStart command line
3 ) Reload config file and restart service: systemctl daemon-reload && systemctl restart bluetooth.service

If you do try this out, please let us know how it goes!

Hello @tmigone,

thank you for the help.
I gave the workaround a shot. Unfortunately with no luck. The behaviour stays the same. Do I have to reboot the device?
I’m trying to connect with bluetoothctl. I’m not sure if this is actually using the dbus api or not.
(Bluez is so confusing ._. )

I also found this thread and this one on the raspberry pi forums. There the path to bluetoothd is /usr/lib/bluetooth/bluetoothd
Does that matter?

Best,
eb

EDIT:
So I tried to connect via dbus from inside a container with a python script that uses pybluez (which did not work before). Now the sensor connects, but I’m getting a socket time out. I hope this can be solved by adjusting the socket options a little bit. I’ll keep you posted.

Glad you have some progress! Please let us know if you manage to solve the timeouts problem.

Hello again,

So the time out is gone, but now I ran in to the error described in this pybluez issue.
I guess I’ll have to do a bit of research to find pybluez alternatives. :frowning:

EDIT: My current solution with pybluez is to omit the timeout.
Just out of curiosity: After applying the manipulation in /etc/systemd/system/dbus-org.bluez.service
I should be able to remount the root directory as read only again, right?
Is there any other concern, why I should not use this in a production environment?

Best,
eb

Hi, I just wanted to comment on the editing of the bluez dbus service. Generally I don’t see why this change should make the device less secure if you remember to remount as read-only as you say.

The problem and the reason why we advise against it in production is that once you update the OS these changes will be gone and will have to be made again, which makes it more difficult to maintain your application.