BLE ANCS Pairing Issue with ESP32 (Error Code: 0x66/102) (IDFGH-14177) #14977
Comments
github-actions
bot
changed the title
|
Based on your log, the reason for the SMP failure is 0x66, which indicates an SMP timeout. This means that during the SMP process, no packets were received from the peer device. Additionally, I noticed the following in your log: I suspect that during the peer device’s disconnection process, the SMP procedure has not been completed, which ultimately results in the SMP failure. I recommend ensuring the connection is maintained until the SMP process is successfully completed before disconnecting. This should help resolve your issue. |
|
Thank you for the insights, @esp-zhp It seems the issue arises because the user is frequently moving in and out of the device's Bluetooth range. This causes the Bluetooth connection to toggle repeatedly, which may be leading to the SMP timeout and disconnection issues. Given this behavior, could you suggest steps to prevent or mitigate this problem? Should we consider making adjustments in the firmware to handle frequent reconnections more effectively, or are there other solutions you would recommend? |
|
@nitin-jethava There are two possibilities: one is that the Apple Bluetooth stack actively disconnected, and the other is that the user disconnected at the application layer. I suspect the frequent disconnections might be caused by user actions. Do you have any other perspectives? do you know the scenario in which this issue occurred? |
|
Thank you for the detailed insights, @esp-zhp During our QA/QC process, we intentionally toggled Bluetooth (turning it ON and OFF repeatedly), which seems to have triggered the issue. This resulted in the 0x66 error code. After this, we found that the only way to restore communication with our device was to manually "forget device" from the iPhone. Without doing this, reconnecting was not possible. Could you please advise on the best steps to handle this scenario? Should we implement specific measures in the firmware to manage such cases, or are there additional adjustments we can explore? |
|
Based on your recent description, the issue appears to have changed and seems to be related to SMP (Security Manager Protocol). It looks like the ESP device may have lost the bond information. To verify this assumption, you can try printing the bond list using the following APIs:
If it is confirmed to be an SMP-related issue, you can test the behavior without bonding to see if the problem still occurs. Please let us know if further assistance is needed! |
|
You are correct, @esp-zhp. I had tested this, and the bond information indeed appears to be missing when the issue occurs. Under normal circumstances, the Since bonding is closely tied to the ANCS functionality in our application, this loss of bond information directly impacts the ability to receive notifications seamlessly. Given this scenario, could you please advise on the best approach to handle such cases? Specifically:
Your guidance on this matter would be greatly appreciated as it will help us optimize our handling of these disconnections. |
|
We have never encountered a situation where the ESP32 loses bond information. I recommend adding debug logs at key events. For example, print the bond list after advertising starts ( Please also note that the ESP32 bond list has a size limitation of 15 entries. |
|
Thank you for your input, @esp-zhp. After reviewing your suggestions, I’ve added debug logs at key events to monitor the bond list and collected the following observations:
From these logs, it’s clear that bond information is lost after certain disconnection scenarios, particularly when errors I’ve attached the full log file ( Could you please advise on the following:
If you require additional logs, specific test scenarios, or further debugging, please feel free to let me know. I’ll be glad to provide any necessary details or support to help resolve this issue. |
|
Based on the additional logs you provided, we further confirmed the bond loss scenario. Could you check whether the example actively clears bond information? If there’s no active clearing, we suspect this might be a bug in the protocol stack. I’ve added some HCI logs for further debugging. Additionally, have you tried using the latest branch? |
|
Thank you for the clarification, @esp-zhp.
Could you please advise further based on these findings? Do you suspect this could be a protocol stack issue, and are there additional steps or tests you would recommend? If you require additional logs, specific test scenarios, or further debugging, please feel free to let me know. I’ll be glad to provide any necessary details or support to help resolve this issue. |
|
@nitin-jethava It is important to note that bond information is currently retained only when the failure reason is If you prefer to always do not clear the bond information, you can modify the code as follows: From: if (sec_event.auth_cmpl.fail_reason != BTA_DM_AUTH_SMP_CONN_TOUT) {
bta_dm_remove_sec_dev_entry(bda);
}To: if (sec_event.auth_cmpl.fail_reason != BTA_DM_AUTH_SMP_CONN_TOUT) {
// bta_dm_remove_sec_dev_entry(bda);
} |
|
Thank you so much for your solution, @esp-zhp! The issue is now resolved, and everything is working as expected. I appreciate your detailed explanation and the suggested changes regarding bond information retention. The fix has worked for me, and I can confirm the solution is effective. Actually, I was doing this for the Thanks again for your valuable support and for guiding me through this! |
Answers checklist.
General issue report
Issue Description:
The ESP32 running the ESP-IDF BLE ANCS example frequently fails to pair with an iOS device after repeated connect/disconnect cycles. The pairing fails with the error code
0x66(102).Steps to Reproduce:
0x66.Observation:
Logs:
Key observations from logs:
pair status = success).pair status = fail,fail reason = 0x66).Potential Cause:
The BLE stack might not handle rapid reconnections or repeated disconnection scenarios effectively, leading to pairing and service discovery failure.
The text was updated successfully, but these errors were encountered: