Message Sequence Chart incorrect for queued writes with Authorization?

[Philip Odom]

I'm working on support for several custom characteristics that require long write support. I'm using the nrf_ble_qwr library, and I've noticed what seems to be a discrepancy between the message sequence charts and actual behavior.

We're using the nRF52832 with S132 softdevice 5.0.0, SDK 14.2.0

nrf_ble_qwr requires write authorization (wr_auth = true when adding characteristic). This corresponds, I believe to the message sequence chart "GATTS Queued Writes: Stack handled, one or more attributes require authorization" found here.

The chart indicates that there is no BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST event for the first data block, only the BLE_EVT_USER_MEM_REQUEST. Then, the chart shows a BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST event for the second (and presumably all subsequent) blocks.

In reality, I'm getting a BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST for the first block immediately after the BLE_EVT_USER_MEM_REQUEST and call to sd_ble_user_mem_reply(). This also makes more sense, as it allows the app (in this case the QWR library) to check authorization for the first block.

First, is this really an error, or am I missing something?

Second, if it is incorrect, it seems to be present in all of the versions of the documentation including the most recent. 

Finally, I haven't checked yet to be sure, but I assume that the BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST event would have to happen before the SD sends the ATT Prepare Write Response back to the peer for the first handle.

-Philip

[Sigurd]

Hi,

I see the same thing as you describe when testing with the ble_app_queued_writes example in the SDK. So this is a  documentation bug in the message sequence chart.

Thank you for reporting this.

EDIT: We took a closer look at the MSC. In the description it says “one or more attributes require authorization”. So there is a possibility that the first characteristic/attribute(handle_1) doesn't need authorization but the others require authorization(handle_2). It’s a bit confusing, especially since the corresponding “App handled” MSC handle_1 does requires authorization, so we will look into ways to change and make this MSC clearer in the future.