Try pairing when descriptor write fails #190
Conversation
|
@shmuelzon any comment on this? |
There was a problem hiding this comment.
Hey,
There was a reason why writing to a characteristic's descriptor has different logic than the rest.
I think the responses for it weren't consistent and the application would sometimes wait for a response that never came (causing us to hang and not dequeue the next operation).
See 156ce8b. It may have been a bug in ESP-IDF that was since fixed but I'm not even sure which peripherals had this issue so I can't test with them
| if (param->read.status == ESP_GATT_INSUF_AUTHENTICATION || | ||
| param->read.status == ESP_GATT_INSUF_ENCRYPTION) |
There was a problem hiding this comment.
These should probably check param->write.status.
| memcpy(write_buf, operation->value, operation->len); | ||
| write_buf_len = operation->len; |
There was a problem hiding this comment.
Why do we need these static variables? They should be part of the operation and remain there until we decide to dequeue it (after it was successful).
|
@shmuelzon how about this: |
shmuelzon
force-pushed
the
master
branch
2 times, most recently
from
7c19828
to
6ebee2a
Compare
The code tries pairing with a BLE device when an initial characteristic read operation fails, and then tries to read the value again after pairing.
Yet, there might be a failing descriptor write operation first, or no characteristic read at all.
Hence, this code adds handling of such a case by buffering every write, issuing pairing if needed and re writing the descriptor.
This code is just a starting point. @shmuelzon How would you buffer the writes?