RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

ValentinKunti — Thu, 11 Jun 2026 12:09:54 GMT

We kept the sniffer running and re-analysed a fresh session at the raw 802.11 layer. Two refinements to the original report, the second one extends it.

1. The clearest reproduction is gateway ARP, no decryption needed at all

Every failed DNS cycle in 10 capture sessions failed with -ENETUNREACH: the DNS server is the gateway, and the gateway's ARP reply is what gets lost. The pattern, one failed and one successful attempt 4 s apart in the same association (device 14:e2:89:11:1e:32, gateway behind the AP 70:a7:41:f7:57:e6, RSSI -60):

failed attempt
40.836  STA → broadcast   ARP request (QoS Data, 134 B)
40.850  GW  → STA         ARP reply, first delivery        +14 ms
40.852  STA → AP          Null PM=1                        sleep announced 16 ms after own TX
40.850 .. 40.870  GW → STA  14 copies, wlan.fc.retry=1, none ACKed, AP gives up
   next beacon TIM: partial virtual bitmap 78bb07 → 7abb07 = AID 1 (us) now buffered
40.938 .. 44.35   STA sends Null PM=0 / PM=1 several times, AP delivers nothing,
                  TIM bit for AID 1 stays set the whole time

successful attempt, same association, 4 s later
44.841  STA → broadcast   ARP request
44.841 .. 44.851  GW → STA  ~20 copies of the reply, STA finally ACKs one ~10 ms in
44.851  STA → GW          DNS query, cycle proceeds normally

In another window the reply arrived 0.7 ms after the device's own transmission and was already lost. So the receiver is off essentially at TX completion, and whether a connection attempt works is a race between the RPU re-opening its RX and the AP exhausting its MAC retry budget (16 to 19 retransmissions in 5 to 10 ms). This also explains why CONFIG_NRF70_RPU_PS_IDLE_TIMEOUT_MS 10/25/100 ms made no difference for us: the reply lands inside any of those windows.

2. When PM=1 is sent, the buffered frame is still never retrieved

This is the part that is new compared to the original post. In the ARP case above the station did announce PM=1 (16 ms after its TX, 2 ms after the first delivery had already died un-ACKed). The AP then does everything right: it buffers the next reply and sets the TIM bit for AID 1, verified in the beacons (78bb07 → 7abb07, bitmap offset 0). The station announces PM=0 several times over the following 3.5 s and the AP delivers nothing; the TIM bit stays set until the station gives up and re-ARPs. So both legs of power save fail: receiving while advertised active, and retrieval of buffered traffic after advertised sleep. Tuning the exit strategy so the AP buffers more (EVERY_TIM) cannot help if the pickup never happens.

One more data point: the station's own Null and data frames are sent 3 to 4 times back to back (retry=1), so it also misses the AP's ACKs to its own transmissions right after TX, consistent with the RX being gated off at TX completion.

This narrows question 2 from the original post: even when the PM=1 Null does go out and the AP buffers correctly, why does the RPU not collect the buffered frame on its next wake?