iPhone (and hostap) set Key Type=0 in the pairing NIK follow-up Shared-Key
Descriptor (key_info=0x1340) since the NIK is not a pairwise key. We required
the pairwise bit and rejected the frame before decryption, so the NIK
exchange timed out and pairing was torn down. Require only the Encrypted
Key Data bit.
ESP32-S31 uses the same trace encoder IP as ESP32-P4. Of the E-Trace v2.0
parameters the two targets report, only privilege_width_p differs (1 on P4,
2 on S31), and it affects both the sync packet layout and the filter's
privilege selector.
- Add the SOC_RISCV_TRACE_* caps for ESP32-S31 along with the esp32s31 LL, and
declare TRACE0/TRACE1 in the target's trace_struct.h.
- Carry privilege_width_p as SOC_RISCV_TRACE_PRIV_WIDTH so the sync packet
decoder can locate the address field, which starts one bit later on targets
that implement supervisor mode.
- Use the RISC-V architectural privilege encoding (0 user, 1 supervisor,
3 machine) in the public filter enum so the values do not change per target,
and let each LL narrow them to its own register field.
- Add riscv_trace_ll_priv_is_supported() per target, so a privilege level the
selector cannot represent is rejected with ESP_ERR_NOT_SUPPORTED rather than
being silently narrowed to a different level. It lives next to the narrowing
code so the two cannot drift apart.
- Fix trace buffer allocation on targets whose internal RAM is not reached
through a cache. esp_cache_get_alignment() reports 0 there, which underflowed
the size check and failed every allocation. Align base and size to the larger
of the reported cache line and the encoder's 4-byte write granularity.
Skip processing cxx/project_include.cmake when building subprojects such
as ULP as they use custom toolchain and IDF toolchain helpers are not
available.
On RISC-V without frame pointers, STACK_DEPTH defaults to 0, so
alloced_by[] is empty. Writing callers[0] still ran and overwrote the
caller's cm.push saved ra, causing an illegal-instruction fault after
the first traced malloc (e.g. with HEAP_TRACING on ESP32-S31).
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).
