Failure to re-pair to phone (esp-idf v5.4.1)

[finger563]

Whereas previously my hid_service/example would pair and work with my iPhone over BLE every time, now it only works every other reboot.

Flash the example, then run the following steps to reproduce:

1. Pair to iphone - should see that it bonds and connects just fine
2. Forget pairing info on iphone
3. Attempt to re-pair to iphone - should see that it gives pairing prompt then briefly shows connected before immediately disconnects (REMOTE_USER_TERMINATED).
4. Step 3 will continue to fail until you reboot the esp32, at which point it will succeed again, but only once. Any kind of reboot seems to work (power cycle, press reset button, software reset, deep sleep reset)

Logs:

success.log failure.log

[finger563]

Note: i've tested and it seems this failure occurs on android as well.

[finger563]

And I have confirmed that this behavior persists even after I run idf.py erase-flash

[finger563]

I've opened an upstream issue here as I try to determine if it's an issue in the latest version of NimBLE or if it's a required change in esp-nimble-cpp

[finger563]

Differences I've found:

diff.log

[finger563]

Note: this does not happen on esp-idf v5.4, but does happen on v5.4.1

[finger563]

Have confirmed this is an esp-idf / nimble upstream issue since this behavior is exhibited in the esp-idf/examples/bluetooth/nimble/bleprph example.

https://github.com/espressif/esp-idf/issues/15740#issuecomment-2786946928

[finger563]

@h2zero I'll let you determine if you want to keep this issue open for tracking upstream or if you'd rather close it. I don't know if the upstream changes won't also require changes to the esp-nimble-cpp implementation (there is an unknown event showing up in the logs).

Edit: The Unknown event type 27 0x1b in the logs corresponds to BLE_GAP_EVENT_PAIRING_COMPLETE which the server does not handle.

[h2zero]

Thanks @finger563 looks like there are a lot of breaking changes in 5.4.1, lets keep this open for tracking.

[finger563]

FWIW i'm tracking that the DHKEY check is failing, causing the stack to stall out / go into a bad state preventing the bonding from succeeding. I'll continue to update as I find out more, but the majority of my testing / findings is on the linked issue.

[h2zero]

What should be happening is that with the phone bond deleted the stack should recognize this and trigger a repairing event that will delete the local bond info and start the process anew. I wonder what they changed.

[finger563]

For anyone else experiencing this issue, there is a nimble patch available which (in my testing) fixes the issue

https://github.com/espressif/esp-idf/issues/15740#issuecomment-2789983990

[finger563]

Note: there's a better patch available as that patch breaks pairing compatibility with macos

[whni]

Note: there's a better patch available as that patch breaks pairing compatibility with macos

Hi thank you so much for raising this issue. I am also experiencing this issue on macos. What will the better patch will? Thank you!

[finger563]

Note: there's a better patch available as that patch breaks pairing compatibility with macos

Hi thank you so much for raising this issue. I am also experiencing this issue on macos. What will the better patch will? Thank you!

diff --git a/nimble/host/src/ble_hs_conn.c b/nimble/host/src/ble_hs_conn.c
index ff4183483..eb749c41a 100644
--- a/nimble/host/src/ble_hs_conn.c
+++ b/nimble/host/src/ble_hs_conn.c
@@ -480,13 +480,11 @@ ble_hs_conn_addrs(const struct ble_hs_conn *conn,
     case BLE_ADDR_PUBLIC_ID:
         addrs->peer_id_addr.type = BLE_ADDR_PUBLIC;
         addrs->peer_ota_addr = conn->bhc_peer_rpa_addr;
-        addrs->peer_ota_addr.type = conn->bhc_peer_addr.type;
         break;

     case BLE_ADDR_RANDOM_ID:
         addrs->peer_id_addr.type = BLE_ADDR_RANDOM;
         addrs->peer_ota_addr = conn->bhc_peer_rpa_addr;
-        addrs->peer_ota_addr.type = conn->bhc_peer_addr.type;
         break;

     default: