About GATT Server Context in HID mouse/keyboard example

[chd]

Hi,

Sorry if these are silly questions but I've tried some searchings and still cannot figure out the answers for the questions below

1. What is GATT Server Context? What is the data inside it specifically?

2. What is the purpose of saving GATT Server Context to persistent memory for each bonded device and what happens if I lose it?

3. I see in the example code that both gatts_context and bond_context are saved in persistent memory. And when there is a connect request from a previous bonded device, gatts_context will be loaded (applied) using sd_ble_gatts_sys_attr_set function. So, how about the bond_context (holds encryption info)? I dont see any function to load it.

I'm using Nordic nrf51822 chip with soft device s110 v7.0.0

Thank you for any help!

[Ulrich Myhre]

For bonded devices, you are required to remember the exchanged keys and the peer's "preferences" (i.e. GATT CCCD states like "notification enabled") shall be remembered between connections. This means that if a previously bonded device connects to you, you should be able to restore all the CCCD states as they were when you last communicated (this is done with sd_ble_gatts_sys_attr_set) and encrypt with the LTK received from earlier. I am not very familiar with the HID example, but I assume the two contexts refer to these two things. The GATT Server Context will contain every handle + value for each CCCD and the Bond Context I presume contain the encryption keys.

Not remembering the encryption keys will lead to a new pairing happening each time, and might confuse the peer if you do not send a "Pin or key missing" response to the security key request (which should delete the bond on the peer side). Not remembering the CCCD states between connections with a bonded device is a spec violation, and will lead to interoperability problems down the road.

Forgetting both the encryption keys and the CCCD context is allowed if you respond with "Pin or Key Missing", but this leads to a really slow ramp-up time. The bonding procedure exchanges a minimum of 6 packets + 1-2 for each key specified. It is also not possible to use IRK-based white-listing or Privacy 1.1/1.2 if you do not remember the Identity Resolving Key of your peer.

So these contexts are needed for HID, and while losing both is fine from a "What's allowed" perspective, it will really hurt power usage, latency and interoperability. This could legitimately happen if the device is restored to factory settings or lose power before saving the contexts. Losing only one of them is not allowed however.

[chd]

Is it the function call sd_ble_gap_sec_info_reply(m_conn_handle, NULL, NULL) that you're mentioning? If it is, the peer (an iPhone in my case) will still keep the connection, but it's unencrypted. As my application uses HID services that require encryption, doing so will make it got stuck with this iPhone (whenever I disconnect from my device's side, iPhone will automatically request a reconnecting if it see my device's advertising and get stuck in this unencrypted link again!)