Bluetooth pairing panics every time following unpairing
Posted: Thu Jun 22, 2023 10:46 am
I’m working on a Bluetooth (NimBLE stack) device that uses pairing. I took a device that had been working fine a day ago and unpaired it using its external button (which calls ble_gap_unpair_oldest_peer()). Then, when I tried to pair again, it connected but panicked and disconnected shortly after initiating pairing, not getting far enough to ask me to enter the pairing passkey. After repeating this many times, including on different computers and with different central devices, this happened every time.
I have attached a screenshot of the stack after I had paused the debugger after the issue (for some reason it would not automatically pause when it panicked). Clearly this is something to do with the security manager and seems to be happening when the device receives some data.
Furthermore, when I tried pairing with the device today, after not doing anything to it, the issue has mysteriously gone and the device is pairing and working fine.
Does anyone have any ideas as to what may be happening here? It’s worrying that this can happen seemingly during normal operation (i.e. using the unpairing functionality) and we can’t have this happen when the device is in the field. Could it be that the original unpairing failed and left some remnants that caused any further pairings to be unable to succeed? Further calls to ble_gap_unpair_oldest_peer() returned BLE_HS_ENOENT (as would be expected after successful unpairing).
Thanks.
I have attached a screenshot of the stack after I had paused the debugger after the issue (for some reason it would not automatically pause when it panicked). Clearly this is something to do with the security manager and seems to be happening when the device receives some data.
Furthermore, when I tried pairing with the device today, after not doing anything to it, the issue has mysteriously gone and the device is pairing and working fine.
Does anyone have any ideas as to what may be happening here? It’s worrying that this can happen seemingly during normal operation (i.e. using the unpairing functionality) and we can’t have this happen when the device is in the field. Could it be that the original unpairing failed and left some remnants that caused any further pairings to be unable to succeed? Further calls to ble_gap_unpair_oldest_peer() returned BLE_HS_ENOENT (as would be expected after successful unpairing).
Thanks.