从 Bluez 5.48 开始，iPhone 在连接 BLE GAP 外设时需要配对，为什么？

Question

我有一个使用 Bluez 5.X 和 DBus 在嵌入式设备上运行的应用程序。

\n\n

\n

• 我的应用程序将具有“NoInputNoOutput”功能的代理和适配器设置为不可配对（我不想配对）。

\n

• 我的嵌入式设备不发起连接（GAP 外围设备）和广播广告（GATT 服务器）。

\n

\n\n

使用 BlueZ 5.48（和 5.52），当我尝试从 Android 设备连接到我的嵌入式设备时，一切正常，但当我尝试使用 iOS 时，连接在一段时间后丢失，并且在 btmon 工具中存在以下日志：

\n\n

> ACL Data RX: Handle 68 flags 0x02 dlen 9              #1050 [hci0] 398.940027\n  ATT: Error Response (0x01) len 4\n    Read Request (0x0a)\n    Handle: 0x0016\n    Error: Insufficient Authentication (0x05)\n< ACL Data TX: Handle 68 flags 0x00 dlen 7              #1051 [hci0] 398.940268\n      ATT: Read Request (0x0a) len 2\n        Handle: 0x0016\n> ACL Data RX: Handle 68 flags 0x02 dlen 9              #1052 [hci0] 398.991500\n      ATT: Error Response (0x01) len 4\n        Read Request (0x0a)\n        Handle: 0x0016\n        Error: Insufficient Authentication (0x05)\n

\n\n

如果我的应用程序将适配器设置为可配对（但我不想），我会在 iPhone 上（而不是在 andro\xc3\xafd 上）看到一个弹出窗口，以便授权配对

\n\n

信息：

\n\n

\n
• 我的 BlueZ 5.47 没有这个问题
\n
• 我在 iPhone 的常规蓝牙\n“设备”列表中没有看到我的嵌入式设备。
\n
• 即使我的应用程序未设置任何\n特征，我也遇到问题
\n

\n\n

我没有发现（在 ChangeLog 和 git 中）自 BlueZ 5.47 以来的更改，这会导致此问题。有任何想法吗 ？

\n\n

我认为 iPhone 上有一个 GATT 服务器，因为我可以看到连接时在 DBus 上注册的许多对象。我对 andro\xc3\xafd 没有这个问题，即使我设置了具有“读取加密”权限特征的 GATT 服务器（nRF Connect）

\n\n

我的分析：

\n\n

\n

1. 在 Iphone 上，我启动与嵌入式设备的连接

\n

2. 我的嵌入式设备尝试读取 iPhone 上的某些内容（受保护的特征\n？）（不！为什么？）

\n

3. iPhone拒绝“加密不足”（？）

\n

4. 我的嵌入式设备发送“安全请求”

\n

5. Iphone 发送“配对请求”

\n

6. 我嵌入的拒绝“原因配对不支持”

\n

\n\n

编辑：\n弹出窗口显示提交“client：将 set-filter-uuids 重命名为 uuids”（e1021f7e486ebd6c0618673a758fa2c50d81109c）（Bluez 5.47 和 5.48 之间）

\n

Answer 1

这有点晚了，但希望这可以帮助其他遇到同样问题的人。

在将电池 GATT 特性移至DBUS org.bluez.Battery1 接口后，Bluez v5.48 中开始出现此问题。

解决此问题的最简单方法是阻止 Bluez 电池插件在启动时加载。您将需要修改位于以下路径的蓝牙服务文件： /lib/systemd/system/bluetooth.service 。在此文件中，转到以“ExecStart”开头的行，并确保该行具有“ExecStart=/usr/lib/bluetooth/bluetoothd -P Battery”（不带引号）。此 -P 选项可防止加载任何列出的插件。

解决此问题的另一种方法是编写自己的自定义代理来自动接受配对请求。我使用了Bluez simple-agent 示例并对其进行了修改，以便 RequestPinCode 函数始终成功返回而不是要求输入。这种方法的缺点是仍然要求 iOS 用户进行配对。尽管如此，如果您想通过完全配对的蓝牙连接获得可靠性和加密访问，这可能是一个积极的结果。