issues with writable characteristic

RE: issues with writable characteristic

Carles — Mon, 01 Jun 2015 13:36:01 GMT

thanks again!

RE: issues with writable characteristic

RK — Mon, 01 Jun 2015 13:26:03 GMT

oops thought I had - must have misclicked - now marked properly.

RE: issues with writable characteristic

Carles — Mon, 01 Jun 2015 11:11:46 GMT

Sure, you're welcome. Thank you for the feedback, it will contribute to a better SD in the future. Can you mark the question as answered? Thanks!

RE: issues with writable characteristic

RK — Mon, 01 Jun 2015 10:56:54 GMT

I see looking at 2. again and see that if you have no authorised attributes and you provide user memory then the stack already has parsed out the values and committed them, I was originally confused by the phrase 'app parses the memory it provided' and thought it still needed to commit the values itself, now I see it doesn't. I wish I could use that, regrettably I have to validate the value on one written characteristic and provide an application error if invalid so I have to do the auth. Since I have to do it for one, I found the easiest code path is to do it for them all.

Thanks for the detailed explanation - that - plus some of the reading I did after posting the original question, has cleared it up a lot and I think I can improve my implementation a bit more.

RE: issues with writable characteristic

Carles — Mon, 01 Jun 2015 10:40:40 GMT

Yes the reason those 2 error codes you mention are not on that list is that we consider those to be only for internal stack usage. However I do agree that the INVALID_OFFSET and PREPARE_QUEUE_FULL should be made usable for the app too, since it can be handling its own queue. I have created an internal issue for that and hopefully we'll evaluate it and, if applicable, fix it soon. I understand that the application cannot know how much memory it will need, and neither can the stack, so that's why we pushed the decision up to the application so that it can be tested/tuned without having to update the SD

RE: issues with writable characteristic

RK — Mon, 01 Jun 2015 10:21:41 GMT

Thanks for the list of allowed error code , I was trying to figure it out. Is there a reason that neither BLE_GATT_STATUS_ATTERR_INVALID_OFFSET nor BLE_GATT_STATUS_ATTERR_PREPARE_QUEUE_FULL are in that list? Yes in this case I am handling the prepared write myself and not returning a memory chunk, that's unfortunate but necessary for this particular application for one particular characteristic. When you get the memory request you have no idea which characteristics are going to be in the prepared write (you can't know) so I have to return NULL and deal with it. That means however that I can run out of memory during a Prepare Write and should send QUEUE_FULL and when I process the queue later if there's an INVALID_OFFSET I'm supposed to return that, but can't because they're not on the list. I guess I'll use INSUF_RESOURCES for the first and ATT_VAL_LENGTH for the second but not ideal

RE: issues with writable characteristic

Carles — Mon, 01 Jun 2015 10:02:26 GMT

Hi there,

First of all, the answer you gave yourself to the first question is correct, and we implement the spec as it's written.

Let me try to answer your 2 remaining questions:

Characteristic properties are hints, nothing else. The stack treats those properties simply as raw data, and does not enforce any limitations based on them. They are populated by the application and they are supposed to be read/checked by the peer application, but ultimately only permissions are enforced by the stack. This is again per specification. I know it's a bit confusing, but if the stack was to enforce characteristic properties we would be violating the specification, since the only checks the ATT implementation is supposed to perform are permission-related checks. You mention prepare write operations, but the same is true for any other one (like a write request on a characteristic that doesn't have the write without response property set).
You are mixing two things here. If none of the attributes written to by the prepare writes require authorization (and you have provided memory to the stack with user_mem_reply), you will not get any RW_AUTHORIZE_REQUEST events. And in fact if you provide memory to the stack the queued writes will execute transparently just like any other write (request or command) would without you having a chance to approve/reject the operation, just like with any other write. See here for an example of this. If you on the other hand do not provide memory to the stack because you want to handle all prepare write operations yourself (see example here) then you can reply to each RW_AUTHORIZE_REQUEST with any of the ones allowed by the stack.

This is the list of errors you can use:

BLE_GATT_STATUS_ATTERR_INSUF_AUTHORIZATION
BLE_GATT_STATUS_ATTERR_INSUF_ENC_KEY_SIZE
BLE_GATT_STATUS_ATTERR_INVALID_ATT_VAL_LENGTH
BLE_GATT_STATUS_ATTERR_UNLIKELY_ERROR
BLE_GATT_STATUS_ATTERR_INSUF_RESOURCES
BLE_GATT_STATUS_ATTERR_READ_NOT_PERMITTED
BLE_GATT_STATUS_ATTERR_WRITE_NOT_PERMITTED
BLE_GATT_STATUS_ATTERR_INSUF_AUTHENTICATION
BLE_GATT_STATUS_ATTERR_INSUF_ENCRYPTION

along with application errors, which are the ones designed to notify the peer of application-level error conditions (like for example properties violated):

BLE_GATT_STATUS_ATTERR_APP_BEGIN <= error <= BLE_GATT_STATUS_ATTERR_APP_END

I understand that you need to deal with this when you're not interested at all in queued writes, but you have to bear in mind that queued writes are like any other write operation and the stack cannot simply reject it autonomously, just like it can't reject any other write operation unless it targets an attribute that is explicitly authorized.

Carles