BlueZ BLE Ecrypted Characteristic Read fails after bonding and connecting - bluetooth-lowenergy

Question

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.
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
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:
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?
If it is bonded, then shouldn't the Paired and Trusted fields be True while connecting (which is not, from the log)?
While trying to read an encrypted characteristic, the bond is deleted and connection is also disconnected.

Answer 1

So, after many hours of trial and error, I have been able to reproduce the failure case and successful case consistently.
Failure Case:
Boot up the Pi.
Start the agent, advertisement and gatt server.
Bond the device. Connect it.
Try to read the encrypted characteristic. It fails.
Success Case:
Boot up the Pi.
Restart bluetooth service.
Start the agent, advertisement and gatt server.
Bond the device. Connect it.
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.