Multiple Ble Connections Using Linux and Bluez 5.0

Establishing multiple BLE connections simultaneously using BlueZ

I think the whitelist method is the only way to handle establishing multiple connections at once. HCI is only able to handle establishing one connection at a time as (if I remember correctly) you don't have any connection handle until the connection is established.

The L2CAP socket is a kernel abstraction that utilizes the HCI method. If you try to start another connection while one is pending I think you get an error.

I suspect even the DBUS method mention is just an abstraction over the HCI method and it's still a process of making connections in sequence.

Even if you used the whitelist method, though, I'm not sure how much faster it'd actually be as the issue is the connection interval along with the advertising interval. The whitelist works by listening for advertising packets and establishing connections as they're detected. I've also never used the whitelist method, but you'd probably have to use an HCI socket and handle multiplexing the different devices over that one socket yourself.

Most hardware will allow you to establish connections while still scanning, so you can be collecting new ad packets while waiting for the current connection to establish. When a connection is finished establishing you can move to the next. As long as connection can be established relatively quickly, there's no benefit over using a whitelist. (the actual underlying implementation may be the same any way)

Using Bluez/Linux, can I run a daemon broadcasting BLE ibeacons and be connectable using RFCOMM simultaneously?

If you are using a common CSR 4.0 Dongle or Ampac AP6212 (which purportedly uses the same Broadcom chip as the RPI3) then this is possible - they are "dual-stack".

Given this, the typical USB CSR chips have a hard limit of two connected RFCOMM clients and the Ampac, 8 or maybe more (tested for sure 8).

BlueZ BLE Ecrypted Characteristic Read fails after bonding and connecting

So, after many hours of trial and error, I have been able to reproduce the failure case and successful case consistently.

Failure Case:

1. Boot up the Pi.
2. Start the agent, advertisement and gatt server.
3. Bond the device. Connect it.
4. Try to read the encrypted characteristic. It fails.

Success Case:

1. Boot up the Pi.
2. Restart bluetooth service.
3. Start the agent, advertisement and gatt server.
4. Bond the device. Connect it.
5. Try to read the encrypted characteristic. It succeeds.

So, for the time being, the workaround seems to be restarting the bluetooth service after boot up before starting the agents and advertisements.

Fixing the root cause:
The solution to this problem is given in this Github link.

After much digging, I noticed that this problem is caused by the state
the bluetooth chip is in at the time BlueZ is fired up (you can check
the state with hciconfig hci0). If it's in "UP RUNNING" state or in
"UP RUNNING PSCAN ISCAN" state, BlueZ complains with one or more of
these:

Failed to set mode: Rejected (0x0b) Failed to set mode: Rejected
(0x0b) Failed to set privacy: Rejected (0x0b)

But if it's in "DOWN" state, BlueZ starts with no issues. So, you
first have to do hciconfig hci0 down before the bluetooth service
starts up. But before you can use hciconfig, you also need to ensure
the sys-subsystem-bluetooth-devices-hci0.device service has started!

Solution 1:

I ended up disabling the automatic boot sequence, and run this script instead:

systemctl start sys-subsystem-bluetooth-devices-hci0.device; hciconfig hci0 down; systemctl start bluetooth

Solution 2:

Delaying the running of bthelper by a couple of seconds fixed this issue for me, without me having to disable the automatic boot sequence and run any manual commands.

I added an ExecStartPre line to /lib/systemd/system/bthelper@.service
such that the Service section now looks like this:

[Service]
Type=simple
ExecStartPre=/bin/sleep 2
ExecStart=/usr/bin/bthelper %I

I tried Solution 2 and it worked.

---

Related Topics