Service changed leading to disconnection

[nrbrook]

We have a device that does not support bonding, however the services changed and so we want to notify devices that may have cached the previous attribute table. To do this, we are sending service changed when service changed indications are enabled the first n times. Here is the code:

case BLE_GATTS_EVT_WRITE: {
            ble_gatts_evt_write_t const * p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;
            if (m_service_changed_indication_pending && p_evt_write->handle == 0xD && p_evt_write->len == 2 && p_evt_write->data[0] != 0) {
                NRF_LOG_INFO("Service changed indication enabled, sending indication");
                err_code = sd_ble_gatts_service_changed(p_ble_evt->evt.gatts_evt.conn_handle, m_kf_service.service_handle, 0xFFFF);
                if (err_code == NRF_SUCCESS) {
                    m_service_changed_indication_pending--;
                } else {
                    NRF_LOG_WARNING("Service changed indication failed, error %s", nrf_err_desc(err_code));
                }
            }
        }
            break;

Handle 0xD is the service changed CCCD.

When iOS connects, this works as expected – it enables indications, and then our device sends the service changed indication. iOS then starts service discovery again. The problem is that it appears the SoftDevice (7.2.0) or iOS disconnects. Here are the logs from the device with SDH BLE debug logging enabled:

00> [00:00:12.251,464] I22 <debug> nrf_sdh_ble: BLE event: 0x50.
00> [00:00:12.251,586] I22 < info> Bluetooth: Service changed indication enabled, sending indication
00> [00:00:12.319,030] I22 <debug> nrf_sdh_ble: BLE event: 0x11.
00> [00:00:12.319,152] I22 < info> Bluetooth: Disconnected. conn_handle: 0x2, reason: BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION

Here are the packet logs from iOS:

Jul 12 09:59:34.015  ATT Send         0x0042  D8:01:9E:EB:A8:48  Write Request - Handle: 0x000D - Service Changed - Configuration - Indication  
Jul 12 09:59:34.062  ATT Receive      0x0042  D8:01:9E:EB:A8:48  Write Response  
Jul 12 09:59:34.062  ATT Receive      0x0042  D8:01:9E:EB:A8:48  Handle Value Indication - Handle:0x000C - Service Changed - Value: 1900 FFFF  
Jul 12 09:59:34.062  ATT Send         0x0042  D8:01:9E:EB:A8:48  Handle Value Confirmation  
Jul 12 09:59:34.063  ATT Send         0x0042  D8:01:9E:EB:A8:48  Read By Group Type Request - Start Handle: 0x0001 - End Handle: 0xFFFF - UUID: GATT Primary Service Declaration  
Jul 12 09:59:34.065  HCI Event        0x0042  D8:01:9E:EB:A8:48  Number Of Completed Packets - Handle: 0x0042 - Packets: 0x0002    
Jul 12 09:59:34.067  HCI Command      0x0042  D8:01:9E:EB:A8:48  Disconnect - Connection Handle: 0x0042 - Reason: Remote User Terminated Connection  
Jul 12 09:59:34.108  HCI Event        0x0042  D8:01:9E:EB:A8:48  Number Of Completed Packets - Handle: 0x0042 - Packets: 0x0002    
Jul 12 09:59:34.108  HCI Event        0x0042  D8:01:9E:EB:A8:48  Disconnection Complete - Success  

[Vidar Berg]

Hello, 

The log indicates that the connection was terminated by the iPhone. I'm not sure exactly why it does this. But as you may know, there is no attribute caching when the Service Changed characteristic is present and there is no trusted relationship between the devices (i.e., no bond), so it should be redundant to send a Service Changed notification on connection as the phone will have just performed the service discovery anyway. Is the attribute table being updated during connections in your case?

Best regards,

Vidar

[nrbrook]

Ok it sounds like an iOS bug then. It does seem to cache attributes without bonding, we have to toggle bluetooth off and on to get it to refresh, which is why I was trying to get service changed working.

[Vidar Berg]

Strange. I have not experienced this myself, nor do I recall seeing any reports about it. The specification is quite clear on this too (the nRF5 SDK does not support the mentioned 'Hash Database' characteristic):

The only case I can think of where this would be expected is if the device was programmed initially with an application that did not include the Service changed characteristic.

Have you seen this with multiple iphones?

[nrbrook]

We didn’t have service changed before. Does that mean that iOS can cache it? Yes we have seen it with multiple phones.

[Vidar Berg]

It does. So, I'm afraid your only option is to manually clear the cache after changing the firmware in order to allow the iPhone to discover that the service changed characteristic has been added.

[nrbrook]

Ok so have the service changed characteristic present, but don’t send an indication, and iOS will not cache when unbonded?