issues with writable characteristic

Question

I have a service a writeable characteristic and I'm finding the following issues. 
 Characteristic is read/write, not variable length, size of 4, no read or write auth, no extended attributes (ie no reliable/long writes) 
 
 If I write the characteristic with more than 4 bytes (but less than 20) there's a correct 'invalid attribute value length' error returned. However if I write with less than 4 bytes the write succeeds and only some bytes of the value are updated, but the length remains at 4. Since it's fixed length, I would expect an invalid attribute value length error in this case too. 
 
 Edit: and I'm wrong for expecting that as someone kindly pointed me at the spec and it says 
 
 If the attribute value has a fixed
length and the Attribute Value
parameter length is less than or equal
to the length of the attribute value,
the octets of the attribute value
parameter length shall be written; all
other octets in this attribute value
shall be unchanged. 
 
 That still leaves the other two 
 
 If I send a prepared write for that
characteristic even though it's
fixed-length and doesn't have any
extended attributes (nor does any
other characteristic) I get a USER
MEM request and the rw_auth calls.
Since I'm not expecting any long
writes, I don't look for those
events or handle them. If a
characteristic is not set up for
reliable/long writes, why doesn't
the softdevice instantly reject the
prepare write with an error message?
I would expect the 'Attribute Not
Long' error. I would only expect to
ever get the user memory and
prepare/commit calls for attributes
which have the extended reliable_wr
property set true. 
 If I do try to handle the rw_auth and send back a proper error code, like 'Attribute Not Long'' the sd_ble_gatts_rw_authorize_reply() function returns an INVALID_PARAM error. It seems that I am only allowed to send a very few gatt_status codes, others are rejected as invalid params, why? 
 
 You can see this in the sample code too, if you run say the uart example and use lightblue to attempt to send a > 20 byte value to the writable characteristic, for which it will send out a prepare write, nothing will happen and eventually the connection will drop - this is because internally a memory request has been sent and not handled so the connection times out. It's true that a client ought to see the lack of extended characteristics and not attempt a prepared/long write, but if one is sent, the softdevice should reject it.

Carles · Accepted Answer

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

issues with writable characteristic

Top Replies