Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to send GATT_ERROR_response?

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

Parents
  • Hello,

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

    Best regards,

    Edvin

  • 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?

  • 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

  • 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

  • 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

     

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

    BR,

    Edvin

     

  • 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

Reply Children
No Data
Related