sd_ble_gatts_rw_authorize_reply() returns NRF_ERROR_INVALID_PARAM when communicating error

[Torsten Robitzki]

Hi,

after porting an existing application from version 3.0 of the s132 SD to version 5.0, I experience, that sd_ble_gatts_rw_authorize_reply() returns NRF_ERROR_INVALID_PARAM, when I try to reply with an ATT Error Response to an ATT Write Request.

For all cases, where the reponse to a write request is simply BLE_GATT_STATUS_SUCCESS, sd_ble_gatts_rw_authorize_reply() does not return an error. But when I want the BLE stack to respond with an ATT Error Response, sd_ble_gatts_rw_authorize_reply() returns with NRF_ERROR_INVALID_PARAM (0x07).

Here are the aguments, I pass to sd_ble_gatts_rw_authorize_reply():

(gdb) p/x response
$2 = {type = 0x2, params = {read = {gatt_status = 0x107, update = 0x0, offset = 0x0, len = 0x0, p_data = 0x0}, write = {gatt_status = 0x107, update = 0x0, 
      offset = 0x0, len = 0x0, p_data = 0x0}}}
(gdb) p/x conn_handle
$3 = 0x0

And this is the event, to which the reponse belongs:

(gdb) p/x evt
$1 = (const ble_gatts_evt_rw_authorize_request_t &) @0x200050d2: {type = 0x2, request = {read = {handle = 0x10, uuid = {uuid = 0x5f4d, type = 0x2}, 
  offset = 0x1}, write = {handle = 0x10, uuid = {uuid = 0x5f4d, type = 0x2}, op = 0x1, auth_required = 0x0, offset = 0x0, len = 0x9, data = {0x8}}}}

According to the documentation of the return value NRF_ERROR_INVALID_PARAM: "Authorization op invalid, handle supplied does not match requested handle, or invalid data to be written provided by the application."

I think with "Authorization op", ble_gatts_evt_rw_authorize_request_t::type is ment. Which im my case is 0x02, which is BLE_GATTS_AUTHORIZE_TYPE_WRITE.

"handle supplied does not match requested handle": Dunno what this means. Maybe the connection handle, but as this problem only occurs, when the gatt_status is not equal to BLE_GATT_STATUS_SUCCESS, the connection handle seems to be ok.

"invalid data to be written provided": Well, when I look at othere examples in the SDK, that call sd_ble_gatts_rw_authorize_reply(), none of them set more than the gatt_status and the type field.

What am I'm doing wrong here?

Kind regards,

Torsten

[Petter Myhre]

You are trying to use BLE_GATT_STATUS_ATTERR_INVALID_OFFSET? I'm not sure that is supported. I'll have to check with the developers.

[Torsten Robitzki]

Well, the documentation of ble_gatts_authorize_params_t::gatt_status referes to GATT Status Codes, which contains all ATT error codes.

[Petter Myhre]

Yes, but if you are trying to use BLE_GATT_STATUS_ATTERR_INVALID_OFFSET with a write request (op = 0x01 = BLE_GATTS_OP_WRITE_REQ), that doesn't really make sense, because the write request doesn't include an offset parameter.

[Torsten Robitzki]

Well, I reuse the error code on the application layer. The PDU contains some kind of offset and when that is out of range, I would like to respond with ATT Invalid Offset. I would like to not add additional error codes, in cases where a good one exists already that is supported already by tools like sniffers. Is there a way to disable the test for "reasonable" error codes? Does this mean, if I would use, either a user defined error code, of for example the more generic ATT error code "Invalid PDU", that sd_ble_gatts_rw_authorize_reply() would then not return an error?

[Petter Myhre]

I'm not sure what you mean by reuse on the application layer. And what do you mean the PDU contains some kind of offset? Which PDU? The check cannot be turned off, this is by spec, see Vol. 3, Part F, Section 3.4.9 in the Bluetooth Core v5.0 for allowed error responses for the different methods. As you can see, there is no Invalid Offset for Write Request.

It should be possible to send application errors in the range of BLE_GATT_STATUS_ATTERR_APP_BEGIN to BLE_GATT_STATUS_ATTERR_APP_END, but I have never tested it myself. Have you tried?