Non-consecutive handle values in GATT

[Andrejs Hanins <andrejs.hanins@ubnt.com>]

Hello,

     I'm experimenting with an LE peripheral device which provides GATT 
services described by attributes with non-consecutive handle values, 
i.e. there are "gaps" between handle values. According to the Bluetooth 
Core specification 4.0 (Volume 3, Part G, "2.5.1 Overview") it is allowed:

      Although the Attribute Handle values are in increasing order, 
following Attribute Handle values may differ by more than one.

     Based on my experiments, BlueZ 5.28 and also git-master as of today 
does not support non-consecutive handle values GATT table. As a result, 
I can't connect to my device because gatt-client fails to initialize 
properly. The failing place is in discover_descs():

       if (gatt_db_attribute_get_handle(attr) !=
                             chrc_data->value_handle)
             goto failed;

     The value of chrc_data->value_handle is correct and matches GATT 
table one the device, but the attr->handle has the value of previous 
attribute (Primary Service UUID in my case) +2. This handle value 
calculation happens in gatt_db_service_add_characteristic() which has 
strange code:

     /* We set handle of characteristic value, which will be added next */
     put_le16(get_handle_at_index(service, i - 1) + 2, &value[1]);

     Before trying to fix the problem by myself it would be great to 
hear some comments about this issue. Does it seem like a bug or I missed 
something?

     As a note, I can successfully connect to my LE peripheral from an 
iPhone LightBlue app, which does not posses any issues during GATT 
discovery and can read/write the characteristic on the device.


BR, Andrey