Immediate disconnect during bonding attempt with BLE4.2 with deprecated bond information

[emb_dev]

Hello,

 

we face the following issues when trying to connect to our peripheral with Android 7 and 8 phones each with BLE4.2.

 

Precondition:

Phone was connected and bonded to the peripheral.

Bond information was stored by Peer Manager module.

The bond information was deleted on the peripheral and is no longer available in the peer manager module.

The bond information persists on the phone.

Connection settings:

#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 92
#define NRF_SDH_BLE_GAP_DATA_LENGTH 32
#define NRF_SDH_BLE_GAP_EVENT_LENGTH 10

#define MIN_CONN_INTERVAL                   MSEC_TO_UNITS(45, UNIT_1_25_MS)         /**< Minimum acceptable connection interval. */
#define MAX_CONN_INTERVAL                   MSEC_TO_UNITS(60, UNIT_1_25_MS)        /**< Maximum acceptable connection interval. */
#define SLAVE_LATENCY                       15                                       /**< Slave latency. */
#define CONN_SUP_TIMEOUT                    MSEC_TO_UNITS(6000, UNIT_10_MS)         /**< Connection supervisory time-out. */

#define FIRST_CONN_PARAMS_UPDATE_DELAY      APP_TIMER_TICKS(500)                  /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (10 seconds). */
#define NEXT_CONN_PARAMS_UPDATE_DELAY       APP_TIMER_TICKS(1000)                   /**< Time between each call to sd_ble_gap_conn_param_update after the first call. */
#define MAX_CONN_PARAMS_UPDATE_COUNT        3                                       /**< Number of attempts before giving up the connection parameter negotiation. */

Observed behavior:

Phone connects to the peripheral, does not bond but disconnects right away.

On the peripheral the disconnect reason 19 (BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION) is reported.

On the phone the disconnect reason Reason: TERMINATE LOCAL HOST is reported after we get the ConnectionObserver.onDeviceConnected() event from the Nordic Android library. After this the Service discovery occurs automatically.

 

 

Expected behavior:

Phone connects and bonds to the peripheral without problems as it does with BLE5 and other Android versions.

 

 

Is there something we have to consider in the implementation on the peripheral that will lead to the expected behavior on all phones?

 

Thanks in advance for your help and best regards.

[Einar Thorsrud]

Hi,

The bond information was deleted on the peripheral and is no longer available in the peer manager module.

The bond information persists on the phone.

In this case it is expected that the phone disconnects immediately after being unable to secure the link. Silently allowing repairing here would be a security problem as an attacker could spoof the address of the peer and replace it's bond. Therefor this is prohibited by all modern smart phones.

There are two ways to solve this exact issue:

1. Do not bond with the nRF, only pair. In that case, both the nRF and phone would loose the pairing information on each disconnect, and they can pair again whiteout issues. This may not suite your use case though.
2. The other alternative is do delete the bond on the phone before connecting and bonding with the nRF again.

As a side note, on the nRF you can specify that repairing should be allowed as explained here, and that would solve the issue if it was the other way around (bonding information deleted on the phone, but not on the nRF).

[emb_dev]

Hi,

thank you very much for the quick response.

If I understand correctly, once the nRF deletes the bond information but it remains on the phone, it should always disconnect immediately? Because we observe that with newer phones (BL5) it is no problem rebonding even if the bond information was deleted on the nRF but not on the phone.

As you already indicated, option one (not bonding) doesn't fit our usecase.

We would implement the second solution in case the bonding does not work anymore. We have another question here: 

Is there a specific error we should catch that indicates this issue or is it just the TERMINATE_LOCAL_HOST error?

In the other case, when the bond information is deleted on the phone but not on the nRF, the following is already implemented and working nicely:

case PM_EVT_CONN_SEC_CONFIG_REQ: {

    // Allow pairing request from an already bonded peer.
    NRF_LOG_INFO("Allowing repairing existing bond entries");
    pm_conn_sec_config_t conn_sec_config = {.allow_repairing = true};
    pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config);
}
    break;

[Einar Thorsrud]

Hi,

emb_dev said:

Because we observe that with newer phones (BL5) it is no problem rebonding even if the bond information was deleted on the nRF but not on the phone.

I must admit I was no aware of this, but it seems newer Android devices will typically automatically delete the bond silently in this case, and then allow you to pair again (so it there has been a slight shift away from security towards user friendliness in this case). This is all depending on the Android side and not something that can be controlled from the nRF side.

emb_dev said:

Is there a specific error we should catch that indicates this issue or is it just the TERMINATE_LOCAL_HOST error?

There is no disconnect reason that covers this. I am not familiar enough with Android API's, but on the nRF you would get a PM_EVT_CONN_SEC_FAILED event from the peer manager in such cases.

[emb_dev]

Thanks for your help!