Hi Scott, > > > This adds plugin support for a callback called when bonding completes, > > > either successfully or fails, or is cancelled. In the success or failure > > > cases the callback may return TRUE, in which case the bonding is retried > > > after a short backoff period. > > > > > yesterday Johan and talked about this a little bit and I just wanna > > quickly iterate some small comments here. > > > Great! > > > So we should only allow retrying when we initiated the bonding. If the > > other side started the pairing, then retrying should not even be > > considered. > > > I thought I put a check in for that, but I've just realized that after > I separated out the autopair and the keyboard pairing stuff, that > check ended up only in the keyboard pairing side. > > My intent was this entire path should be only when the host initiated > the bonding, not the client. to be honest, I did not get further into actually checking the code itself. I just wanted to ensure we are on the same and expecting how this is suppose to work ;) > > We have to also ensure that we do not disconnect the ACL in between the > > retry attempts. Otherwise some car kits might cancel their pairing > > procedure and you have to have user interaction to get it back into > > pairing mode. So if the ACL gets disconnect, then we should just fail > > and cancel the bonding. > > > In my testing, OS X/iOS drop the ACL between retry attempts - so we > wouldn't be any worse than they are. I'm not sure whether it's even > possible in bluez to avoid dropping the ACL? Is Apple doing retried pairing (or auto-pairing) as well? Strictly speaking the ACL disconnect is host stack triggered. So you have HCI_Authentication_Requested and you can just execute that again with the same link. We also do have a ACL disconnect timeout handling of 2 seconds that will allow sockets to re-use the same ACL link. Can you provide some hcidump traces from your test cases? Regards Marcel -- 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
