Details
-
Bug
-
Resolution: Incomplete
-
P2: Important
-
None
-
6.8.0
-
None
-
Linux, qt 6.8.0
-
-
Foundation PM Prioritized, Foundation Sprint 124, Foundation Sprint 125, Foundation Sprint 126
Description
Normally connecting to open devices for testing which has been working ok, but today tried connecting to a device which has an authorisation requirement on a characteristic (to read/write it, that is) and seemingly this throws qtconnectivity into an undefined state, the output I get in my application is:
[12:17:23] mcumgr: Discovered Bluetooth service: "{00001801-0000-1000-8000-00805f9b34fb}" [12:17:23] mcumgr: Discovered Bluetooth service: "{00001523-1212-efde-1523-785feabcd123}" [12:17:23] mcumgr: Discovered Bluetooth service: "{8d53dc1d-1db7-4cd3-868b-8a527460aa84}" [12:17:23] mcumgr: Bluetooth MTU: 509 [12:17:23] mcumgr: Bluetooth service state changed: QLowEnergyService::RemoteServiceDiscovering
The output I get on the actual device being connected to:
Connected Passkey for DC:21:5C:F7:22:21 (public): 325375 E: pairing failed (peer reason 0x1) Pairing cancelled: DC:21:5C:F7:22:21 (public) Security failed: DC:21:5C:F7:22:21 (public) level 1 err 1 Pairing failed conn: DC:21:5C:F7:22:21 (public), reason 1
But qt seems stuck at this point, nothing more happens unless I disconnect. I've looked through qlowenergycontroller and don't see a way to deal with pairing or how to even know the other side is trying to request a pair. All I can see is this function which requests pairing but that doesn't seem right here https://doc.qt.io/qt-6/qbluetoothlocaldevice.html#requestPairing
Here is a log of bluetooth on the host PC (central): log_security.pcapng
Have marked this as a bug because it sort of seems it but not sure if the feature is not yet implemented or will never be implemented. This is with the bluez dbus api, did try running with export QT_BLUETOOTH_USE_KERNEL_PERIPHERAL=1 but the behaviour was the same