RE: [BUG] rtw88 8821ce: connection wedges (100% loss until reboot) with station power save

[Ping-Ke Shih <pkshih@realtek.com>]

Abdurrahman Karadag <abdurrahmankaradag19@gmail.com> wrote:
> Correction and new data.
> 
> First, a correction to my report: I have now hit the wedge with station
> power save OFF, so power save is not the trigger. My earlier "power_save
> off makes it stop" was coincidence on an intermittent bug. Please disregard
> the PS/smart_ps angle.
> 
> Second, I captured a wedge with Wireshark on wlan0 (802.3 view, i.e. at the
> netdev boundary), and the signature is much more specific than "connection
> wedges":
> 
>   - RX is fully intact, including unicast: DHCP OFFER/ACK addressed to my
>     MAC, an ICMP echo request from the router, TLS data from the router,
>     and the gateway's ARP requests sent *unicast* to me were all received.

Good to know RX is good. 

Can you setup another WiFi as monitor mode to capture 802.11 packets?

>   - My DHCP DISCOVER/REQUEST (342/345 bytes, L2 broadcast) reach the AP and
>     are answered within milliseconds - on two different APs (an Android
>     hotspot and a MikroTik router).
>   - 14-30 ms after those successful DHCP exchanges, my ARP requests for the
>     gateway (42 bytes, L2 broadcast; 89 of them, 1/s) get zero replies on
>     both networks.

Use another WiFi monitor to see if RTL8821CE actually transmitted the packets.

>   - The gateway ARPs *me* (unicast, 10 times at ~0.77 s intervals, then
>     falls back to broadcast). I receive every request and reply immediately
>     (42-byte unicast ARP reply) - yet it keeps asking, so my replies never
>     reach it.
>   - My TCP SYNs (78 bytes, unicast to the gateway MAC) get no SYN-ACK.
> 
> So the failing set is small STA->AP frames (42-byte ARP, both broadcast
> and unicast; 78-byte SYN) and the working set is 342-byte broadcast DHCP,
> with RX working throughout and no kernel/driver messages. Since DHCP
> succeeds tens of milliseconds before ARP fails, this looks like a
> per-frame property (frame size, or possibly ethertype) rather than a
> temporal stall. Two unrelated APs show the identical pattern, so it is
> not AP-specific. The interface stays associated; only a reboot clears it
> (a live driver reload froze the machine once, so I avoid that).
> 
> Next time it wedges I will run a size probe (static ARP entry for the
> gateway, then ping -s 8/56/200/400/1000) to confirm whether it is
> size-dependent, plus station-dump tx-failed/retry deltas and a
> neigh-flush -> reconnect -> link down/up ladder to see which layer holds
> the wedge. If there is anything specific on the 8821c TX side you would
> like me to dump (tx desc, debugfs, registers) while it is wedged, tell me
> and I will capture it.

I'm not sure why the size can affect the result. Normally large size
is harder to transmit basically though. 

Please fully turn off power save when you do the tests to reduce one
factor that can possibly cause TX slowly or stuck.

> 
> Capture available on request.

802.11 capture by another WiFi monitor is better.