绑定和连接后，BlueZ BLE加密特征读取失败 [英] BlueZ BLE Ecrypted Characteristic Read fails after bonding and connecting

问题描述

我正在将Raspberry Pi用作BLE外围设备，并将nRF Connect工具用作BLE客户端.在Raspberry Pi中，我正在运行简单代理测试程序，广告程序和 Gatt服务器程序在Bluez测试文件夹中给出.

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.

首先，从nRF Connect Tool绑定设备并连接设备.我已经为该过程附上了dbus日志.

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

1. 绑定时，日志显示以下内容

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

1. 在连接时，日志显示以下内容:

1. 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. 虽然绑定和连接路径不同:/org/bluez/hci0/dev_04_C8_07_BC_23_7A和/org/bluez/hci0/dev_7A_5D_49_4F_ED_08.对于Rasperry Pi，这意味着在绑定和连接时该设备看起来有所不同吗?

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?

如果它是绑定的，那么在连接时(配对的和可信任的)字段是否应该为True(不是，从日志来看)?

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.

推荐答案

因此，经过数小时的反复试验，我能够始终如一地重现失败案例和成功案例.

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

失败案例:

1. 启动Pi.
2. 启动代理，广告和gatt服务器.
3. 绑定设备.连接它.
4. 尝试读取加密的特征.它失败了.

成功案例:

1. 启动Pi.
2. 重新启动蓝牙服务.
3. 启动代理，广告和gatt服务器.
4. 绑定设备.连接它.
5. 尝试读取加密的特征.成功了.

因此，暂时而言，解决方法似乎是在启动后启动代理和广告之前重新启动蓝牙服务.

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

解决根本原因: Github链接中给出了解决此问题的方法.. >

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

经过大量挖掘，我发现此问题是由状态引起的 启动BlueZ时蓝牙芯片已插入(您可以检查 hciconfig hci0的状态).如果在"UP RUNNING"中州或州 "UP RUNNING PSCAN ISCAN"；状态，BlueZ抱怨以下一个或多个 这些:

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:

无法设置模式:已拒绝(0x0b)无法设置模式:已拒绝 (0x0b)无法设置隐私:已拒绝(0x0b)

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

但是，如果它处于"DOWN"状态，状态，BlueZ毫无问题.那么你 首先必须在蓝牙服务之前关闭hciconfig hci0 启动.但是在使用hciconfig之前，还需要确保 sys-subsystem-bluetooth-devices-hci0.device服务已启动！

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!

解决方案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

解决方案2:

我将bthelper的运行延迟了几秒钟，从而解决了这个问题，而无需禁用自动启动顺序并运行任何手动命令.

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.

我在/lib/systemd/system/bthelper@.service中添加了ExecStartPre行 这样服务"部分现在如下所示:

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

我尝试了解决方案2，并且有效.

I tried Solution 2 and it worked.

这篇关于绑定和连接后，BlueZ BLE加密特征读取失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！