Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CANFkB1ydGuwKRjusy3U0HCQo8E88XbZTh_UdPZ8wujt7P5KKnQ@mail.gmail.com>
 <CABBYNZLjV3PQ7Hm3PJZcTcs64aLzWLBNfooSYuZmSywv0RJG0g@mail.gmail.com>
 <CANFkB1yr3N_Twac=ocxBRst79-gmdu8=6VTD6oPgdGT0rb_HaQ@mail.gmail.com> <CANFkB1xEesP1cMmK4VGi5cH-v80ho00wT24q=+4QQSdyPegPQQ@mail.gmail.com>
In-Reply-To: <CANFkB1xEesP1cMmK4VGi5cH-v80ho00wT24q=+4QQSdyPegPQQ@mail.gmail.com>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Tue, 22 Mar 2022 14:35:11 -0700
Message-ID: <CABBYNZKSsyqfiWYjpuZNYtKAZb4C2q73YwOj=KoUFq71gLs7Hg@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 Tue, Mar 22, 2022 at 3:40 AM Adam Pigg <adam@piggz.co.uk> wrote:
>
> Hi Luiz
>
>
> On Tue, 22 Mar 2022 at 07:55, Adam Pigg <adam@piggz.co.uk> wrote:
> >
> > Hi Luiz
> >
> > On Tue, 22 Mar 2022 at 00:44, Luiz Augusto von Dentz
> > <luiz.dentz@gmail.com> wrote:
> > >
> > > 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.
> > >
> > >
> > 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