In the Bluetooth connections with some smartphones, communication can possibly be blocked
during packet type negotation, when ESP32-S31 attempts to finalize the ACL-U transmission
and waits for the last Tx ACL-U packet to be transmitted, but peer device rejects the
packet with FLOW=STOP in its packet, thus causing a deadlock.
Closes https://github.com/espressif/esp-idf/issues/18797
This MR also provide with some optimizations and fixes
When PORT_RX_BUF_LOW_WM is too low, RFCOMM replenishes credits only
after receiving a relatively large number of packets, which may cause
the peer to exhaust its credits and enter a stop-and-wait state.
Increase the low watermark to replenish credits more promptly and
reduce the likelihood of the peer stalling while waiting for additional
credits.
- Fixed the state machine issue caused by security related LMP procedures on ESP32-S31
- Fixed the issue of insufficient air time for ACK reception from the Central on ESP32-S31
- Fixed the page scan collision issue on ESP32-S31
- Fixed read failures for local supported features and extended features on ESP32-S31
- Fixed NULL access issue during SYNC disconnection on ESP32-S31
- Fixed ACL schedule issue during SYNC connection establishment on ESP32-S31
The TX power range configurable in menuconfig only describes the maximum possible range.
Add a function to report the real range, and validate the configured BR/EDR TX power values during conroller init.
Before:
The cache won't be disabled when XIP on psram. But during flash
erasing/programming, read data will be courrupt.
When XIP in psram is enabled, the image is not mapped to the cache so
usually there will be no flash access. The only way to read from flash
is via the driver or use mmap. The driver has protection during erasing,
while th mmap region not.
Now:
Mmap APIs provide a flag to make mmap->unmap region mutually exclusive
to flash erase/programming when XIP from psram. SPI Flash write APIs
will benefit from this. When the flag is used, no concurrent access to
mapped region will happen while writing; otherwise the cache will be
disable to avoid data corruption.
Most ESP-IDF APIs calls mmap with this flag. As for users calling
mmap-like APIs directly, they can choose whether to enable this by a
flag.
Closes https://github.com/espressif/esp-idf/issues/14897
Only update extend_adv_cb after HCI Set Extended Advertising
Parameters succeeds, so a failed update does not corrupt cached
legacy_pdu and related fields used by adv data validation.
(cherry picked from commit 31bd80fee8)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
Map received error reason 0x00 to GATT_UNKNOWN_ERROR so the client
does not report GATT_SUCCESS with zero-length data on malformed errors.
(cherry picked from commit 1b6f9380f4)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
When sending an ATT error response after a failed server operation,
use p_tcb->sr_cmd.status instead of the last app callback status so
invalid error code 0x00 is not sent to the peer.
(cherry picked from commit 4c0488d92a)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
Read Multiple may mix stack auto-responses with app async responses,
so multi_rsp_q order can differ from the request handle order. Look up
each response by handle (with occurrence for duplicates) instead of
walking the queue by index, and treat opcode-only buffers as empty.
(cherry picked from commit f91a41510c)
Co-authored-by: zhanghaipeng <zhanghaipeng@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>
