Hi Petri,
On Wed, Nov 9, 2016 at 9:39 PM, Petri Gynther <pgynther@xxxxxxxxxx> wrote:
> Hi linux-bluetooth:
>
> I'm seeing the following issue with BlueZ 5.43 and Linux 4.4.30.
>
> When a previously bonded HoG remote control reconnects to BlueZ 5.43
> host, BlueZ goes ahead and re-discovers the primary services of the
> bonded remote again and again on every reconnect.
>
> Why is this necessary? Shouldn't this information be cached on the
> initial pairing/bonding, and a reconnect can get this information from
> the relevant persistent file, rather than wasting BLE airtime and
> delaying the reconnect?
>
IF, and only if, the cache is restored properly then yes it will work
as you said, but bt_hog is not yet using the gatt_db so it might
rediscover the handles anyway, this happens only once though.
>
>
> In the above log, I see that MTU exchange takes place:
> 15,148467,14484676000,-;bluez: bluetoothd[1985]:
> src/device.c:gatt_debug() MTU exchange complete, with MTU: 23
>
> Looking at the relevant code in src/shared/gatt-client.c, function
> exchange_mtu_cb():
>
> util_debug(client->debug_callback, client->debug_data,
> "MTU exchange complete, with MTU: %u",
> bt_att_get_mtu(client->att));
>
> discover:
> client->discovery_req = bt_gatt_discover_all_primary_services(
> client->att, NULL,
> discover_primary_cb,
> discovery_op_ref(op),
> discovery_op_unref);
>
>
> The call to bt_gatt_discover_all_primary_services() is unconditional,
> whether the device was previously bonded or not.
This does range validation in case service changed is not properly
implemented this will attempt to figure out if there are any changes
in the database, but note that it will stop in here:
attr = gatt_db_insert_service(client->db, start, &uuid, true,
end - start + 1);
if (!attr) {
So if the database already contain all the services it will no do more
than one Read By Group Type.
--
Luiz Augusto von Dentz
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
