Timeout connecting from public central address to RPA peripheral address.

[gkoh]

esp-nimble-cpp: 2.3.1 esp-idf: 5.4.2

I'm on an ESP32 SoC (just ESP32, no C, no H, no S). If I do the following:

NimBLEDevice::setSecurityAuth(true, true, true);

// claim YESNO to enable numeric LE security
NimBLEDevice::setSecurityIOCap(BLE_HS_IO_DISPLAY_YESNO);

NimBLEDevice::setSecurityInitKey(BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID);
NimBLEDevice::setSecurityRespKey(BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID);
NimBLEDevice::setOwnAddrType(BLE_OWN_ADDR_PUBLIC);

and connect the esp32 as a central to an nRF Connect peripheral on Android:

• initial pairing and bonding works
• subsequent re-connect timeouts

I eventually tracked it down to the automagic peer address resolution which is occurring here on advertisements: https://github.com/espressif/esp-nimble/blob/48ca84312ea388fcfdb9cb9c85a8a8d4f9283302/nimble/host/src/ble_hs_hci_evt.c#L734

My knowledge is shallow, but I believe the timeout is occurring because esp-nimble has auto-resolved the advertisement address, when we need the 'actual' address to form a connection. If I comment out the above peer address resolution in the advertisement handling, everything works as expected. This appears related to an old esp-nimble issue: https://github.com/espressif/esp-nimble/issues/10

As the code is conditional on MYNEWT_VAL(BLE_HOST_BASED_PRIVACY), and I don't need host RPA, I disabled it in menuconfig (CONFIG_BT_NIMBLE_HOST_BASED_PRIVACY). Much to my surprise, this had zero effect on esp32 because of this: https://github.com/espressif/esp-idf/blob/47a659cd3ee5f73a253d2a7af02781a73a44356d/components/bt/host/nimble/port/include/esp_nimble_cfg.h#L953

Whilst this is not a problem in esp-nimble-cpp there appears to have been numerous issues on RPA handling in the past and I seek advice on how to proceed.

[h2zero]

@gkoh Looks like espressif added this back after it was removed years ago, https://github.com/espressif/esp-nimble/pull/7 I will look to remove this here, again, for now I suggest you comment that section out, or better yet, use a newer esp32 chip.

[gkoh]

@gkoh Looks like espressif added this back after it was removed years ago, espressif/esp-nimble#7 I will look to remove this here, again, for now I suggest you comment that section out, or better yet, use a newer esp32 chip.

@h2zero Thanks for the confirmation. I actually got here because RPA<->RPA with an nRF Connect Mobile wasn't working either, so tried to halve the problem ... only to have more problems 😐

Unfortunately I need to retain the original esp32 as I will need dual role Bluetooth Classic and LE in the near future. And that will mean porting over to Bluedroid ... ugh.

It seems all the new esp32 chips have gone BLE only.

[h2zero]

What happens if you disable the privacy config, just edit the file?

Bluetooth classic has been deprecated for a few years now by the SIG so nobody is making chips with that anymore.

[gkoh]

What happens if you disable the privacy config, just edit the file?

So I hard coded as:

#define MYNEWT_VAL_BLE_HOST_BASED_PRIVACY (0)

and initial pair/bond works, but a subsequent re-connect fails like this:

I (64675) NimBLE: GAP procedure initiated: connect; 
I (64681) NimBLE: peer_addr_type=2 peer_addr=
I (64686) NimBLE: 94:xx:xx:xx:xx:23
I (64690) NimBLE:  scan_itvl=16 scan_window=16 itvl_min=24 itvl_max=40 latency=0 supervision_timeout=256 min_ce_len=0 max_ce_len=0 own_addr_type=0
I (64703) NimBLE: 

I (64711) NimBLE: ogf=0x08, ocf=0x000d, hci_err=0x212 : BLE_ERR_INV_HCI_CMD_PARMS (Invalid HCI Command Parameters)

E (64718) NimBLEClient: Failed to connect to 94:xx:xx:xx:xx:23, rc=530; Invalid HCI Command Parameters

It looks like they added it all back here: https://github.com/espressif/esp-nimble/commit/56917b28aa8e9249bd09b263e35ec7b62d7cde32

Bluetooth classic has been deprecated for a few years now by the SIG so nobody is making chips with that anymore.

Sadly I can't make a choice. I'm developing a Bluetooth remote control for various existing cameras on the market (and using nRF Connect as a mock target). One of these cameras drops to Bluetooth Classic for the OOB key exchange ...