* Running GATT/SR/GAI/BV-01-C and GATT/SR/GAI/BV-02-C tests
@ 2026-02-11 13:17 Christian Eggers
2026-02-11 18:30 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 3+ messages in thread
From: Christian Eggers @ 2026-02-11 13:17 UTC (permalink / raw)
To: linux-bluetooth, frederic.danis
According to Frédéric's instruction [1], GATT/SR/GAI/BV-01-C should executed
with a custom service/characteristic added via bluetootctl:
+------------------------+----------+---------+-------+-------------------------------------------------------------------------+
| GATT/SR/GAI/BV-01-C | PASS | 6.1 | 5.69 | Run 'bluetoothctl': |
| | | | | |
| | | | | - [bluetooth]# gatt.register-service 0xFFFF |
| | | | | |
| | | | | - *yes* when asked if primary service |
| | | | | |
| | | | | - [bluetooth]# gatt.register-characteristic 0xAAAA read,write |
| | | | | |
| | | | | - enter '1' when prompted |
| | | | | |
| | | | | - [bluetooth]# gatt.register-application |
+------------------------+----------+---------+-------+-------------------------------------------------------------------------+
With the current PTS, the test is being stuck waiting for on indication on the
characteristic with the handle 0x0008:
> Please send an Handle Value indication handle = '0008'O after enabled by the
> PTS.
>
> Description: Verify that the Implementation Under Test (IUT) can send handle
> value notification to the PTS.
According to btmon, this is the "Service Changed" characteristic,
which is automatically created by bluetoothd in populate_gatt_service().
bluetoothd[511]: < ACL Data TX: Handle 24 flags 0x00 dlen 27 #36 [hci0] 1187.212787
ATT: Read By Type Response (0x09) len 22
Attribute data length: 7
Attribute data list: 3 entries
...
Handle: 0x0007
Value[5]:
20 08 00 05 2a ...*
Properties: 0x20
Indicate (0x20)
Value Handle: 0x0008
Value UUID: Service Changed (0x2a05)
It looks like the testcase doesn't use the characteristic (0xAAAA) set up via
bluetoothctl at all. Instead it seems to pick up the first characteristic
returned by READ_BY_TYPE which has the 'Indicate' (0x20) property.
After comparing with the instructions for other tests, it looks like I need
to use 'btgatt-server' for manually sending the notification.
Q1: How does btgatt-server interfere with bluetoothd? I guess that both are
listening on the same CID? It looks like btgatt-server has precedence in
accepting new connections, but how does this work?
Instead of following the bluetootctl based setup, I then ran btgatt-server and
sent the notification manually. But there is another check in the testcase
which disconnects/reconnects the ACL and verifies that the client configuration
descriptor has been reset to 0 (GATT/SR/GAI/BV-01-C, no bonding) or been kept
at 2 (GATT/SR/GAI/BV-02-C, with bonding):
> 4.8.2 Characteristic Value Indication - by Server
> • Test Purpose
> Verify that a Generic Attribute Profile server can send a Characteristic
> Value Indication and that it retains or resets the configured CCCD after
> disconnection and reconnection depending on bonding.
After reconnection, GATT/SR/GAI/BV-01-C fails because btgatt-server has
exited on disconnect and the consecutive READ_REQUEST is processed by
bluetoothd (instead of btgatt-server), where the CCCD handle (cached by PTS)
points to another characteristic (which of course doesn't contain the
expected value).
Immediately restarting btgatt-server can fix this, but it feels like this
defends the purpose of this unit test.
Q2: Are there plans to implement "manual sending of notifications by handle"
in bluetoothd/bluetootctl?
In order to process with GATT/SR/GAI/BV-02-C, I modified btgatt-server in a
way that it accepts further ATT connections after disconnect instead of
exiting. Although the PTS test is happy (due to the retained value of the
CCCD's value), it feels wrong to me to reimplement the lifecycle of the CCCD's
value within btgatt-server instead of testing with the "real" implementation.
Any idea how can "improve" execution of this tests?
regards,
Christian
[1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/qualification/gatt-pts.rst#n1106
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Running GATT/SR/GAI/BV-01-C and GATT/SR/GAI/BV-02-C tests
2026-02-11 13:17 Running GATT/SR/GAI/BV-01-C and GATT/SR/GAI/BV-02-C tests Christian Eggers
@ 2026-02-11 18:30 ` Luiz Augusto von Dentz
2026-02-24 19:21 ` Christian Eggers
0 siblings, 1 reply; 3+ messages in thread
From: Luiz Augusto von Dentz @ 2026-02-11 18:30 UTC (permalink / raw)
To: Christian Eggers; +Cc: linux-bluetooth, frederic.danis
Hi Christian, Frederic,
On Wed, Feb 11, 2026 at 8:17 AM Christian Eggers <ceggers@arri.de> wrote:
>
> According to Frédéric's instruction [1], GATT/SR/GAI/BV-01-C should executed
> with a custom service/characteristic added via bluetootctl:
>
> +------------------------+----------+---------+-------+-------------------------------------------------------------------------+
> | GATT/SR/GAI/BV-01-C | PASS | 6.1 | 5.69 | Run 'bluetoothctl': |
> | | | | | |
> | | | | | - [bluetooth]# gatt.register-service 0xFFFF |
> | | | | | |
> | | | | | - *yes* when asked if primary service |
> | | | | | |
> | | | | | - [bluetooth]# gatt.register-characteristic 0xAAAA read,write |
> | | | | | |
> | | | | | - enter '1' when prompted |
> | | | | | |
> | | | | | - [bluetooth]# gatt.register-application |
> +------------------------+----------+---------+-------+-------------------------------------------------------------------------+
>
> With the current PTS, the test is being stuck waiting for on indication on the
> characteristic with the handle 0x0008:
>
> > Please send an Handle Value indication handle = '0008'O after enabled by the
> > PTS.
> >
> > Description: Verify that the Implementation Under Test (IUT) can send handle
> > value notification to the PTS.
>
> According to btmon, this is the "Service Changed" characteristic,
> which is automatically created by bluetoothd in populate_gatt_service().
Hmm, it looks like this was done to avoid manually generating an
indication, so service changed was used, or perhaps the purpose is to
test the service changed behavior.
> bluetoothd[511]: < ACL Data TX: Handle 24 flags 0x00 dlen 27 #36 [hci0] 1187.212787
> ATT: Read By Type Response (0x09) len 22
> Attribute data length: 7
> Attribute data list: 3 entries
> ...
> Handle: 0x0007
> Value[5]:
> 20 08 00 05 2a ...*
> Properties: 0x20
> Indicate (0x20)
> Value Handle: 0x0008
> Value UUID: Service Changed (0x2a05)
>
> It looks like the testcase doesn't use the characteristic (0xAAAA) set up via
> bluetoothctl at all. Instead it seems to pick up the first characteristic
> returned by READ_BY_TYPE which has the 'Indicate' (0x20) property.
Well it is a Read By Type what is the type? If it is 0x2a05 perhaps
the intent is test service changed behavior, not an indication of a
specific characteristic/handle. Do you register after connecting or
before? If registration happens before connecting, it would probably
explain why it fails, as no indication would be sent then.
> After comparing with the instructions for other tests, it looks like I need
> to use 'btgatt-server' for manually sending the notification.
>
> Q1: How does btgatt-server interfere with bluetoothd? I guess that both are
> listening on the same CID? It looks like btgatt-server has precedence in
> accepting new connections, but how does this work?
I would go in the direction of using btgatt-server, that probably
doesn't know how to handle service changed at all.
> Instead of following the bluetootctl based setup, I then ran btgatt-server and
> sent the notification manually. But there is another check in the testcase
> which disconnects/reconnects the ACL and verifies that the client configuration
> descriptor has been reset to 0 (GATT/SR/GAI/BV-01-C, no bonding) or been kept
> at 2 (GATT/SR/GAI/BV-02-C, with bonding):
>
> > 4.8.2 Characteristic Value Indication - by Server
> > • Test Purpose
> > Verify that a Generic Attribute Profile server can send a Characteristic
> > Value Indication and that it retains or resets the configured CCCD after
> > disconnection and reconnection depending on bonding.
>
> After reconnection, GATT/SR/GAI/BV-01-C fails because btgatt-server has
> exited on disconnect and the consecutive READ_REQUEST is processed by
> bluetoothd (instead of btgatt-server), where the CCCD handle (cached by PTS)
> points to another characteristic (which of course doesn't contain the
> expected value).
>
> Immediately restarting btgatt-server can fix this, but it feels like this
> defends the purpose of this unit test.
>
> Q2: Are there plans to implement "manual sending of notifications by handle"
> in bluetoothd/bluetootctl?
>
> In order to process with GATT/SR/GAI/BV-02-C, I modified btgatt-server in a
> way that it accepts further ATT connections after disconnect instead of
> exiting. Although the PTS test is happy (due to the retained value of the
> CCCD's value), it feels wrong to me to reimplement the lifecycle of the CCCD's
> value within btgatt-server instead of testing with the "real" implementation.
>
> Any idea how can "improve" execution of this tests?
>
> regards,
> Christian
>
> [1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/qualification/gatt-pts.rst#n1106
>
>
>
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Running GATT/SR/GAI/BV-01-C and GATT/SR/GAI/BV-02-C tests
2026-02-11 18:30 ` Luiz Augusto von Dentz
@ 2026-02-24 19:21 ` Christian Eggers
0 siblings, 0 replies; 3+ messages in thread
From: Christian Eggers @ 2026-02-24 19:21 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth, frederic.danis
Hi Luiz, hi Frederic,
On Wednesday, 11 February 2026, 19:30:34 CET, Luiz Augusto von Dentz wrote:
> Hi Christian, Frederic,
>
> On Wed, Feb 11, 2026 at 8:17 AM Christian Eggers <ceggers@arri.de> wrote:
> >
> > According to Frédéric's instruction [1], GATT/SR/GAI/BV-01-C should executed
> > with a custom service/characteristic added via bluetootctl:
> >
> > +------------------------+----------+---------+-------+-------------------------------------------------------------------------+
> > | GATT/SR/GAI/BV-01-C | PASS | 6.1 | 5.69 | Run 'bluetoothctl': |
> > | | | | | |
> > | | | | | - [bluetooth]# gatt.register-service 0xFFFF |
> > | | | | | |
> > | | | | | - *yes* when asked if primary service |
> > | | | | | |
> > | | | | | - [bluetooth]# gatt.register-characteristic 0xAAAA read,write |
> > | | | | | |
> > | | | | | - enter '1' when prompted |
> > | | | | | |
> > | | | | | - [bluetooth]# gatt.register-application |
> > +------------------------+----------+---------+-------+-------------------------------------------------------------------------+
> >
> > With the current PTS, the test is being stuck waiting for on indication on the
> > characteristic with the handle 0x0008:
> >
> > > Please send an Handle Value indication handle = '0008'O after enabled by the
> > > PTS.
> > >
> > > Description: Verify that the Implementation Under Test (IUT) can send handle
> > > value notification to the PTS.
> >
> > According to btmon, this is the "Service Changed" characteristic,
> > which is automatically created by bluetoothd in populate_gatt_service().
>
> Hmm, it looks like this was done to avoid manually generating an
> indication, so service changed was used, or perhaps the purpose is to
> test the service changed behavior.
Yes, using an already existing "standard" characteristic which can generate
indications may be the reason for using "Service Changed".
>
> > bluetoothd[511]: < ACL Data TX: Handle 24 flags 0x00 dlen 27 #36 [hci0] 1187.212787
> > ATT: Read By Type Response (0x09) len 22
> > Attribute data length: 7
> > Attribute data list: 3 entries
> > ...
> > Handle: 0x0007
> > Value[5]:
> > 20 08 00 05 2a ...*
> > Properties: 0x20
> > Indicate (0x20)
> > Value Handle: 0x0008
> > Value UUID: Service Changed (0x2a05)
> >
> > It looks like the testcase doesn't use the characteristic (0xAAAA) set up via
> > bluetoothctl at all. Instead it seems to pick up the first characteristic
> > returned by READ_BY_TYPE which has the 'Indicate' (0x20) property.
>
> Well it is a Read By Type what is the type? If it is 0x2a05 perhaps
> the intent is test service changed behavior, not an indication of a
> specific characteristic/handle.
> Do you register after connecting or
> before? If registration happens before connecting, it would probably
> explain why it fails, as no indication would be sent then.
That is the point! Simply deferring registration of the GATT application until
PTS asks for sending the indication solves all my problems! This works fine with
GATT/SR/GAI/BV-01-C and GATT/SR/GAI/BV-02-C.
Thank you very much for nudging me into the right direction! I'll send patches
for the qualification documentation tomorrow.
regards,
Christian
>
> > After comparing with the instructions for other tests, it looks like I need
> > to use 'btgatt-server' for manually sending the notification.
> >
> > Q1: How does btgatt-server interfere with bluetoothd? I guess that both are
> > listening on the same CID? It looks like btgatt-server has precedence in
> > accepting new connections, but how does this work?
>
> I would go in the direction of using btgatt-server, that probably
> doesn't know how to handle service changed at all.
>
> > Instead of following the bluetootctl based setup, I then ran btgatt-server and
> > sent the notification manually. But there is another check in the testcase
> > which disconnects/reconnects the ACL and verifies that the client configuration
> > descriptor has been reset to 0 (GATT/SR/GAI/BV-01-C, no bonding) or been kept
> > at 2 (GATT/SR/GAI/BV-02-C, with bonding):
> >
> > > 4.8.2 Characteristic Value Indication - by Server
> > > • Test Purpose
> > > Verify that a Generic Attribute Profile server can send a Characteristic
> > > Value Indication and that it retains or resets the configured CCCD after
> > > disconnection and reconnection depending on bonding.
> >
> > After reconnection, GATT/SR/GAI/BV-01-C fails because btgatt-server has
> > exited on disconnect and the consecutive READ_REQUEST is processed by
> > bluetoothd (instead of btgatt-server), where the CCCD handle (cached by PTS)
> > points to another characteristic (which of course doesn't contain the
> > expected value).
> >
> > Immediately restarting btgatt-server can fix this, but it feels like this
> > defends the purpose of this unit test.
> >
> > Q2: Are there plans to implement "manual sending of notifications by handle"
> > in bluetoothd/bluetootctl?
> >
> > In order to process with GATT/SR/GAI/BV-02-C, I modified btgatt-server in a
> > way that it accepts further ATT connections after disconnect instead of
> > exiting. Although the PTS test is happy (due to the retained value of the
> > CCCD's value), it feels wrong to me to reimplement the lifecycle of the CCCD's
> > value within btgatt-server instead of testing with the "real" implementation.
> >
> > Any idea how can "improve" execution of this tests?
> >
> > regards,
> > Christian
> >
> > [1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/qualification/gatt-pts.rst#n1106
> >
> >
> >
>
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-02-24 19:21 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-11 13:17 Running GATT/SR/GAI/BV-01-C and GATT/SR/GAI/BV-02-C tests Christian Eggers
2026-02-11 18:30 ` Luiz Augusto von Dentz
2026-02-24 19:21 ` Christian Eggers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox