What is a 'system attribute'

[brianreinhold]

I see this in the documentation for this method

uint32_t sd_ble_gatts_value_set	(	uint16_t	conn_handle,
		uint16_t	handle,
		ble_gatts_value_t *	p_value
	)

with this note:

Values other than system attributes can be set at any time, regardless of whether any active connections exist.

But what is a system attribute? Why is one attribute have preference over another? They are, after all, attributes. Is a system attribute any attribute that has no characteristic value, for example, a characteristic declaration? How about a descriptor?

[tesc]

Hi,

By "system attributes" we primarily mean the Client Characteristic Configuration Descriptors (CCCD), i.e. attributes that are handled by the SoftDevice and have special requirements. It is mandated by Bluetooth specification that CCCD values are altered only by the peer, so you cannot change them from the application. Since CCCD values for a bonded peer should be stored between connections, an API exist for the application to store the values after disconnection, and to restore them on connection.

Regards,
Terje

[brianreinhold]

Okay, I figured it might be something like that but I needed to be sure.

On your second remark I have been storing the keys and the CCCD state myself. I give the keys to the peer on a reconnect when asked, and when encryption is done I just assumed the CCCD state was remembered. I just used the CCCD state to say I can start sending data as soon as encryption is finished. Since the peer re-writes the CCCDs every time to handle those bad devices that say they bond but don't save the CCCD state I was never sure that it was set before the peer set it.

So there are APIs that do this work for me?

[tesc]

Hi,

I would rather describe it as a SoftDevice API that lets you, or an SDK library, do the work. From the application you must, somehow, call sd_ble_gatts_sys_attr_get() to store the state, and sd_ble_gatts_sys_attr_set() to restore it. See GATTS System Attributes Handling: Bonded Peer and ... Unknown Peer for message sequence charts.

If you use our SDK this would be automatically handled through the Peer Manager library. So in that case you do not need to worry about the system attributes at all.

Regards,
Terje

[brianreinhold]

I am using the pc-ble-driver so I need to work with the sd_* methods and events directly. I prefer that in some sense because I am doing testing which means sometimes I have to do things which are considered bad and the SDK would not do.

Do those methods also save the various keys? I am wondering because now I have to handle an keys request event from the client where I give the keys to the client. If I use the above sd call to restore the state, will I still get signaled the key request event or will the SoftDevice handle it automatically?

[tesc]

Hi,

The SoftDevice uses a fixed amount of RAM for a given configuration, and only stores the data needed for the current connections. It does not use any permanent storage. Hence anything not related to the current connections, that should be saved for later, must be handled by the application.

When using the SD API directly you must do the work storing keys yourself. See e.g. the p_sec_keyset in/out parameter for sd_ble_gap_sec_params_reply(). You can also have a look at the GAP Message Sequence Charts, in particular the (Central / Peripheral) Security  Procedures.

Regards,
Terje

[brianreinhold]

So the bottom line is this: I do save the stuff myself. But when I read in that the measurement descriptor has been enabled, can I set the descriptor to the appropriate notify/indicate setting using the write method as when the client does it?  And do it before I start advertising?

[tesc]

Hi,

While you are in a connection, the SoftDevice will handle the CCCD as appropriate. When the peer writes to CCCD, that will be handled by SoftDevice.

The only thing related to the CCCD that you have to do from the application, is to store the data you get from sd_ble_gatts_sys_attr_get() on disconnection, and provide it back to the SoftDevice with sd_ble_gatts_sys_attr_set() on the BLE_GATTS_EVT_SYS_ATTR_MISSING event. You should treat the data as a blob of data of unknown format, i.e. you should store it as is and provide it back as is, without changing it. You should not try to write to the CCCD directly from the application.

Regards,
Terje

[brianreinhold]

Now that I am trying to use these methods there are two flags

#define BLE_GATTS_SYS_ATTR_FLAG_SYS_SRVCS (1 << 0) /**< Restrict system attributes to system services only. */
#define BLE_GATTS_SYS_ATTR_FLAG_USR_SRVCS (1 << 1) /**< Restrict system attributes to user services only. */

I think I now understand the system services. But what is a user service?

If I do this procedure, will I get the

BLE_GAP_EVT_SEC_INFO_REQUEST

any more?

Right now I save the security keys myself and restore them on that event. The documentation for the sd_ble_gatts_sys_attr_set() method does not specifically mention security keys and I get the idea that it is only CCCDs and the like, and no security keys.

To add to the problem, @ref BLE_GATTS_SYS_ATTRS_FORMAT described in the call to the *_get() method does not exist. I need to know what state the collector left the CCCDs in on a reconnect.

[brianreinhold]

I do as you say. But I have one major issue. On the bonded re-connect, the  BLE_GATTS_EVT_SYS_ATTR_MISSING is never signaled. Why?

I suppose that is causing the headaches I am having with invoking a service-changed indication?

Since the central re-writes the CCCDs I still get the measurements but the central should not have to do that. It does because there are too many bad devices out there that don't bond correctly when it comes to CCCDs.