Notify problem in gatt plugin

DISCUSSION Mathieu Ocaña 2 participants 4 messages Jan 19, 2015 – Jan 28, 2015 Bluetooth drivers

Share & tools

Mathieu Ocaña

author

2015-01-19 16:20 UTC #0 lore raw

Hello,

I'm currently working on a plugin to implement a GATT peripheral. Based on the plugins/gatt-example and the profiles/alert/server, I finally got something which works: read, write, with dbus signaling. But, notifications doesn't work...
All seems ok until the call to "g_attrib_send()".

Quoted 10 lines

Quoted 10 lines
static void attio_connected_cb(GAttrib *attrib, gpointer user_data) {
[...]
len = enc_notification(p_adapter->batterylevel_chr.level_hnd_value,
                    nd->value, nd->len, pdu, len);
[...]
ret = g_attrib_send(attrib, 0, pdu, len, destroy_notify_callback,
cb, NULL);
return;
}

The parameters passed to g_attrib_send seems valid, I have verified the pdu, len and user_data, but I'm not sure to understand well all the fields of "attrib" (struct _GAttrib). Moreover the return value is 0.

Some extra details:
- the destroy_notify_callback is not called (maybe normal as the notification is not succesfully sent).
- in g_attrib_send, the call to bt_att_send() return 0. After this point my understanding of the source code became a little bit fuzzy.

Quoted 1 line

It would be great if someone could suggest me a fix or a workaround.

I have also developped some extensions for the function gatt_service_add(), such as the support of static value characteristic, and the descriptors for presentation format, valid range and user description.

Quoted 1 line

Before submitting this patch, I want to know which is the patch policy for the bluez project? (validation test to perform, etc.).

Regards,

Signature · 1 line

Mathieu OCAÑA

Luiz Augusto von Dentz

maintainer

2015-01-20 09:30 UTC #1 lore raw

Hi Mathieu,

Quoted 24 lines · Mathieu Ocaña

Hello,
I'm currently working on a plugin to implement a GATT peripheral. Based on the plugins/gatt-example and the profiles/alert/server, I finally got something which works: read, write, with dbus signaling.
But, notifications doesn't work...
All seems ok until the call to "g_attrib_send()".
Quoted 10 lines
Quoted 10 lines
static void attio_connected_cb(GAttrib *attrib, gpointer user_data) {
[...]
len = enc_notification(p_adapter->batterylevel_chr.level_hnd_value,
                    nd->value, nd->len, pdu, len);
[...]
ret = g_attrib_send(attrib, 0, pdu, len, destroy_notify_callback,
cb, NULL);
return;
}
The parameters passed to g_attrib_send seems valid, I have verified the pdu, len and user_data, but I'm not sure to understand well all the fields of "attrib" (struct _GAttrib). Moreover the return value is 0.

Quoted 5 lines

Some extra details:
- the destroy_notify_callback is not called (maybe normal as the notification is not succesfully sent).
- in g_attrib_send, the call to bt_att_send() return 0. After this point my understanding of the source code became a little bit fuzzy.

You might not be connected then so perhaps there is a bug in attio callback. Which version are you using?

Quoted 7 lines

Quoted 1 line
It would be great if someone could suggest me a fix or a workaround.
I have also developped some extensions for the function gatt_service_add(), such as the support of static value characteristic, and the descriptors for presentation format, valid range and user description.
Quoted 2 lines
Before submitting this patch, I want to know which is the patch policy for the bluez project? (validation test to perform, etc.).

It is documented in Submitting patches section in the HACKING:
https://git.kernel.org/cgit/bluetooth/bluez.git/tree/HACKING

Signature · 1 line

Luiz Augusto von Dentz

Mathieu Ocaña

author

2015-01-20 22:44 UTC #2 lore raw

Hi Luiz,

Quoted 26 lines · Luiz Augusto von Dentz

Hi Mathieu,
Quoted 23 lines · Mathieu Ocaña
Hello,
I'm currently working on a plugin to implement a GATT peripheral. Based on the plugins/gatt-example and the profiles/alert/server, I finally got something which works: read, write, with dbus signaling.
But, notifications doesn't work...
All seems ok until the call to "g_attrib_send()".
Quoted 10 lines
Quoted 10 lines
static void attio_connected_cb(GAttrib *attrib, gpointer user_data)
{
   [...]
   len = enc_notification(p_adapter->batterylevel_chr.level_hnd_value,
                     nd->value, nd->len, pdu, len);
   [...]
   ret = g_attrib_send(attrib, 0, pdu, len, destroy_notify_callback,
cb, NULL);
   return;
}
The parameters passed to g_attrib_send seems valid, I have verified the pdu, len and user_data, but I'm not sure to understand well all the fields of "attrib" (struct _GAttrib). Moreover the return value is 0.

Quoted 7 lines

