Hi Adam, On Tue, Mar 22, 2022 at 3:40 AM Adam Pigg <adam@xxxxxxxxxxx> wrote: > > Hi Luiz > > > On Tue, 22 Mar 2022 at 07:55, Adam Pigg <adam@xxxxxxxxxxx> wrote: > > > > Hi Luiz > > > > On Tue, 22 Mar 2022 at 00:44, Luiz Augusto von Dentz > > <luiz.dentz@xxxxxxxxx> wrote: > > > > > > Hi Adam, > > > > > > On Mon, Mar 21, 2022 at 4:03 PM Adam Pigg <adam@xxxxxxxxxxx> wrote: > > > > > > > > Hi > > > > > > > > A bit of background, I write a linux desktop/mobile app called > > > > Amazfish which interfaces with several watches over BLE using their > > > > GATT services. To do this, I use the bluez dbus api (technically a > > > > thin wrapper around it I wrote called qble > > > > https://github.com/piggz/qble) > > > > > > > > All has been good so far, I support several generations of > > > > Huami/Amazfit watches, as well as the open source Pinetime and > > > > Bangle.js. For the Amazfit watches, i have implementations for older > > > > devies such as the Bip, and newer ones such as the GTS. > > > > > > > > Much of the reverse engineering comes from the Android Gadget Bridge > > > > project, which supports many more devices. > > > > > > > > My community of users donated to buy me a newer device called a GTR2, > > > > which, according to the GB devs uses the same protocol as the slightly > > > > older GTS, and the packet captures I have from Android would support > > > > this. > > > > > > > > But this is where my trouble starts with Bluez, my existing > > > > implementation doesnt work at all. Normally, after a connection, I > > > > would wait for the ServicesResolved signal, which happens pretty fast > > > > on all other devices, but on the GTR2, it takes about 30 seconds, by > > > > which time, the watch has disconnected. (i get a disconnected signal > > > > immediately after the ServicesResolved signal) > > > > > > > > To rule out my code, I have tried several things: > > > > Gatttool > > > > With gattool, i can connect, get the services, enable a notification, > > > > write a value and get the expected results seemingly fine > > > > > > > > Python-gatt (using the bluez dbus api) > > > > Im unable to iterate the services, like my app, it takes 30 seconds to > > > > get the signal and then swiftly disconnects > > > > > > > > Gattlib (https://github.com/labapart/gattlib) > > > > Gattlib is interesting as it appears to have "borrowed" much of its > > > > code directly from bluez. When built against the system bluez, if the > > > > version is > 5.42, it will use the dbus api. When I do this, again im > > > > unable to list services on the watch. However, if I edit the build to > > > > force it to use its internal gatt implementation, which appears to be > > > > the same one used by gatttool, then, it IS able to interrogate the > > > > watch. > > > > > > > > I have attached 3 files > > > > 1. test python program which should print services, and associated btmon > > > > 2. btmon output while using gatttool > > > > 3. btmon output running gattlib discover example > > > > > > > > Note, other than discovery, I havnt been able to get gattlib to > > > > read/write/notify! > > > > > > > > It seems as though I may be triggering a bug in the bluez dbus api? > > > > Can anyone suggest anything? > > > > > > What version are you using? I would first try with the latest to see > > > if that something already fixed. > > > > > > > > Im using 5.63 already, which is the latest tag (on opensuse tumbleweed) > > > > I'll also try bluetoothctl and attach logs using that, though I > > suspect it will behave the same as the python library and my own > > library. > > > > Attached is the output of btmon while using bluetoothctl > > bluetoothctl behaves the same as my lib and python, it is unable to > list services, and after a while, emits the ServicesResolved and > disconnected messages at the same time. Im sure it should be able to > list the services immediately after connect just like gatttool can. Looks like there is multiple rounds of MTU Exchange, not sure if that is actually a problem but the spec does say it shall only be sent once per client: BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part F page 1424: This request shall only be sent once during a connection by the client. There is also no response to frame #30: < ACL Data TX: Handle 3585 flags 0x00 dlen 7 #30 [hci0] 26.641557 ATT: Read Request (0x0a) len 2 Handle: 0x0018 So after 30 seconds (ATT timeout) without receiving any response it disconnects: < HCI Command: Disconnect (0x01|0x0006) plen 3 #48 [hci0] 58.673128 Handle: 3585 Reason: Remote User Terminated Connection (0x13) > Thanks > > > > > -- > > > Luiz Augusto von Dentz -- Luiz Augusto von Dentz
