Hi Manish, > Based on your feedback, in the BlueZ kernel, if we plan to track whether the > link was created because of Pair Device action or not, we'll need to add a > flag in struch hci_conn and update related functions/APIs. I was wondering if > this would look like a clean fix or not. > > Another option could be disconnecting from BlueZ daemon while handling > 'cancel pairing' user request. But the problem with this approach is that > there is no way to request the kernel to send SMP failure PDU with the > existing implementation. > > Third option could be handling this in the chromium and requesting a > disconnect when the user hits the cancel button. I believe Ubuntu/Android are > taking a similar approach. However, on Android, if the 'cancel' button is > selected on the pairing window, it shows 'pairing failed because of invalid > passkey' message. > > Bluetooth specification doesn't have any mention about how to handle the > pairing cancel case. Based on the statistics we have for ChromeOS, over 60% > pairing attempts are cancelled by users. Since the link is not terminated, > the bluetooth keyboard keeps on requesting to enter a new passkey even if the > user selects to cancel the pairing and there is no way to cancel the pairing > process. > > Can you please help me select the better approach to handle the pairing > cancel case? Should we need to propose this to be addressed in the Bluetooth > Specification as well?
are we sending Cancel Pairing correctly? If so and we only care about the cancel case, then I would just track if the connection was triggered by a pairing and then only cancel pairing terminate the connection. Regards Marcel
