This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Long Read with authorize: how to signal end of transfer

I am implementing long read with authorization in the server (peripheral). I have a characteristic with vlen = 1 and maxlen = 300. ATT_MTU = 23.

gatts_attr_md.vlen = true;
gatts_attr_md.vloc = BLE_GATTS_VLOC_USER;
gatts_attr_md.rd_auth = true;
gatts_attr_md.wr_auth = true;

The handling on server side is done when a BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST with BLE_GATTS_AUTHORIZE_TYPE_READ arrives. Data for response is prepared and the answer is sent with sd_ble_gatts_rw_authorize_reply().

To transfer a value with len = 30, the client reads first with offset=0 and gets back 22 data bytes. Because len in response == ATT_MTU-1 the client has to read again with offset = 22 and gets back the response with len=8 and the remaining 8 bytes. Client knows now that the transfer is over because len < ATT_MTU-1.

When the length of the data is len = 44, the client reads with offset = 22 and gets back len=22 and the remaining 22 bytes. Now the client has to read a third time with offset= 44 to be sure to have read all bytes.

My question is now: What is the correct answer from server to this third request to inform the client that there are no more data to read?

When trying to answer with INVALID_OFFSET, I get the INVALID_PARAMETER error.

When I answer with len=0, I get a "[Malformed packet]" on the wire (nrfSniffer).

I am using SDK 15.2, SoftDevice s132 V6.1, custom board with nrf52832

Parents Reply
  • Hi  Christian, 

    I got the confirmation from the team that it's actually a bug in the softdevice.  

    We will include a fix for that in the next release of the softdevice. But I don't know when it will be out. 

    For now there is a workaround is to use BLE_GATT_STATUS_ATTERR_INVALID_ATT_VAL_LENGTH as the response, instead of BLE_GATT_STATUS_ATTERR_INVALID_OFFSET .

    Could you please try and let me know if it would work fine ? 

Children
Related