BlueZ BLE Ecrypted Characteristic Read fails after bonding and connecting

问题

I am using Raspberry Pi as a BLE Peripheral and nRF Connect tool as BLE Client. In Raspberry Pi, I'm running Simple Agent Test Program, Advertisement Program and Gatt Server Program given in the Bluez Test Folder.

From the nRF Connect Tool, I, first bonded the devices and connected the devices. I have attached the dbus logs for the process.

1. While bonding, the log shows the following

signal time=1595076323.849939 sender=:1.15 -> destination=(null destination) serial=863 path=/org/bluez/hci0/dev_04_C8_07_BC_23_7A; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged

  string "org.bluez.Device1"
   array [
      dict entry(
         string "Connected"
         variant             boolean true
      )
   ]
   array [
   ]
method call time=1595076324.986873 sender=:1.15 -> destination=:1.79 serial=864 path=/test/agent; interface=org.bluez.Agent1; member=RequestConfirmation
   object path "/org/bluez/hci0/dev_04_C8_07_BC_23_7A"
   uint32 243301

2. While connecting, the log shows the following:

    signal time=1595076345.854856 sender=:1.15 -> destination=(null destination) serial=868 path=/; interface=org.freedesktop.DBus.ObjectManager; member=InterfacesAdded
   object path "/org/bluez/hci0/dev_7A_5D_49_4F_ED_08"
   array [
      dict entry(
         string "org.freedesktop.DBus.Introspectable"
         array [
         ]
      )
      dict entry(
         string "org.bluez.Device1"
         array [
            dict entry(
               string "Address"
               variant                   string "7A:5D:49:4F:ED:08"
            )
            dict entry(
               string "AddressType"
               variant                   string "random"
            )
            dict entry(
               string "Alias"
               variant                   string "7A-5D-49-4F-ED-08"
            )
            dict entry(
               string "Paired"
               variant                   boolean false
            )
            dict entry(
               string "Trusted"
               variant                   boolean false
            )
            dict entry(
               string "Blocked"
               variant                   boolean false
            )
            dict entry(
               string "LegacyPairing"
               variant                   boolean false
            )
            dict entry(
               string "Connected"
               variant                   boolean true
            )
            dict entry(
               string "UUIDs"
               variant                   array [
                  ]
            )
            dict entry(
               string "Adapter"
               variant                   object path "/org/bluez/hci0"
            )
            dict entry(
               string "ServicesResolved"
               variant                   boolean false
            )
         ]
      )
      dict entry(
         string "org.freedesktop.DBus.Properties"
         array [
         ]
      )
   ]
   

I am confused with the following:

1. While bonding and connecting the paths are different: /org/bluez/hci0/dev_04_C8_07_BC_23_7A and /org/bluez/hci0/dev_7A_5D_49_4F_ED_08. Does it mean, to the Rasperry Pi, the device appears different while bonding and connecting?

2. If it is bonded, then shouldn't the Paired and Trusted fields be True while connecting (which is not, from the log)?

3. While trying to read an encrypted characteristic, the bond is deleted and connection is also disconnected.

回答1:

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.

来源：https://stackoverflow.com/questions/62968970/bluez-ble-ecrypted-characteristic-read-fails-after-bonding-and-connecting