Hi Petri, On Wed, Nov 30, 2016 at 10:36 AM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > 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. Checking the code I did not find anything that could have break the remote services, or perhaps it is the passive scanning/reconnection logic that gets broken if we failed to discover the services? -- 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
