Details
-
Bug
-
Resolution: Duplicate
-
Not Evaluated
-
None
-
5.10.1
-
None
-
Qt 5.10.1, Arch linux x86_64, BlueZ v5.49, Bluetooth v4.2 dongle. Can be recreated by taking the lowenergyscanner application, removing the setaddresstype() function and running as a normal user then trying to connect to a device with a random address.
Description
I raised a query a long time about being able to get the address type of a Bluetooth Low Energy device when scanning and was told that only root users can do it or those with special permissions but was told that if a device is detected in a scan by Qt then it should be able to connect to it without knowing if it's a public or random address as this information is retained by the kernel, but I'm not able to get this to work unless I explicitly grant the CAP_NET_ADMIN permission to the generated Qt executable, after doing this I can detect a device in a scan (with a random address) and then connect to it without calling the function to set the type of the address.
However, I'm able to use bluetoothctl (included as part of BlueZ), to scan for devices and connect to them without knowing if their address type is random or public, and there are no special permissions granted to this:
[user@SPP-Linux qtbluetooth]$ getcap /usr/bin/bluetoothctl [user@SPP-Linux qtbluetooth]$ getcap /home/user/qtvsp_otp.git/qtbluetooth /home/user/qtbluetooth/qtbluetooth = cap_dac_override,cap_net_admin,cap_net_raw+eip [user@SPP-Linux qtbluetooth]$
So is this a bug in Qt/should I be able to connect to a device from the device scan callback without needing special permissions or is bluetoothctl using a different access mechanism? I don't want to know what type of address the device has, I just want to connect to a BLE device I've detected in a scan.
Attachments
Issue Links
- duplicates
-
QTBUG-66908 Port central role support for QtBluetooth using DBus BlueZ
- Closed