Proper way to handle a bonded reconnect

RE: Proper way to handle a bonded reconnect

brianreinhold — Thu, 30 Jan 2020 16:40:05 GMT

I will work on that. The client is fairly complicated as it is a production application. It does not ever read the CCCDs, it always enables them every pass because there are some devices that do NOT properly remember the bonding information.

RE: Proper way to handle a bonded reconnect

run_ar — Thu, 30 Jan 2020 14:07:07 GMT

As a check, what happens if you try the read a cccd value from the gatt-client, after you have connected and tried to restore the attributes on the connection event (on the gatt server)? Since this is the api's we are using in the peer manager to recover attributes they should work, but maybe there is something wrong with the serialization.

Is there any chance you can share your application? or create stripped down version that recreates the issue?

Also, could you capture sniffer traces that shows the initial connection where the bonds is created and also a new connection where the bond and attribute data is restored?

RE: Proper way to handle a bonded reconnect

brianreinhold — Thu, 23 Jan 2020 14:33:58 GMT

I do not know what will trigger the attrs missing event. It is never triggered.

I have tried all combinations for the get and set. At the moment I am ORing all the available flags in the hope that I am getting both system and 'application' CCCD settings. From parsing the data (which is not the easiest to read) it looks like everything is there (service changed AND my app''s CCCDs).

This prevents me from sending a service changed event ... it never works. But having the central re-set the CCCDs every connection works. A bad solution and not following the spec.

RE: Proper way to handle a bonded reconnect

run_ar — Thu, 23 Jan 2020 12:47:15 GMT

Yes, you are right, you have to wait until the connection is established befor setting the system attribures. But you already confirmed the get looks good when you read it back after a write. So that is a bit strange. Are you using the flags or are you getting and restoring both system and user attributes? Note that it should be fine to set the attribute on connection, I do not see a reason to wait for the system attribute missing event or error. However you should probably wait until the bond has been reestablished so you know you are setting the system attributes for a known device and not just someone who randomly connected.

Note that calling sd_ble_gatts_hvx will not trigger an event. Instead it will return an error message with the error code

BLE_ERROR_GATTS_SYS_ATTR_MISSING compared to the event

BLE_GATTS_EVT_SYS_ATTR_MISSING which will be generated in case the peer tries to read a system attribute handle.

RE: Proper way to handle a bonded reconnect

brianreinhold — Thu, 23 Jan 2020 11:57:01 GMT

There is a lot to filter through here. I will need to change my central to get back to testing these situations. Because of the problem, I have added code in my central that writes CCCDs EVERY connection, bonded or not, which is not ideal. However, there are health devices in the field which also have this bug.

The problem with doing the 'set' and 'get' calls pre-connection is that the calls themselves require a connection handle which you don't get until a connection event.

I know the first pass at doing this I had my set and get calls in the BLE_ERROR_GATTS_SYS_ATTR_MISSING event handler. But calling the sd_ble_gatts_hvx did not signal the event and the central did not receive the indications/notification. So I gave up that approach a long time ago and went for the setting during the connection event. Interestingly, when I read back what I set, it looks good.

I am at an IHE connectathon at the moment so am a little tied when it comes to further testing.

RE: Proper way to handle a bonded reconnect

run_ar — Thu, 23 Jan 2020 11:33:36 GMT

Yes, you are correct. The peer should not have to re-set the CCCD's or perform service discovery on a reconnect when it is bonded.

However I am a bit confused, as you say you do not get the BLE_ERROR_GATTS_SYS_ATTR_MISSING event? But is the peer actually trying to read something in this case?

Also in case you call sd_ble_gatts_hvx, you can get an BLE_ERROR_GATTS_SYS_ATTR_MISSING error message. This is also a case where you need to set the system attribute.

However, since this is serialization. Can you collect the content using system attribute get command, first before esthablishing a connection at all, then on disconnect. And then again after setting them after reestablishing the bond. Just want to check that it is actually updated during the connection and that the last get matches what you received on disconnect.

RE: Proper way to handle a bonded reconnect

brianreinhold — Wed, 22 Jan 2020 14:58:09 GMT

Pairing is not the problem.I have no problems with pairing or encryption on a reconnect. The problem is saving the 'enabled' state of the descriptors. On the first time connect, the peer pairs and then sets the CCCDs for indications or notifications (as needed). I save that information according to the documentation. On a reconnect I restore it according to the documentation. As I understand it, the peer should NOT have to re-set the CCCDs. But if the peer does not reset the CCCDs, no data will be sent and I get the above errors. So either my understanding of the pairing/bonding procedure is incorrect, or something is wrong with the documentation on how to restore the CCCD data.

I guess I should add that when following the sequence diagram that you mention I never get the BLE_GATTS_EVT_SYS_ATTR_MISSING event. I submitted a ticket on that some time ago, but have received no resolution. So I am assuming that approach (as in the sequence diagram) does not work and I am trying to do what is done in the handling of that event in the connection event. I have long given up on the BLE_GATTS_EVT_SYS_ATTR_MISSING event.

https://devzone.nordicsemi.com/f/nordic-q-a/54039/why-don-t-i-get-a-ble_gatts_evt_sys_attr_missing-event/223027#223027

RE: Proper way to handle a bonded reconnect

run_ar — Wed, 22 Jan 2020 13:35:36 GMT

Hi,

Unfortunately we do not have a bonding example for the pc-ble-driver. However serialization uses the same softdevice calls as the sdk does. In the SDK the Peer manager will create an event (PM_EVT_BONDED_PEER_CONNECTED) on connection that is forwarded to the gatts_cache_manager. This event will call a function local_db_apply_in_evt ( this will call gscm_local_db_cache_apply) that eventually results in sd_ble_gatts_sys_attr_set being called. Look at gatts_cache_manager.c:218

RE: Proper way to handle a bonded reconnect

brianreinhold — Thu, 09 Jan 2020 09:29:26 GMT

There is no such support for the ble-pc-driver. Everything is based upon sd_* calls and that is all I have at my disposal. Besides, according to the documentation, what I am doing should work.

RE: Proper way to handle a bonded reconnect

run_ar — Thu, 09 Jan 2020 08:56:08 GMT

Hi,

First I just want to say that I am sorry for the late answer, we have been catching up on backlog from the Holidays.

Second how come you are not using the peer manager (Architecture)? this SDK module would handle these things for you. If you take a look at the gatts_cache_manager module in our SDK you can see how we handle these attributes. More specifically the gscm_local_db_cache_apply function.

If you are making your own "Peer manager": Did you see the Message sequence charts in our documentation?

GATTS System Attributes Handling: Bonded Peer

GATTS System Attributes Handling: Unknown Peer