【问题标题】:BlueZ BLE Ecrypted Characteristic Read fails after bonding and connectingBlueZ BLE 加密特性读取在绑定和连接后失败
【发布时间】:2020-07-18 13:10:08
【问题描述】:

我使用 Raspberry Pi 作为 BLE 外设和 nRF Connect 工具作为 BLE 客户端。在 Raspberry Pi 中,我正在运行 Bluez 测试文件夹中给出的 Simple Agent Test ProgramAdvertisement ProgramGatt Server Program

通过 nRF 连接工具,我首先绑定设备并连接设备。我已附上该进程的 dbus 日志。

  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. 连接时,日志显示如下:

     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 [
          ]
       )
    ]
    

我对以下内容感到困惑:

  1. 虽然绑定和连接路径不同:/org/bluez/hci0/dev_04_C8_07_BC_23_7A/org/bluez/hci0/dev_7A_5D_49_4F_ED_08。这是否意味着,对于 Rasperry Pi,设备在绑定和连接时看起来不同?

  2. 如果已绑定,那么在连接时 Paired 和 Trusted 字段是否不应该为 True(从日志中不是)?

  3. 在尝试读取加密特征时,绑定被删除并且连接也被断开。

【问题讨论】:

    标签: bluetooth-lowenergy bluez raspberry-pi4


    【解决方案1】:

    因此,经过数小时的反复试验,我已经能够一致地重现失败案例和成功案例。

    失败案例:

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

    成功案例:

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

    因此,目前,解决方法似乎是在启动后重新启动蓝牙服务,然后再启动代理和广告。

    解决根本原因: 这个问题的解决方法在这个Github link中给出。

    经过大量挖掘,我注意到这个问题是由状态引起的 蓝牙芯片在 BlueZ 启动时已启动(您可以检查 hciconfig hci0 的状态)。如果它处于“UP RUNNING”状态或 “UP RUNNING PSCAN ISCAN”状态,BlueZ 抱怨一个或多个 这些:

    设置模式失败:拒绝 (0x0b) 设置模式失败:拒绝 (0x0b) 设置隐私失败:拒绝(0x0b)

    但如果它处于“DOWN”状态,BlueZ 启动时没有问题。那么你 首先必须在蓝牙服务之前做 hciconfig hci0 down 启动。但在使用 hciconfig 之前,还需要确保 sys-subsystem-bluetooth-devices-hci0.device 服务已启动!

    解决方案 1:

    我最终禁用了自动启动序列,并改为运行此脚本:

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

    解决方案 2:

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

    我在 /lib/systemd/system/bthelper@.service 中添加了一个 ExecStartPre 行 这样服务部分现在看起来像这样:

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

    我尝试了解决方案 2,它奏效了。

    【讨论】:

      猜你喜欢
      • 2021-03-25
      • 2015-03-08
      • 2018-07-08
      • 2018-11-20
      • 1970-01-01
      • 2013-04-19
      • 2017-01-13
      • 2020-11-07
      • 1970-01-01
      相关资源
      最近更新 更多