bt_mesh_bta_gatts_cb did not always answer ATT Read/Write Requests:
- READ: on a callback error it only logged a warning and sent nothing; a
0-byte read (Read Blob at an offset equal to the value length) also sent
nothing, although it is a successful empty read.
- WRITE: on a callback error it sent nothing, and a partial/zero write was
treated as success.
- Both: when the handle was not found or the attribute had no read/write
callback, the request was silently dropped.
An ATT Request must always be answered:
- READ: len >= 0 is success -> Read Response (a 0-byte read yields an empty
value); len < 0 -> ATT Error Response carrying the callback's error code
(-len, since BLE_MESH_GATT_ERR(x) == -x). The copy length is clamped to
the source buffer size as a defensive bound. If the handle is unknown or
the attribute has no read callback, respond with INVALID_HANDLE /
READ_NOT_PERMITTED.
- WRITE: when need_rsp is set, always reply. len == write length -> Write
Response; otherwise (negative ATT error, partial write, or 0) -> ATT
Error Response (the negative code, or UNLIKELY for partial/0). If the
handle is unknown or the attribute has no write callback, respond with
INVALID_HANDLE / WRITE_NOT_PERMITTED. Write Without Response still sends
no response.
A non-success status passed to BTA_GATTS_SendRsp is turned into an ATT
Error Response by the GATT layer (gatt_sr_process_app_rsp ->
gatt_send_error_rsp).
(cherry picked from commit ed1f4de3a3)
Co-authored-by: luoxu <luoxu@espressif.com>
The reassembly buffer must be reset to its origin at the beginning of every
transaction. prov_msg_recv() pulls the PDU type byte (advancing buf->data by
one) and nothing restores it between transactions. Without this reset,
buf->data drifts forward by one byte per received PDU, causing the segment-0
memcpy to write past the end of the statically allocated rx buffer
(PROV_RX_BUF_SIZE), and the XACT_SEG_DATA() offsets used for continuation
segments to be skewed by the accumulated drift.
(cherry picked from commit 2c4acaa2aa)
Co-authored-by: luoxu <luoxu@espressif.com>
Fix multiple wire-format and robustness issues in the DFD client
(dfd_cli.c):
- handle_capabilities: read oob_retrieval_supported as u8 instead of
le32. The server encodes a single byte; le32 over-consumed 3 bytes
of the URL scheme list and could over-read the buffer.
- handle_upload_status: extract upload_progress from bits 0-6 (& 0x7F)
and upload_type from bit 7 (>> 7), matching the server encoding
(progress | BIT(7)). The previous >>1 / &0x01 returned wrong values,
mis-classified in-band vs OOB, and falsely rejected valid OOB
messages with high progress.
- handle_dfd_status: correct the transfer-mode byte layout to
trans_mode bits 0-1, update_policy bit 2, RFU bits 3-7 (previously
read bits 6-7 / 5), and fix the RFU mask to 0xF8. Now matches the
struct bitfield definition and the DFD server.
- handle_dfd_status: report status+phase and return early when
buf->len == 0 (IDLE phase) instead of pulling 10 absent bytes.
- bt_mesh_dfd_cli_distribution_start: encode trans_mode/update_policy
into bits 0-2 so the server decodes them correctly.
- handle_receiver_list: validate buf->len >= entries_cnt * 5 before
the loop, and handle entries_cnt == 0 without relying on calloc(0).
- handle_receiver_status: pass the status value (not the whole union)
to the %d log format, fixing undefined behavior.
- dfd_client_recv_status: drop the dead BLE_MESH_DFD_OP_CAPABILITIES_GET
case (a client-send opcode) from the receive switch.
- bt_mesh_dfd_cli_receivers_add: widen msg_length to uint32_t to avoid
uint16_t overflow that bypassed the PDU size guard; add a NULL check
for the receivers array.
- bt_mesh_dfd_cli_distribution_upload_oob_start: return -EINVAL
instead of -1 for consistency with the rest of the file.
(cherry picked from commit 43137475e1)
Co-authored-by: luoxu <luoxu@espressif.com>
The protocol may still receive DFU-related packets from the
network (such as forwarded or retransmitted ones) after DFU ends,
while the user might release the targets immediately after DFU completion.
However, since the list head is not empty, the protocol could access
already-freed memory when iterating through the targets.
- Fix DFU server transfer error state ordering to ensure proper callback delivery
- Add validation to discard chunks when blob server is not in busy state
- Prevent chunk processing when server is not in active transfer state