Re: GATT characteristic for only LE or BR/EDR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Alexander,

On Mon, Aug 5, 2024 at 11:21 AM Alexander Ganslandt
<Alexander.Ganslandt@xxxxxxxx> wrote:
>
> Hi Luiz,
>
> On Mon, Aug 5, 2024 at 15:12 Luiz Augusto von Dentz
> <luiz.dentz@xxxxxxxxx> wrote:
> > Hi Alexander,
> >
> > On Mon, Aug 5, 2024 at 9:04 AM Luiz Augusto von Dentz
> > <luiz.dentz@xxxxxxxxx> wrote:
> > >
> > > Hi Alexander,
> > >
> > > On Mon, Aug 5, 2024 at 8:31 AM Alexander Ganslandt
> > > <Alexander.Ganslandt@xxxxxxxx> wrote:
> > > >
> > > > Hello!
> > > >
> > > > I found a previous discussion about this here: https://lore.kernel.org/all/59CDEBDF.3090200@xxxxxxxx/t/, but there was no conclusion. Now I'm having the same issue 7 years later :)
> > > >
> > > > I'm trying to pass BT SIG tests but fail on two test cases: GATT/SR/GAR/BI-34-C and GATT/SR/GAR/BI-35-C. To my understanding, in order to pass these tests, you need to register a GATT characteristic that is readable only through LE or BR/EDR, but not both at the same time. However, when I register a service+characteristic through bluetoothctl, it is automatically registered for both LE and BR/EDR. To verify this, I use gatttool with and without "-p 31" to connect over BR/EDR and LE respectively, and the characteristic shows up in both. Based on the previous discussion, and based on reading the BlueZ API, there doesn't seem to be a way to only support ONE transport for a characteristic? Is this conclusion correct?
> > >
> > > You can detect what bearer it is connected via:
> > >
> > > bluez/doc/org.bluez.GattCharacteristic.rst at master · bluez/bluez · GitHub
> > >
> > > Looks like we are missing one of the options is link which can be
> > > either LE or BR/EDR:
> > >
> > > bluez/src/gatt-database.c at master · bluez/bluez · GitHub
> >
> > Here is the commit that added support for it which specifically targets BI-34-C:
> >
> > gatt: Add implementation of link option · bluez/bluez@e577e47 · GitHub
> >
>
> Many thanks for the info! If I understand this correctly, is the idea to implement a custom GATT server with two characteristics, where you check link_type in ReadValue to only allow BR/EDR for one of the characteristics, and LE for the other? And if the wrong transport is used you respond with the error the test expects?

Yeah, we could perhaps add support for something like that into
bluetoothctl directly so we could have a script registering the
attributes and then responding based on the link type.

> If so, I will try doing this and report back the result if it passes the tests, just for future reference to other poor people that run into this issue :)

Yeah, btw you might be interested in the following discussion as well
if you are actually planning on qualifying BlueZ:

https://github.com/orgs/bluez/discussions/817

> > > > If so, how can one pass these BT SIG tests? In the previous thread I linked, the "solution" seemed to be to write an application that simply rejects the read request for a certain transport, but this seems like more of a hack than a solution to me. Is there any other solution?
> > > >
> > > > Very thankful for any thoughts!
> > > >
> > > > Best regards,
> > > > Alexander
> > >
> > >
> > >
> > > --
> > > Luiz Augusto von Dentz
> >
> >
> >
> > --
> > Luiz Augusto von Dentz
>
> BR,
> Alexander



-- 
Luiz Augusto von Dentz





[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux