linux - 使用 org.bluez.Adapter.CreateDevice 连接到 BT LE 设备失败并显示 org.bluez.Error.Failed : Operation canceled Error

Question

我正在尝试使用 BlueZ 4.X DBus 接口(interface)在 Linux 上建立与蓝牙 4.0 LE 设备的连接。

为了测试这一点，我使用以下命令:

dbus-send --system --dest=org.bluez --print-reply /org/bluez/<PID of bluetoothd>/hci0 org.bluez.Adapter.CreateDevice string:<MAC of BT device>

这个命令似乎大多数时候都有效，给出的结果如下:

method return sender=:1.238 -> dest=:1.262 reply_serial=2
   object path "/org/bluez/9652/hci1/dev_BC_6A_29_26_C2_1C"

并使我能够与设备 DBus 对象进行交互。

但是，从昨天开始，这似乎非常频繁地返回以下错误:

Error org.bluez.Error.Failed: Operation canceled

调试蓝牙守护进程时，(使用bluetoothd -n -d)在执行方法调用时我注意到以下事情:

bluetoothd[340]: src/adapter.c:create_device() BC:6A:29:26:C2:1C
bluetoothd[340]: src/adapter.c:adapter_create_device() BC:6A:29:26:C2:1C
bluetoothd[340]: src/device.c:device_create() Creating device /org/bluez/340/hci0/dev_BC_6A_29_26_C2_1C
bluetoothd[340]: src/device.c:btd_device_ref() 0xb7ad8: ref=1
bluetoothd[340]: src/device.c:device_set_temporary() temporary 1
bluetoothd[340]: src/device.c:btd_device_ref() 0xb7ad8: ref=2
bluetoothd[340]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[340]: plugins/mgmtops.c:mgmt_event() Received 14 bytes from management socket
bluetoothd[340]: plugins/mgmtops.c:mgmt_connect_failed() hci0 BC:6A:29:26:C2:1C status 4
bluetoothd[340]: src/event.c:btd_event_conn_failed() status 0x04
bluetoothd[340]: src/device.c:device_remove() Removing device /org/bluez/340/hci0/dev_BC_6A_29_26_C2_1C
bluetoothd[340]: src/device.c:device_set_temporary() temporary 1
bluetoothd[340]: src/device.c:btd_device_unref() 0xb7ad8: ref=1
bluetoothd[340]: src/device.c:btd_device_unref() 0xb7ad8: ref=0
bluetoothd[340]: src/device.c:device_free() 0xb7ad8

据我所知，当我尝试连接到设备时，我的蓝牙加密狗向我发送了一个错误事件(状态 4)。

但是，当我使用 hcitool ot gatttool 连接到设备时，一切正常。

我发现这种情况主要发生在我尝试使用不同的程序(即 cinnamon-settings)连接到设备并过早取消连接之后。我在 Angstrom 上的其他程序(如蓝牙属性)中也注意到了这一点。

我的猜测是 Bluez 在某些情况下向我的蓝牙加密狗发送了错误的 HCI 命令。我认为这是因为 gui 程序尝试与设备配对而不是仅仅连接到它，这可能导致 BlueZ 认为我的设备是蓝牙 2.0 设备。

到目前为止，我似乎能够通过使用 gui 应用程序连接到我的 BT 设备来解决这个问题，等待它失败，然后重新启动我的计算机。然而，这个问题似乎偶尔会再次出现，这让人非常痛苦。

我在同时运行 BlueZ 版本 4.99 和 4.101 的系统上看到过这个问题。

有谁知道我该如何正确解决这个问题？

Answer 1

看来我的预测或多或少是正确的。经过几个小时的调试蓝牙守护进程后，我发现在没有初步扫描的情况下连接到 BT LE 设备会导致守护进程尝试连接到作为 BR/EDR 设备的设备。这是因为守护程序的“内部缓存”充满了 EIR。发现设备时的信息。如果在连接到 LE 设备时此信息不可用，则 CreateDevice 方法将失败。

一个简单的解决方案是始终确保在连接到设备之前发现它们。

BlueZ 5 API introduction and porting guide还描述了这个问题，以及它是如何在 BlueZ 5 中解决的:

Bluetooth Low Energy essentially extended Bluetooth addresses with one extra bit, requiring one to always know whether an address is “random” or “public”. This caused issues with the BlueZ 4 API where the address was given to BlueZ in the CreateDevice and CreatePairedDevice calls. Since the parameter didn’t contain any of this extra random/public information bluetoothd had to maintain an internal cache to look up the necessary info. Another complication to the matter is that the BlueZ D-Bus API doesn’t differentiate between traditional BR/EDR devices and LE devices so there are essentially three possible address types: BR/EDR, LE public and LE random.