Quoted 5 lines
Some extra details:
- the destroy_notify_callback is not called (maybe normal as the notification is not succesfully sent).
- in g_attrib_send, the call to bt_att_send() return 0. After this point my understanding of the source code became a little bit fuzzy.
You might not be connected then so perhaps there is a bug in attio callback. Which version are you using?

I'm using the v5.27. I see no signs of disconnection in the debug messages, but I will explore this lead.
For now I use a Nordic dongle & software (master panel monitor) for my tests and the connection seems ok (even if the notificatons are not sent, the read/write operation are performed witout problem). But when I use gatttool I'm disconnected constantly after 5-15s, (in this case the debug log tells me it). I have not yet tested with a BT LE-enabled smartphone, but if I'm also disconnected, maybe the two problems are related.

Quoted 8 lines

Quoted 6 lines
Quoted 1 line
It would be great if someone could suggest me a fix or a workaround.
I have also developped some extensions for the function gatt_service_add(), such as the support of static value characteristic, and the descriptors for presentation format, valid range and user description.
Quoted 2 lines
Before submitting this patch, I want to know which is the patch policy for the bluez project? (validation test to perform, etc.).
It is documented in Submitting patches section in the HACKING:
https://git.kernel.org/cgit/bluetooth/bluez.git/tree/HACKING

Ok, I had totally forgotten this file. According to the coding standards, I've some modifications to do.
The answer is maybe obvious, but if I modify the behavior of the function gatt_service_add(), I should also patch the profiles and plugins which use it, accordingly?

Thank for your answer,

--
Mathieu OCAÑA

Mathieu Ocaña

author

2015-01-28 01:33 UTC #3 lore raw

Re: Notify problem in gatt plugin - solved

I have finally solved the problem.

For interested people, the notification mechanism showed in the alert-server (profiles/alert/server.c), which I used as starting point, is broken.

In src/shared/att.c:L306, a test condition prevents the sending of the data if a callback is defined but not needed (and it is the case for a notification).

So in my plugin source code, in attio_connected_cb(), by simply changing:

Quoted 1 line

ret = g_attrib_send(attrib, 0, pdu, len, destroy_notify_callback, cb, NULL);

to:

Quoted 1 line

ret = g_attrib_send(attrib, 0, pdu, len, NULL, NULL, NULL);

the notifications are now sent :)

Of course, the same change will fix the alert-server.

--
Mathieu OCAÑA

Quoted 62 lines · Mathieu Ocaña

Hi Luiz,
Quoted 27 lines · Luiz Augusto von Dentz
Hi Mathieu,
Quoted 24 lines · Mathieu Ocaña
Hello,
I'm currently working on a plugin to implement a GATT peripheral. Based on the plugins/gatt-example and the profiles/alert/server, I finally got something which works: read, write, with dbus signaling.
But, notifications doesn't work...
All seems ok until the call to "g_attrib_send()".
Quoted 11 lines
Quoted 11 lines
static void attio_connected_cb(GAttrib *attrib, gpointer user_data)
{
   [...]
   len = 
enc_notification(p_adapter->batterylevel_chr.level_hnd_value,
                     nd->value, nd->len, pdu, len);
   [...]
   ret = g_attrib_send(attrib, 0, pdu, len, destroy_notify_callback,
cb, NULL);
   return;
}
The parameters passed to g_attrib_send seems valid, I have verified the pdu, len and user_data, but I'm not sure to understand well all the fields of "attrib" (struct _GAttrib). Moreover the return value is 0.
Quoted 8 lines
Quoted 6 lines
Some extra details:
- the destroy_notify_callback is not called (maybe normal as the notification is not succesfully sent).
- in g_attrib_send, the call to bt_att_send() return 0. After this point my
understanding of the source code became a little bit fuzzy.
You might not be connected then so perhaps there is a bug in attio callback. Which version are you using?
I'm using the v5.27. I see no signs of disconnection in the debug messages, but I will explore this lead.
For now I use a Nordic dongle & software (master panel monitor) for my tests and the connection seems ok (even if the notificatons are not sent, the read/write operation are performed witout problem). But when I use gatttool I'm disconnected constantly after 5-15s, (in this case the debug log tells me it). I have not yet tested with a BT LE-enabled smartphone, but if I'm also disconnected, maybe the two problems are related.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
It would be great if someone could suggest me a fix or a workaround.
I have also developped some extensions for the function gatt_service_add(), such as the support of static value characteristic, and the descriptors for presentation format, valid range and user description.
Quoted 2 lines
Before submitting this patch, I want to know which is the patch policy for the bluez project? (validation test to perform, etc.).
It is documented in Submitting patches section in the HACKING:
https://git.kernel.org/cgit/bluetooth/bluez.git/tree/HACKING
Ok, I had totally forgotten this file. According to the coding standards, I've some modifications to do.
The answer is maybe obvious, but if I modify the behavior of the function gatt_service_add(), I should also patch the profiles and plugins which use it, accordingly?
Thank for your answer,
Signature · 6 lines
Mathieu OCAÑA

-- 
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html