iOS application connecting in the background

RE: iOS application connecting in the background

Hung Bui — Fri, 28 Aug 2020 11:17:50 GMT

Hi Jeff,

It's great that now you found the root cause. I'm glad that I can help a little bit. The sniffer traces were very useful.
Good luck with the project !

RE: iOS application connecting in the background

Jeff — Thu, 27 Aug 2020 16:37:17 GMT

Hi Hung,

Just wanted to follow up and report that the extra security request was the issue.

Our application, before creating a bond, requires a signed token from the mobile app. The logic of how that token was processed in our firmware was incorrect and causing a security request when it shouldn't have been asking for one.

Thanks for the help!

Jeff

RE: iOS application connecting in the background

Jeff — Tue, 25 Aug 2020 20:30:35 GMT

Hi Hung,

I'll look into what's causing that extra security request. Thanks for pointing me in that direction.

Jeff

RE: iOS application connecting in the background

Hung Bui — Mon, 24 Aug 2020 11:51:12 GMT

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.

RE: iOS application connecting in the background

Jeff — Thu, 20 Aug 2020 14:53:51 GMT

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.

devzone.nordicsemi.com/.../iOS_2D00_initial_2D00_pairing.pcapng

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

devzone.nordicsemi.com/.../iOS_2D00_background_2D00_connection_2D00_failed.pcapng

Jeff

RE: iOS application connecting in the background

Hung Bui — Thu, 20 Aug 2020 12:47:25 GMT

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.

RE: iOS application connecting in the background

Jeff — Wed, 19 Aug 2020 17:16:43 GMT

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

devzone.nordicsemi.com/.../iOS_2D00_background_5F00_connection.pcapng

RE: iOS application connecting in the background

Jeff — Tue, 18 Aug 2020 16:36:59 GMT

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

RE: iOS application connecting in the background

Hung Bui — Tue, 18 Aug 2020 14:56:28 GMT

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.

RE: iOS application connecting in the background

Jeff — Tue, 18 Aug 2020 14:04:36 GMT

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