How to send GATT_ERROR_response?

[CheMax]

Hello,

I have the following question: when developing a software product, I developed my own service. It consists of one characteristic and several descriptors (valid range / signal frequency / text description, etc ...).

Part descriptor I want to use to configure the device after the connection is established. For this, the descriptor value is available both by writing and by reading.

Now, I want to control the record of the values ​​and when I try to write the incorrect setting (wrong size / out of range), send an error message. I can implement the control, but how do I return a GATT error, such as an invalid size / invalid value?

Thanks,

p.s. I used a Google translator to control the correctness of the translation of my question

[Edvin]

Hello,

You should look into using the write request. Check out run_ar's reply in this case.

Best regards,

Edvin

[CheMax]

In that topic, it was a question of setting the rights to read / write and warning that writing or reading is not available without authorization. But this is not exactly what I need.

I have next function for control writen value in descriptor:

static void cds_on_write(cds_svc_t *p_cds, ble_evt_t const *p_ble_evt)
{
  ble_gatts_evt_write_t const *p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;
		 
  
  if(p_evt_write->handle == p_cds->valid_channels_handle)
  {
    if (p_cds->evt_handler != NULL)
    {
      if(*p_evt_write->data >= 1)
      {
        // Invalid value! Send error message
      }
    }
  }
}

Now, how do I report that the value is not correct?

[CheMax]

Hello, Edvin.

I open a Bluetooth Core Specification and read next text:

An Error Response is sent by the server in response to the Write Request if insufficient authentication, insufficient authorization, insufficient encryption key size is used by the client.
The Error Code parameter is set as specified in the Attribute Protocol.

If the characteristic descriptor value is is written in the form of an error, the value is written in the form of an error, or has an invalid value. Code set to Application Error by the server.

(BLUETOOTH SPECIFICATION Version 4.2 [Vol. 3, Part G] page 567).

So, according to the description for any read operation, a response with an error code (0 if there was no error) should be returned. My question is, with what function or when processing which event do I control the return value?

For example: trying to write a value of 0x02 in the 0x2902 descriptor results in an incorrect size error.

Best Regards,

Max

[Edvin]

Hello Max,

It is the SoftDevice that handles these errors, and sends them if you don't have sufficient encryption or authorization. This is controlled when you set the encryption requirement for a characteristic, using e.g.:

BLE_GAP_CONN_SEC_MODE_SET_OPEN(...)                      // means that any connected device can interact with it.

or

BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(...)  // means that you need to have MITM protection to interact with it.

 

When these are set, the SoftDevice will send the correct GATT error. 

You can't send these responses via the application, unfortunately.

 

BR,

Edvin

[CheMax]

Hello Edvin,

Thanks for your answer.

A little philosophical question: does this contradict the specification?

Well, it turns out that at the development stage, I need to take into account and set the appropriate permissions.

Is it possible to set different authorization levels for characteristics / descriptors within the same service?

BR, Max

[Edvin]

The softdevice handles the cases that you mentioned from the spec:
"An Error Response is sent by the server in response to the Write Request if insufficient authentication, insufficient authorization, insufficient encryption key size is used by the client."

But you can't overwrite the return values if the application does not approve of the actual data.

 

Yes. You may have different authorization levels for different characteristics within the same service. If you look at the ble_app_gls example, you can see in ble_gls.c that you initially need to use MITM to enable notification. If you connect with nRF Connect (for Desktop) you will be able to see that if you press ignore when the passkey windows pops up, you will not be able to enable notifications for the glucose characteristic.

You can see that the same goes with the glucose feature characteristic within the same service. You can e.g. try to change the line:

BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM(&attr_md.read_perm);

to

BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.read_perm); 

and see that you can now access this characteristic even when you are not connected.

Also, inside the same function, glucose_feature_char_add(), if you add the write property after the read property:

char_md.char_props.read = 1;
char_md.char_props.write = 1;

and set it to open while the read property is still NO_MITM:

BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM(&attr_md.read_perm);
BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.write_perm);

You will see that if you are not paired with MITM (if you ignore the passkey), you can write to the characteristic, but not read it.

 

Best regards,

Edvin

 

[Edvin]

I also suggest that you look through this blog post, as it describes the characteristic setup quite good.

BR,

Edvin

 

[CheMax]

Thanks,

I read this post.
 
Will the description of the extended interaction with characteristics be added, for example adding specific descriptors?

Thank you very much for your help!

BR,

Max