r0kk3rz/gist:4a6a37160933d05defea3744e9ddd7de Secret

## gistfile1.txt
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
	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