# Matter-over-Wi-Fi: device-originated TX fails on nRF54LM20 + nRF7002 (operational path), CASE/mDNS time out with error 32

## Summary

On **nRF54LM20DK + nRF7002 EB II**, running the **Matter `light_bulb` sample** over Wi-Fi,
the device commissions and operates correctly for a short period, then **device-originated
Wi-Fi transmits stop reaching the network**. Unicast (CASE / IM messages) and multicast
(mDNS) TX both fail: the CHIP stack hands packets down and the nRF70 driver accepts them,
but the peer never receives them. All retransmissions exhaust, the operational secure
session goes `kDefunct`, mDNS resolution times out, and CASE re-establishment fails with
**CHIP error 32 (CHIP_ERROR_TIMEOUT)**. The device never recovers without a power cycle.

**Inbound Wi-Fi RX continues to work** during the failure (the device keeps receiving
`InvokeCommandRequest` and duplicate messages from the controller and ACKs them). The
failure is one-directional: **outbound TX on the operational path**.

This matches the earlier-reported behavior (works ~1–6 min after commissioning, then
permanent `Timeout waiting for mDNS resolution` / `operational discovery failed: 32`).

## Environment

| Item | Value |
|------|-------|
| Board | `nrf54lm20dk/nrf54lm20a/cpuapp` |
| Shield | `nrf7002eb2` |
| NCS | v3.3.4-b096d30d893b |
| Zephyr | v4.3.99-37e6c28576ee |
| nRF70 FW patch | v1.2.14.8 |
| RPU LPM | **DISABLED** (`CONFIG_NRF_WIFI_LOW_POWER=n`) |
| Sample | `nrf/samples/matter/light_bulb` |
| Debug | `nrf70-driver-verbose-debug` snippet, `CONFIG_BT_RX_STACK_SIZE=22000` |
| AP | 2.4/5 GHz, RSSI at device = -37 dBm (strong) |

Note: this is a **mains-powered** design; Wi-Fi power-save is intentionally OFF
(`RPU LPM type: DISABLED` confirmed at boot). So this is NOT the low-power
re-association issue (KRKNWK-17864).

## Build command

```
west build -p -b nrf54lm20dk/nrf54lm20a/cpuapp \
  --build-dir <build> <ncs>/nrf/samples/matter/light_bulb -- \
  -DSHIELD=nrf7002eb2 -DSB_CONFIG_WIFI_NRF70=y -DCONFIG_CHIP_WIFI=y \
  -DCONFIG_NRF_WIFI_LOW_POWER=n \
  -Dlight_bulb_SNIPPET="nrf70-driver-verbose-debug" \
  -Dlight_bulb_CONFIG_BT_RX_STACK_SIZE=22000
```

## Observed sequence (from attached verbose log)

1. **Boot / connect (healthy):**
   - `Firmware (v1.2.14.8) booted successfully`, `RPU LPM type: DISABLED`
   - `Connection to Netanel requested [RSSI=-37]` -> `Connected to WiFi network`
   - Association + auth complete; device reaches operational and CASE sessions establish.

2. **Operational (working, briefly):** the device correctly handles controller commands:
   - `app: Turn On Action has been completed`
   - `ZCL Cluster LevelControl: attribute CurrentLevel set to 254`
   - `app: Setting brightness level to 254`
   - Bidirectional traffic: `Msg TX ... InvokeCommandResponse/ReportData` over UDP,
     followed by `Msg RX ... StatusResponse` and `Received status response, status is 0x00`.
   - **However, retransmissions already appear here** — some outbound messages need
     1–4 retries before being ACKed, indicating a marginal TX path even while "working".

3. **Degradation -> permanent failure:**
   ```
   <err> [EM] Msg Retransmission to 1:... failure (max retries:4)
   [SC] SecureSession[...]: State change 'kActive' --> 'kDefunct'
   <err> [DIS] Timeout waiting for mDNS resolution.
   <err> [DMG] Time out! failed to receive status response from Exchange: ...
   <err> [DIS] OperationalSessionSetup[...]: operational discovery failed: 32
   <err> [DMG] Failed to establish CASE for subscription-resumption with error '32'
   ```
   After this, the CHIP layer goes silent; the nRF70 driver log shows only endless
   `Event type 2 recd` / `Event 3 received from UMAC` (RPU alive, but no useful TX).
   The device does not recover without a power cycle.

Key point: the RPU/host bus stays alive throughout (SPI comms fine), and the device keeps
**receiving**. It is specifically **device-originated transmit** that stops being delivered.

## Why we believe it is a TX-path issue (not app/config)

- `CONFIG_NRF_WIFI_LOW_POWER=n` (verified `RPU LPM type: DISABLED`) — not the low-power bug.
- Inbound RX works during the failure (controller messages received and ACKed).
- Both unicast (CASE) and multicast (mDNS) outbound fail together.
- CHIP reports messages as sent; peer never receives them -> retransmit exhaustion -> error 32.
- Strong RF (RSSI -37), so not a link-margin issue.

## Question for Nordic

1. Does **anomaly 20 "CLOCK: RADIO payload is not transmitted"** (documented for nRF54L05/L15:
   *"Preamble is correctly transmitted but all following payloads are not transmitted"* when the
   MCU power domain sleeps during RADIO TX) apply to **nRF54LM20** with the nRF7002 companion,
   and could it explain device-originated Wi-Fi TX not reaching the peer? If so, what is the
   correct driver/SoC workaround for this SDK (e.g. constant-latency handling)?
2. If not anomaly 20, what in the nRF70 TX data path on nRF54LM20 (NCS v3.3.4) could cause
   accepted-but-undelivered transmits that degrade over minutes and end in permanent failure?
3. Is there a fix or newer nRF70 FW patch targeting this for nRF54LM20?

## Attachments

- `nordic_full_log.txt` — complete verbose log from boot through Wi-Fi connect (nrf70-driver-verbose-debug).
- `nordic_excerpt_operational_failure.txt` — filtered excerpt: working light control ->
  retransmit failures -> session defunct -> mDNS timeout -> CASE error 32.
