Received-SPF: softfail (google.com: domain of transitioning linux-bluetooth-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <CANFkB1ydGuwKRjusy3U0HCQo8E88XbZTh_UdPZ8wujt7P5KKnQ@mail.gmail.com>
In-Reply-To: <CANFkB1ydGuwKRjusy3U0HCQo8E88XbZTh_UdPZ8wujt7P5KKnQ@mail.gmail.com>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Mon, 21 Mar 2022 17:43:48 -0700
Message-ID: <CABBYNZLjV3PQ7Hm3PJZcTcs64aLzWLBNfooSYuZmSywv0RJG0g@mail.gmail.com>
Subject: Re: GATT issue, possible bluez bug?
To:     Adam Pigg <adam@piggz.co.uk>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Adam,

On Mon, Mar 21, 2022 at 4:03 PM Adam Pigg <adam@piggz.co.uk> 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.


-- 
Luiz Augusto von Dentz