iOS application connecting in the background

[Jeff]

I'm using SDK 15.3.0 and SoftDevice 6.1.1 running on an nRF52832.

The iOS application works correctly when it is running in the foreground.  It is able to connect and bond to the nRF.

After it has bonded, if I try to connect in the background, I'm seeing an BLE_GAP_EVT_AUTH_STATUS event.  I don't see that event during a foreground connection. The fields in the status event are saying that the remote side (src) returned a status of BLE_GAP_SEC_STATUS_UNSPECIFIED (0x88):

[00:01:24.056,976] <debug> ble_dcs: Event BLE_GAP_EVT_AUTH_STATUS (0x19)
[00:01:24.057,006] <info> app: BLE_GAP_EVT_AUTH_STATUS: status:0x88 bond:0x0 src:0x1 lesc:0x0
[00:01:24.057,037] <info> app: BLE_GAP_EVT_AUTH_STATUS: sm1:0000
[00:01:24.057,037] <info> app: BLE_GAP_EVT_AUTH_STATUS. sm2.0000
[00:01:24.057,067] <info> app: BLE_GAP_EVT_AUTH_STATUS: kdist_own: enc:0x0 id:0x0 sign:0x0 link:0x0
[00:01:24.057,067] <info> app: BLE_GAP_EVT_AUTH_STATUS: kdist_peer: enc:0x0 id:0x0 sign:0x0 link:0x0

I'm looking for any insight into the cause of this issue and what (if anything) can be done about it?

thanks,

Jeff

[Jeff]

A colleague suggested that I double check my connection parameters against the Apple Accessory Design Guidelines (https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf).

I believe that I'm meeting those with the values:

• min: 15 ms
• max: 75 ms
• latency: 0
• connection supervision timeout: 6 sec

However, there is a statement:

The device will not read or use the parameters in the Peripheral Preferred Connection Parameters characteristic. See the Bluetooth 4.0 specification, Volume 3, Part C, Section 12.5.

I'm using the function sd_ble_gap_ppcp_set() to set those connection parameters.

Is there another way that should be used when connecting with an iOS device?

The guidelines say to send a L2CAP Connection Parameter Update Request at the appropriate time.  Is that done by responding to a BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST event?

thanks,

Jeff

[Hung Bui]

Hi Jeff, 

We got report earlier that status BLE_GAP_SEC_STATUS_UNSPECIFIED  may come if the phone is bonded but the device doesn't store the bonding and can't encrypt the link when the phone send the encryption request using the stored TLK. You may want to check and make sure you can do bonding not just pairing. 

Could you clarify that after you bond for the first time using foreground application, if you connect again you don't need to do bonding again and the link can be re-encrypted ? 

A sniffer trace would be very helpful to reveal what happens over the air. 

Regarding your question about connection parameters. I don't think it would related to the issue you are having. Even though iOS device wouldn't read the Peripheral Preferred Connection Parameters, we send connection parameter request and as you already configure it with min 15ms max 75ms I don't see any big issue with that configuration. 

 

 

[Jeff]

Hi Hung,

I've verified that the bond information is being stored and recognized on a foreground connection:

[00:01:52.276,306] <debug> nrf_sdh_ble: BLE event: 0x10.
[00:01:52.276,397] <debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
[00:01:52.276,428] <debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
[00:01:52.276,550] <debug> peer_manager_handler: Event PM_EVT_BONDED_PEER_CONNECTED
[00:01:52.276,550] <debug> peer_manager_handler: Previously bonded peer connected: role: Peripheral, conn_handle: 0, peer_id: 0
[00:01:52.276,580] <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
[00:01:52.276,611] <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update

Thanks for the confirmation on the connection parameters.

I'll see what I can do about collecting a sniffer trace of this happening.

thanks,

Jeff

[Jeff]

Hung,

I've attached a sniffer trace that I captured of the issue.  Packet 1995 shows the pairing failure.

Let me know what you think.

thanks,

Jeff

iOS-background_connection.pcapng

[Hung Bui]

Hi Jeff, 
It looked like the Slave requested the link to be bonded and the phone just rejected it.
I'm not 100% sure why the phone did this. But have you got the link encrypted (bonded) before that ? Could you capture that connection and exchange as well ? (in one shot) 

If the phone and the device had not been paired before that I think the rejection makes sense. The phone doesn't want the end user to be disturbed by an app in the background to popup and ask for pairing.