Device manager DM_EVT_SECURITY_SETUP_COMPLETE error

RE: Device manager DM_EVT_SECURITY_SETUP_COMPLETE error

Petter Myhre — Mon, 25 May 2015 12:56:56 GMT

Yes, this bug was fixed in SDK 7.1.0. CEAA is an IC revision 2 chip, it is compatible with SoftDevice S110 7.1.0 (and 8.0.0, if you disable CPU and radio concurrency, see its release notes). However, SDK 7.0.1 and later has not been tested on IC revision 2. Please see the nRF51 Series Compatibility Matrix for more information. This question may also provide some insight.

RE: Device manager DM_EVT_SECURITY_SETUP_COMPLETE error

Michal Zacharias — Sun, 24 May 2015 16:13:31 GMT

I was trying to implement this, but the 6.1 device manager seems to have a bug

Lines from 2574 in device_manager_peripherla.c

                        if (p_ble_evt->evt.gap_evt.params.auth_status.central_kex.irk == 1)
                        {
                                                            m_peer_table[index].irk =
                                p_ble_evt->evt.gap_evt.params.auth_status.central_keys.irk;
                            m_peer_table[index].id_bitmap &= (~IRK_ENTRY);
                        }

replace to this

                        if (p_ble_evt->evt.gap_evt.params.auth_status.central_kex.irk == 1)
                        {
                                                            m_peer_table[device_index].irk =
                                p_ble_evt->evt.gap_evt.params.auth_status.central_keys.irk;
                            m_peer_table[device_index].id_bitmap &= (~IRK_ENTRY);
                        }

Otherwise I get only valid irk for the first entry in the whitelist, the rest is nilled data.

Is this fixed in newer sdks? Can we use newer sdk and softdevice with nrf58188_xxAA (CEAA)?

RE: Device manager DM_EVT_SECURITY_SETUP_COMPLETE error

Petter Myhre — Fri, 22 May 2015 20:49:02 GMT

Please see my edited answer.

RE: Device manager DM_EVT_SECURITY_SETUP_COMPLETE error

Michal Zacharias — Fri, 22 May 2015 16:01:44 GMT

Okay, I must have connected 7 times before that error. I cannot reproduce it before seven consecutive connections from the same device. The 8th pairing causes the error. So when and how should I delete the rest of paired information. I still didn't find any way to list the bonded peers and delete the oldest ones.

RE: Device manager DM_EVT_SECURITY_SETUP_COMPLETE error

Petter Myhre — Fri, 22 May 2015 11:15:46 GMT

I just tested this now. SoftDevice S110 v7.1.0, SDK6.1.0, iOS 8.3, ble_app_hrs with BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM(&hrs_init.hrs_hrm_attr_md.cccd_write_perm); With DEVICE_MANAGER_MAX_BONDS 7 I don't get DM_DEVICE_CONTEXT_FULL, but with DEVICE_MANAGER_MAX_BONDS 1 I get it. Could it be that you have bonded 7 times without deleting the bond information? Please help me reproduce this.

RE: Device manager DM_EVT_SECURITY_SETUP_COMPLETE error

Michal Zacharias — Thu, 21 May 2015 15:03:04 GMT

The only theoretical solution that comes in my mind to delete all bond information after the LINK_SECURED event if pairing is in progress. Given it is safe to assume that device manager doesn't store device information somewhere before this. But this way only one bounded device would be supported and a solution for your 2) problem would be required.

RE: Device manager DM_EVT_SECURITY_SETUP_COMPLETE error

Petter Myhre — Thu, 21 May 2015 14:57:55 GMT

I'll try to reproduce this tomorrow. What iOS version and device are you using? You are using SDK 6.1.0 with SoftDevice S110 v7.1.0?

RE: Device manager DM_EVT_SECURITY_SETUP_COMPLETE error

Michal Zacharias — Thu, 21 May 2015 14:42:36 GMT

MAX_BONDS is set to 7, and only 1 device connected to it. The application functions as activity tracker and delivers notifications to the user. We need bonding because we also use ANCS client. Without bonding ANCS doesn't work.
I found no way to get a list of stored bonded centrals with device manager and the documentation to it is rather brief and confusing. Could you point me to an example code, where this is implemented?

RE: Device manager DM_EVT_SECURITY_SETUP_COMPLETE error

Petter Myhre — Thu, 21 May 2015 14:11:55 GMT

I think you will only get DM_DEVICE_CONTEXT_FULL when the device context memory is full. You will receive this error from device_instance_allocate() when the BLE_GAP_EVT_AUTH_STATUS event is handled in dm_ble_evt_handler().

Have you set DEVICE_MANAGER_MAX_BONDS to 1? You could try to increase it. If you have space in the device context memory I believe the device manager will just look at the iOS device as a new device and create a new bond. Lets say you set it to 8, then you will be able to bond with 8 different devices, or if you delete the bonding information in iOS, have up to 8 bonds with the same device. The device manager allows you to delete bonds, so you could have some kind of mechanism that ensures that there always is device context memory available when a new device tries to bond.

To detect if a central device has been unbonded you need some way of identifying it. The device address changes, but maybe you can use IRK to achieve it. So what event in the bonding process will give you the IRK? You will not get the IRK when you get the BLE_GAP_EVT_CONNECTED event(if you don't use whitelisting), and you will not get it with the BLE_GAP_EVT_SEC_PARAMS_REQUEST or the BLE_GAP_EVT_CONN_SEC_UPDATE events. You will get it with the BLE_GAP_EVT_AUTH_STATUS event.

To get a list of IRKs of the bonded devices you can use dm_whitelist_create(). So in ble_evt_dispatch() you can look for the BLE_GAP_EVT_AUTH_STATUS event, get the list, run through it, and delete the bonded devices with dm_device_delete_all() if you get a match.

I haven't tested this, it is just an idea. Also, I cannot guarantee that the central device will use the same IRK.

The devices are still connected, and they are still able to communicate, but you will only be able to access characteristic values and descriptors that doesn't require encryption, but usually the app doesn't try to access these. Please see this question for a bit more information.

Edit 22.05.2015 Added a suggestion on how to identify an unbonded central.