GATT server does not forward written attribute to application

GATT server does not forward written attribute to application

[Konstantin Forostyan]

Hi,

During Bluetooth Qualification tests with PTS I found out that if an
attribute provided by a GATT server created by BlueZ 5.50 running on my
IUT is written by remote, the value of this attribute is not provided
by 'bluetoothd' to the upper layer. With a minor modification of
'bluetoothd' I managed to get the tests through, so I'd like to get
feedback from the community, whether this modification was necessary or
may be there's another way of getting attribute write working.

For GATT tests I used 'btgatt-server' application provided by BlueZ. In
order to test writing characteristic value I made "Device Name"
provided by the application writable. It turned out, that the
'gap_device_name_write_cb' function that is called by the daemon upon
writing "Device Name" always receives 'value=NULL' and 'len=0'. The
reason for this is that in the 'gatt_db_attribute_write' call in
'prep_write_cb' in 'gatt-server.c' file in 'bluetoothd' both 'value'
and 'len' are hard-coded to NULL and 0 respectively.

With the following modification in 'gatt-server.c' the callback in
'btgatt-server' application receives the arguments it expects and the
GATT tests can be passed:

--- a/src/shared/gatt-server.c	2018-06-01 10:37:36.000000000 +0200
+++ b/src/shared/gatt-server.c	2019-12-13 12:16:58.000000000 +0100
@@ -1291,7 +1291,7 @@
 	pwcd->length = length;
 	pwcd->server = server;
 
-	status = gatt_db_attribute_write(attr, offset, NULL, 0,
+	status = gatt_db_attribute_write(attr, offset, pwcd->pdu + 4,
pwcd->length - 4,
 						BT_ATT_OP_PREP_WRITE_RE
Q,
 						server->att,
 						prep_write_complete_cb,
pwcd);


Best regards
Konstantin

Re: GATT server does not forward written attribute to application

[Luiz Augusto von Dentz]

Hi Konstantin,

On Wed, Dec 18, 2019 at 2:36 AM Konstantin Forostyan
<konstantin.forostyan@peiker-cee.de> wrote:
>
> Hi,
>
> During Bluetooth Qualification tests with PTS I found out that if an
> attribute provided by a GATT server created by BlueZ 5.50 running on my
> IUT is written by remote, the value of this attribute is not provided
> by 'bluetoothd' to the upper layer. With a minor modification of
> 'bluetoothd' I managed to get the tests through, so I'd like to get
> feedback from the community, whether this modification was necessary or
> may be there's another way of getting attribute write working.
>
> For GATT tests I used 'btgatt-server' application provided by BlueZ. In
> order to test writing characteristic value I made "Device Name"
> provided by the application writable. It turned out, that the
> 'gap_device_name_write_cb' function that is called by the daemon upon
> writing "Device Name" always receives 'value=NULL' and 'len=0'. The
> reason for this is that in the 'gatt_db_attribute_write' call in
> 'prep_write_cb' in 'gatt-server.c' file in 'bluetoothd' both 'value'
> and 'len' are hard-coded to NULL and 0 respectively.

Well not actually a write but a prepare write, so until execute is
called nothing shall be written, so except if I missing something this
is the correct behaviour, if you need that for authorizing the prepare
the you should look into:

https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt#n104
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt#n273

> With the following modification in 'gatt-server.c' the callback in
> 'btgatt-server' application receives the arguments it expects and the
> GATT tests can be passed:
>
> --- a/src/shared/gatt-server.c  2018-06-01 10:37:36.000000000 +0200
> +++ b/src/shared/gatt-server.c  2019-12-13 12:16:58.000000000 +0100
> @@ -1291,7 +1291,7 @@
>         pwcd->length = length;
>         pwcd->server = server;
>
> -       status = gatt_db_attribute_write(attr, offset, NULL, 0,
> +       status = gatt_db_attribute_write(attr, offset, pwcd->pdu + 4,
> pwcd->length - 4,
>                                                 BT_ATT_OP_PREP_WRITE_RE
> Q,
>                                                 server->att,
>                                                 prep_write_complete_cb,
> pwcd);
>
>
> Best regards
> Konstantin
>


-- 
Luiz Augusto von Dentz

Re: GATT server does not forward written attribute to application

[Konstantin Forostyan]

Hi Luiz,

Thank you for the answer and sorry for using wrong term, yes, it's
about prepare write.

> is the correct behaviour, if you need that for authorizing the
> prepare
Do you mean, I have to add "authorize" flag to the characteristic's
properties in order to enable writing, even if I'm not using any
security mechanisms? Please note that 'btgatt-server' application does
not use D-Bus API.

I'm sorry for my comments that may sound stupid, I'm quite new to
Bluetooth LE.

Best regards,
Konstantin


On Wed, 2019-12-18 at 11:02 -0800, Luiz Augusto von Dentz wrote:
> Hi Konstantin,
> 
> On Wed, Dec 18, 2019 at 2:36 AM Konstantin Forostyan
> <
> konstantin.forostyan@peiker-cee.de
> > wrote:
> > Hi,
> > 
> > During Bluetooth Qualification tests with PTS I found out that if
> > an
> > attribute provided by a GATT server created by BlueZ 5.50 running
> > on my
> > IUT is written by remote, the value of this attribute is not
> > provided
> > by 'bluetoothd' to the upper layer. With a minor modification of
> > 'bluetoothd' I managed to get the tests through, so I'd like to get
> > feedback from the community, whether this modification was
> > necessary or
> > may be there's another way of getting attribute write working.
> > 
> > For GATT tests I used 'btgatt-server' application provided by
> > BlueZ. In
> > order to test writing characteristic value I made "Device Name"
> > provided by the application writable. It turned out, that the
> > 'gap_device_name_write_cb' function that is called by the daemon
> > upon
> > writing "Device Name" always receives 'value=NULL' and 'len=0'. The
> > reason for this is that in the 'gatt_db_attribute_write' call in
> > 'prep_write_cb' in 'gatt-server.c' file in 'bluetoothd' both
> > 'value'
> > and 'len' are hard-coded to NULL and 0 respectively.
> 
> Well not actually a write but a prepare write, so until execute is
> called nothing shall be written, so except if I missing something
> this
> is the correct behaviour, if you need that for authorizing the
> prepare
> the you should look into:
> 
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt#n104
> 
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt#n273
> 
> 
> > With the following modification in 'gatt-server.c' the callback in
> > 'btgatt-server' application receives the arguments it expects and
> > the
> > GATT tests can be passed:
> > 
> > --- a/src/shared/gatt-server.c  2018-06-01 10:37:36.000000000 +0200
> > +++ b/src/shared/gatt-server.c  2019-12-13 12:16:58.000000000 +0100
> > @@ -1291,7 +1291,7 @@
> >         pwcd->length = length;
> >         pwcd->server = server;
> > 
> > -       status = gatt_db_attribute_write(attr, offset, NULL, 0,
> > +       status = gatt_db_attribute_write(attr, offset, pwcd->pdu +
> > 4,
> > pwcd->length - 4,
> >                                                 BT_ATT_OP_PREP_WRIT
> > E_RE
> > Q,
> >                                                 server->att,
> >                                                 prep_write_complete
> > _cb,
> > pwcd);
> > 
> > 
> > Best regards
> > Konstantin
> > 
> 
> 
>