ESP-Zigbee: Router network steering fails to join coordinator-formed network

[Kartik D]

Hii all,
i am facing an issue regarding" Zigbee router fails network steering with ESP32-S3 + ESP32-H2 (RCP) gateway"
Setup:

- Gateway (coordinator): ESP32-S3 host + ESP32-H2 flashed as RCP, connected over UART
- Joining device: standalone ESP32-H2 running as Zigbee router
- ESP-IDF version: ESP-IDF 5.3.3
- esp-zigbee-lib / esp-zboss-lib versions: esp-zigbee-lib: 1.6.8 (commit 005fe007) & esp-zboss-lib: 1.6.4 (commit f83438b4
- RCP firmware: ESP-IDF 5.3.3 example
- Zigbee channel / channel mask: Dynamic channeling
- Wi-Fi on S3: enabled

Problem:

The router repeatedly fails BDB network steering. The gateway's MAC layer receives frames from the joining device (RSSI is strong, −26 to −49 dBm), and the coordinator even raises `NWK Device Associated` / `ZDO Device Update` signals — but the join never completes, and the gateway logs repeated OpenThread RCP transmit failures:

W OPENTHREAD:[W] P-RadioSpinel-: Handle transmit done failed: ChannelAccessFailure

This suggests the RCP is failing CCA on transmit, so association responses / beacon responses / transport key from the coordinator may never actually go out over the air.

## Observed behavior (three cases)

Case 1 — Gateway receives the frame but no response is seen over the air

Gateway logs:

I (2104425) [zigbee_utils]: MAC raw frame: 12 63 (RSSI=-29, LQI=96), frame_type = 2
W (2104519) OPENTHREAD:[W] P-RadioSpinel-: Handle transmit done failed: ChannelAccessFailure
I (2104536) [zigbee]: ZDO signal: NWK Device Associated (0x12), status: ESP_OK
I (2104540) [zigbee]: ZDO signal: ZDO Device Update (0x30), status: ESP_OK
W (2104669) OPENTHREAD:[W] P-RadioSpinel-: Handle transmit done failed: ChannelAccessFailure
W (2104839) OPENTHREAD:[W] P-RadioSpinel-: Handle transmit done failed: ChannelAccessFailure
I (2104875) [zigbee]: ZDO signal: NLME Status Indication (0x32), status: ESP_OK

The join stalls after `NWK Device Associated` — the router never receives the transport key.

Case 2 — Router only ever attempts stale/foreign PAN IDs, never the coordinator's actual PAN
Even we are clearing the NVRAM of the device while resetting it. so, it wont have any other paired data i.e pan-id etc
Router logs:

I (122652) Network steering was not successful (status: ESP_FAIL) with network (0xbc88)
I (125909) Network steering was not successful (status: ESP_FAIL) with network (0x709c)
I (129146) Network steering was not successful (status: ESP_FAIL) with network (0x709c)
I (132396) Network steering was not successful (status: ESP_FAIL) with network (0x709c)
I (138885) Network steering was not successful (status: ESP_FAIL) with network (0xbc88)


The coordinator's actual PAN ID at the time was 0x9c7a, which is never attempted. Only two other PAN IDs (0xbc88, 0x709c) cycle. It looks like the coordinator's beacon responses aren't making it out (consistent with the ChannelAccessFailure above), so the active scan only ever sees other networks.

Case 3 — Router-side steering failure with security/commissioning trace

Router (ESP32-H2) logs on every steering attempt:


I (258018) [zigbee]: Network steering was not successful (status: ESP_FAIL)
ZB_TRACE_LOG[1]: secur/zdo_secur.c:1936 zb_secur_get_link_key_by_address: start by index 5
ZB_TRACE_LOG[1]: secur/zdo_secur.c:1974 Can't find key for 00:00:00:00:00:00:00:00 attr 2
ZB_TRACE_LOG[1]: commissioning/bdb/zdo_commissioning_bdb.c:349 dev type 1, joined 0, ext_pan_id 0, authenticated 0, tclk_valid 1
ZB_TRACE_LOG[1]: zdo/zdo_app.c:202 zdo_secur_waiting_for_tclk_update ret 0
ZB_TRACE_LOG[0]: zdo/zdo_commissioning.c:212 Can't find PAN to join to! param 27
ZB_TRACE_LOG[1]: commissioning/bdb/zdo_commissioning_bdb.c:549 COMMISSIONING_STOP: app signal 10 comm status 3


What we've ruled out

- Our RSSI-based MAC frame filter is not dropping these frames. We install a raw frame handler on the gateway that drops frames below −90 dBm:

```c
bool esp_zb_mac_raw_frame_handler(const uint8_t *frame, const esp_ieee802154_frame_info_t *info)
{
bool ret = false; // false => accept frame, true => drop frame
if (info->rssi < MAC_STABLE_LINK_MIN_RSSI) // -90 dBm
{
ESP_LOGI(TAG, "Dropping frame due to weak RSSI = %d dBm and LQI = %d\n", info->rssi, info->lqi);
ret = true;
}
return ret;
}
```

All observed frames in these failures were at −26 to −49 dBm, well above the threshold, and no drop logs appear.

- Devices are physically close (RSSI −26 to −49 dBm), so this is not a range issue.

## Questions

1. Is the repeated `ChannelAccessFailure` from the RCP the likely root cause of the coordinator's responses (beacon response / association response / transport key) never reaching the joiner? This looks similar to IDFGH-13109 (esp-idf issue #14056).
2. Under what conditions does the H2 RCP report `ChannelAccessFailure` — is it purely CCA/noise, or can host↔RCP version mismatch or coexistence with the S3's Wi-Fi cause it even in a quiet RF environment?
3. Is there a recommended way to tune or diagnose CCA on the H2 in the RCP configuration (CCA threshold, retries), and is this exposed to the Zigbee host stack?
4. For Case 2, is there a way to force the router's active scan / steering to log all beacons it receives, to confirm whether the coordinator's PAN (0x9c7a) is ever seen over the air?

Any pointers appreciated — happy to provide sniffer captures or full logs.