Hi Petri, > > This primary services re-discovery on every reconnect is actually now > causing a problem for us. > > Basically, this is what happens: > 1. HoG remote control reconnects to BlueZ host for firmware update check. > 2. BlueZ starts re-discovering the services of the remote, but doesn't > yet complete it. > 3. The remote disconnects after being connected for 2 seconds (no > firmware update was available, so quickly disconnect to save battery). > 4. BlueZ declares the HoG remote "bad" since it couldn't complete step > (2). And then, BlueZ ends up removing the HoG remote services from its > GATT database completely. > 5. On the next reconnect attempt, the remote does not work. Re-pairing > is required. > > Obviously, this is bad for user experience. Therefore, I'm asking: > 1. Is there a way to avoid services re-discovery on every reconnect? > 2. If the remote control is successfully bonded previously, and BlueZ > experiences a problem during reconnect (services re-discovery), can we > avoid destroying the bonding and GATT info on BlueZ side? A failed > reconnect should not be a reason to remove a bonded device. The second point should definitely be fixed, but I wonder how the firmware update check does actually detects if the host is not doing something important before it decides it has to save power. Also if I recall this correctly dfu was exactly why some devices needed the database check, they boot in dfu mode which has a different database but they completely lost the state of service changed subscriptions so basically nothing works since all handles are invalid and even if service changed would work it would cause a rediscover anyway. -- 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
