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]

Hi Hung,

I've attached another pair of sniffer logs.

The first shows:

• an initial pairing with iOS in the foreground
• disconnected from the device.
• reconnected to the device
• disconnected from the device.

iOS-initial-pairing.pcapng

The second shows another failed attempt at the connection in the background.

iOS-background-connection-failed.pcapng

Jeff

[Hung Bui]

Hi Jeff, 
On the 2nd sniffer trace I can see that the slave sent a security request (packet 918) when the link is already encrypted. This is pretty strange. Usually the slave shouldn't do that. Did you hardcode the slave/peripheral to do that ?
And in general the slave shouldn't send security request at all. This is a requirement in the Apple accessories guidelines. Please have a look at section 35.10 Pairing here https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf

The slave/peripheral should leave the connection open and if pairing is required let the central read/write to a characteristic that has encryption requirement, response with  Insufficient Authentication error code (already automatically handled by the softdevice). Then the phone will continue to encrypt the link.