Hello all,
I am participating in an effort to make use of the BlueZ libraries to pull
data from Bluetooth Low Energy health devices.
We are working with the 5.8 version of the library, kernel version 3.12.9,
bluetoothctl, and gatttool when we encountered a possible error.
We expected on the reconnection of two bonded devices, one of which had
stored measurements, that data would transfer. When running gatt tool in
medium security the first measurement to be indicated was lost.
First we used Bluetooth control to pair with the simulated agent device (a
thermometer). Then we disconnected with bluetoothctl and connected with
gatttool in order to write to the C3D (client characteristic configuration
descriptors). After setting the C3D to indicate, we transferred a
measurement successfully. ?Up until this point we saw no unexpected
difference in behavior between low and medium security on the gatttool.
However upon attempting to reconnect to the simulated agent device with
medium security two unexpected behaviors occurred. First, and more
immediately apparent was that the simulated agent did not receive a
confirmation of the indication. A slightly closer look using the hcidump,
trying to find what had happened, showed that the indication had arrived at
the hci layer but was not received at events_handler. ?While the indication
is sent very swiftly upon the reconnection of the devices we understand this
to be the manner in which low energy devices are supposed to behave given
stored measurements and a bonded device.
Records of hcidumps are attached.
Caleb Reinhold
P.S. Resending after failing to attach traces
Hi Anderson,
>If I remember correctly, the issue is in the kernel: if connect() is called
when security level is medium,
>the socket only gets POLLOUT once SMP pairing finishes, and any ATT PDU
received during that time is lost.
This is useful and interesting to know.
>Note that it's almost certain that your device is sending the indication
without requiring encryption.
>Otherwise, it would have sent a Security Request (which triggers a Pairing
Request from the Linux side)
>and wait for the encryption to be enabled before sending the indication. If
that was the case,
>the kernel would deliver the ATT PDU to gatttool after encryption is
enabled and it would work as expected.
It seems our device is indeed sending the indication without requiring
encryption. The suggestion of updating the central device to start with low
security and then change to medium security is producing the desired
behavior. Thank you for your time and assistance.
Regards,
Caleb Reinhold
Hi,
On Thu, Feb 6, 2014 at 6:48 PM, Caleb Reinhold
<[email protected]> wrote:
> It seemed that calling g_attrib_register() in the connection callback might
> be causing the client to start listening for indications and notifications
> too late, but registering right after the gatt_connect() call doesn't seem
> to help. Nor does placing a watch on the GIOChannel inside bt_io_connect(),
> so registering earlier doesn't appear to be the right approach. Do you know
> why we keep missing this initial indication on medium security, and how we
> might fix this issue?
If I remember correctly, the issue is in the kernel: if connect() is
called when security level is medium, the socket only gets POLLOUT
once SMP pairing finishes, and any ATT PDU received during that time
is lost.
Note that it's almost certain that your device is sending the
indication without requiring encryption. Otherwise, it would have sent
a Security Request (which triggers a Pairing Request from the Linux
side) and wait for the encryption to be enabled before sending the
indication. If that was the case, the kernel would deliver the ATT PDU
to gatttool after encryption is enabled and it would work as expected.
PS: Please, as common netiquette, avoid top-posting (i.e. answer
before the original message) and quote only the text that gives
context to your answer.
Best Regards,
--
Anderson Lizardo
http://www.indt.org/?lang=en
INdT - Manaus - Brazil
Hi Anderson,
Thanks for your advice. Connecting to the device on low security and then
switching to medium does allow gatttool to receive and confirm the
indication.
Our interest in gatttool is mainly as a demonstration of BlueZ's GATT API.
Our own GATT client application borrows heavily from gatttool and adds
features such as support for multiple simultaneous connections.
It seemed that calling g_attrib_register() in the connection callback might
be causing the client to start listening for indications and notifications
too late, but registering right after the gatt_connect() call doesn't seem
to help. Nor does placing a watch on the GIOChannel inside bt_io_connect(),
so registering earlier doesn't appear to be the right approach. Do you know
why we keep missing this initial indication on medium security, and how we
might fix this issue?
Thanks for your time,
Tom Harada
-----Original Message-----
From: Anderson Lizardo [mailto:[email protected]]
Sent: Tuesday, February 04, 2014 6:06 PM
To: Caleb Reinhold
Cc: BlueZ development
Subject: Re: possible bug in blueZ 5.8 gatt tool or library
Hi Caleb,
On Tue, Feb 4, 2014 at 5:12 PM, Caleb Reinhold
<[email protected]> wrote:
> We are working with the 5.8 version of the library, kernel version
> 3.12.9, bluetoothctl, and gatttool when we encountered a possible error.
> We expected on the reconnection of two bonded devices, one of which
> had stored measurements, that data would transfer. When running gatt
> tool in medium security the first measurement to be indicated was lost.
First of all, gatttool is a developer tool, and it is far from being a
compliant GATT endpoint (e.g. it does not report to requests, which is
mandatory by the spec). With moderate effort though, the missing features
can be added.
> However upon attempting to reconnect to the simulated agent device
> with medium security two unexpected behaviors occurred. First, and
> more immediately apparent was that the simulated agent did not receive
> a confirmation of the indication. A slightly closer look using the
> hcidump, trying to find what had happened, showed that the indication
> had arrived at the hci layer but was not received at events_handler.
Are you using gatttool in interactive mode (i.e. the -I option) ? If yes,
try first connecting to the device with "connect" followed by setting the
security level to medium with "sec-level medium". This will imitate the
behavior of the BlueZ daemon when connecting to LE devices. Also be sure to
use the "--listen" option so the confirmation is sent by gatttool.
Let us know if it works :)
> While the indication
> is sent very swiftly upon the reconnection of the devices we
> understand this to be the manner in which low energy devices are
> supposed to behave given stored measurements and a bonded device.
You are correct that this is the expected behavior. But gatttool is far from
perfect. Did you try implementing a BlueZ plugin?
Best Regards,
--
Anderson Lizardo
http://www.indt.org/?lang=en
INdT - Manaus - Brazil
Hi Caleb,
On Tue, Feb 4, 2014 at 5:12 PM, Caleb Reinhold
<[email protected]> wrote:
> We are working with the 5.8 version of the library, kernel version 3.12.9,
> bluetoothctl, and gatttool when we encountered a possible error.
> We expected on the reconnection of two bonded devices, one of which had
> stored measurements, that data would transfer. When running gatt tool in
> medium security the first measurement to be indicated was lost.
First of all, gatttool is a developer tool, and it is far from being a
compliant GATT endpoint (e.g. it does not report to requests, which is
mandatory by the spec). With moderate effort though, the missing
features can be added.
> However upon attempting to reconnect to the simulated agent device with
> medium security two unexpected behaviors occurred. First, and more
> immediately apparent was that the simulated agent did not receive a
> confirmation of the indication. A slightly closer look using the hcidump,
> trying to find what had happened, showed that the indication had arrived at
> the hci layer but was not received at events_handler.
Are you using gatttool in interactive mode (i.e. the -I option) ? If
yes, try first connecting to the device with "connect" followed by
setting the security level to medium with "sec-level medium". This
will imitate the behavior of the BlueZ daemon when connecting to LE
devices. Also be sure to use the "--listen" option so the confirmation
is sent by gatttool.
Let us know if it works :)
> While the indication
> is sent very swiftly upon the reconnection of the devices we understand this
> to be the manner in which low energy devices are supposed to behave given
> stored measurements and a bonded device.
You are correct that this is the expected behavior. But gatttool is
far from perfect. Did you try implementing a BlueZ plugin?
Best Regards,
--
Anderson Lizardo
http://www.indt.org/?lang=en
INdT - Manaus - Brazil