NimBLE - scanned address does not match address returned by ble_gap_conn_find() when connecting (IDFGH-3774)

bfriedkin commented 4 years ago

Environment

Development Kit: Moddable Two (ESP32)
Kit version: ESP32 r6
Module or chip used: ESP32-WROOM-32D
IDF version: v3.3.2
Build System: CMake?
Compiler version: xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a) 5.2.0
Operating System: macOS
Using an IDE?: No
Power Supply: USB

Problem Description

When a BLE client connects to a peer device, the peer id and ota addresses returned by the ble_gap_conn_find() function, when called from the BLE_GAP_EVENT_CONNECT event handler, does not match the address previously reported for the same peer in the BLE_GAP_EVENT_DISC handler.

This problem seems to be related to changes in the nimble-1.1.0-idf-v3.3 subcomponent update, referred to in this case. The problem does not occur when using a fresh checkout of ESP-IDF v3.3.2 with no patches applied.

Expected Behavior

The address provided in the addr field in the ble_gap_disc_desc record should match the peer_id_addr field in the ble_gap_conn_desc record returned by ble_gap_conn_find() called after connecting to the peripheral.

Actual Behavior

The peer_id_addr val and type values are different compared to the address reported while scanning when running the nimble-1.1.0-idf-v3.3 subcomponent update.

Note this behavior might be specific to the way iOS uses RPA, though the problem does not exist in Bluedroid, nor when running NimBLE without the update.

If it is not possible to resolve this difference, I would be interested in a workaround that allows us to somehow get the scanned address from the BLE_GAP_EVENT_CONNECT handler. Our code currently keeps a record corresponding to the pending connection. That record includes the scanned address. Then when connecting our code checks that the address reported on connection matches the scanned address. This check now fails when running with the nimble-1.1.0-idf-v3.3 update.

Steps to reproduce

Launch LightBlue on iOS and create a virtual "Heart Rate" device
Scan the "Heart Rate" device from a BLE client app
Note the address and address type reported in the ble_gap_disc_desc record in the BLE_GAP_EVENT_DISC handler
Initiate a connection to the "Heart Rate" virtual peripheral
In the BLE_GAP_EVENT_CONNECT handler, note the peer_id_addr type and val fields are different compared to the address reported for the same peripheral when scanning

Code to reproduce this issue

It should be possible to reproduce this issue with a modified version of the blecent example app. I haven't done that, but it easily reproduces with our apps.

Debug Logs

I traced the address and address type received by our ESP32 device app that scans for and connects to the virtual heart rate peripheral. The traces show the different in addresses:

found HR @ 44:9F:86:2A:AA:C5
peer id address:
50
83
d5
1a
ab
84
peer ota address:
50
83
d5
1a
ab
84

The found HR trace shows the address reported during scanning. The format is printable (big endian). The subsequent peer id address and peer ota address are traced from the BLE_GAP_EVENT_CONNECT handler. The bytes are listed in little endian order. You can see however that the addresses are the same but different compared to the same peripheral's address when scanning.

Alvin1Zhang commented 4 years ago

Thanks for the detailed report and letting us know, we will look into.

rahult-github commented 2 months ago

This issue is reported on nimble-1.3.0-idf which is very old and release/v3.3 is EOL. There is no such issue on later release branches. Closing this issue, please feel to reopen in case of any updates

espressif / esp-idf