ufocia
commented
1 year ago I hope the HTML tables below are visible to everyone.
I'm experiencing a similar problem, as are others, e.g. here. Admittedly, I have not performed as much debugging as the OP.
At first glance of OP's debug it appears that there is a fatal mismatch between the pairing requests and responses in the Android case. The two AN33BLE are a perfect match for each other, as far as I can tell. Please observe:
2 x AN33BLE: Connection 1 - pairing request received: use_oob = false, authentication = 11, initiator_dist = 03, responder_dist = 03 ... Connection 1 - Send pairing response: oob = false, auth = 11, initiator dist = 03, responder dist = 03 ... stack_handler received DM_SEC_ENCRYPT_IND ... (encryption negotiated)
Android + AN33BLE Connection 1 - pairing request received: use_oob = false, authentication = 2D, initiator_dist = 0F, responder_dist = 0F ... Connection 1 - Send pairing response: oob = false, auth = 11, initiator dist = 03, responder dist = 03 ... stack_handler received DM_SEC_PAIR_FAIL_IND ... (more or less the end of the road)
The flow for the Andrid case looks very similar to BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part H, C.5.2 Central rejects pairing because of key size.
I decoded the Android + AN33BLE Authentication requirements flags (auth) according to the table in BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part H Figure 3.3: Authentication requirements flags (pg. 1601):
| LSB | | | | | | | MSB | Hex -- | -- | -- | -- | -- | -- | -- | -- | -- | -- Device | Bond[1] | Bond[2] | MITM | SC | Keypress | CT2 | RFU[1] | RFU[2] | Android | 1 | 0 | 1 | 1 | 0 | 1 | 0 | 0 | 2D AN33BLE | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 11I also decoded the the Android + AN33BLE Initiator Key Distribution/Generation field and Responder Key Distribution/Generation field (initiator dist and responder dist respectively) according to the table in BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part H Figure 3.11: LE Key Distribution format (pg. 1610):
| LSB | | | | | | | MSB | Hex -- | -- | -- | -- | -- | -- | -- | -- | -- | -- Device | EncKey | IdKey | SignKey | LinkKey | RFU[1] | RFU[2] | RFU[3] | RFU[4] | Android | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | F AN33BLE | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 3I just started digging into this, so I'm not sure how much of this is implementation versus merely configuration. Could someone with a bit more experience/expertise please chime in?
Description of defect
Running the SecurityandPrivacy BLE example demonstrating Security Manager implementation only works with 2 microcontrollers doing the demo. Pairing process fails with error code 'SEC_STATUS_UNSPECIFIED' (0x88) in pairingResult when attempting to pair from Android 12 or iOS as masters. The SecurityandPrivacy was slightly modified to run only as a peripheral in an Arduino Nano 33 BLE (nrf52840). Traces were enabled but does not give additional information about the problem (error code: DM_SEC_PAIR_FAIL_IND ). The same error occurs when securityManager is initialized with static passkey and SecurityManager::IO_CAPS_DISPLAY_ONLY On the master side an incorrect pin error pops up a few seconds after accepting pairing 2 times.
Target(s) affected by this defect ?
Arduino Nano 33 BLE (nrf58240)
Toolchain(s) (name and version) displaying this defect ?
arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi
What version of Mbed-os are you using (tag or sha) ?
mbed-os-6.14
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
Uploading firmware to target with Arduino IDE, mbed source code is compiled with script https://github.com/arduino/ArduinoCore-mbed
How is this defect reproduced ?
After uploading the code, the example works correctly with a second board running SecurityandPrivacy example as a master, but trying to connect with Android phone or iPhone does not work. Traces for both cases are attached. traces pairing 2 boards AN33BLE.txt traces pairing Android.txt
https://github.com/ARMmbed/mbed-os-example-ble/tree/development/BLE_SecurityAndPrivacy