Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
qtbluetooth problems
12:36 @kido | updates from the starfish side: so I've written this large codebase with libasteroid using QtBluetooth. it turns out that QtBluetooth wants to handle everything
| itself(especially the whole connection process) and since the L2CAP channel needs to be encrypted, QtBluetooth asks the kernel if it can set up a high security BLE
| connection but in the best case it gets rejected which eventually closes the
12:36 @kido | connection, in the worst case my Jolla C kernel panics... apparently, in order to be able to set up that high sec channel we need to connect from the system side (ie: from
| bluetoothd) and only use the BlueZ's GATT DBus APIs. from what I could understand, this can not be done with QtBluetooth so I've been experimenting with gattlib instead
| but gattlib doesn't work on my computer (dbus crashes) and it doesn't
12:36 @kido | cross compile cleanly with the sailfishos SDK (lots of missing symbols in the bluez libs and some type conversions it doesn't like...) so the experiment is still open
12:37 @kido | if anyone is willing to help, I could push the current qtbluetooth based codebase but cross-compiling asteroid-ctrl is an easier way to reproduce the high sec L2CAP
| problem
12:38 @kido | alternatively, I was also able to reproduce that problem with https://openrepos.net/content/martonmiklos/ble-scanner when discovering the battery service of my asteroid
| watch
12:39 @kido | running the ble scanner from a terminal with strace, we can see that the kernel returns an EACCES error code. I've blindly tracked that down to
| https://github.com/KonstaT/sailfishos_kernel_jolla_msm8930/blob/master/net/bluetooth/l2cap_sock.c#L162 but setting CAP_NET_BIND_SERVICE doesn't fix the problem
12:44 @kido | it's under certain conditions, when you try to connect with qtbluetooth and then from the settings
12:45 @kido | the phone reboots
12:45 @kido | if you just connect from settings, the connection stays active really well (for more than a day without any disconnection and so on)
12:46 @kido | which makes me think we should try to find a simple BlueZ's DBus GATT API wrapper (or write one, alternatively :( ) that "just works" on sailfish
12:47 @kido | let the user connect from system settings, and then starfish communicates with starfishd on dbus and starfishd with bluetoothd on dbus as well
12:50 r0kk3rz | hmm i wonder how systemsettings works, theres probably a qml plugin or something
12:51 @kido | yeah, I wonder as well but I don't think that code is public
12:51 @kido | haven't had the time to check that yet
12:51 @kido | maybe it just connects but never asks for a service discovery on the BLE services that require encryption
12:52 @kido | well, no, that should work since it properly asks for pairing
12:53 @kido | I'm really confused at that point, I wish this SFOS BLE stack was properly tested and documented
12:54 @kido | and when I have a problem on asteroid, I can easily recompile everything with debugging logs from the kernel to the app but when it comes to my jolla c, it looks like the
| kernel building process is not documented at all, I have no idea how to rebuild bluez and so on
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.