Long Read with authorize: how to signal end of transfer

[Christian Waldmann]

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

[Hung Bui]

Hi Christian, 

The function should accept INVALID_OFFSET status code. I have reproduced the issue here it seems like a bug. I reported it internally and  will get back to you when we have an update. 

[Christian Waldmann]

Thank for invesitating this issue.

Please merge with this older thread: 

devzone.nordicsemi.com/.../long-read-with-authorize-how-to-reply-with-atterr_invalid_offset

[Hung Bui]

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 ? 

[Christian Waldmann]

Workaround is NOT working.

BLE_GATT_STATUS_ATTERR_INVALID_ATT_VAL_LENGTH is accepted as valid status, but with the value in the status the whole transfer is discarded.

So I return status SUCCESS and len=0, resulting in a malformed packed on the wire, but a "successful" transfer.

[Hung Bui]

Hi Christian, 

Could you explain a little bit more on what you meant by "whole transfer is discarded" ? You meant there were no read response in your case ? 

I have been reviewed the case with our R&D team, and seems that the proper way to handle this is actually what you suggested. 

According to mesh spec v5.0 at section 3.4.4.6 Vol 3 Part F, you can find this: 

If the value offset is equal to the length of the attribute value, then the length of the part attribute
value shall be zero.

Basically you can just return with SUCCESS and let the softdevice handle the error code or the length of the response. 

[Christian Waldmann]

Hello Hung Bui

I have missed to handle the BLE_GATT_STATUS_ATTERR_INVALID_ATT_VAL_LENGTH on client side, so it looks like the transfer is missing.

Both solutions (status = BLE_GATT_STATUS_ATTERR_INVALID_ATT_VAL_LENGTH or SUCCESS with length=0) work with my client now (pc-ble_interface).

The solution with SUCCESS and len=0 works also with an app on a iPhone as client, but with a "malformed package" on the wire. The other solution I have to approve in futur on an iPhone.

Thanks for investigations.