Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote: > When there is beacon loss, for example due to unrelated Bluetooth > devices transmitting music nearby, the wifi connection dies soon > after the first beacon loss message: > > Apr 28 20:47:14 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4: > CTRL-EVENT-BEACON-LOSS > Apr 28 20:47:15 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4: > CTRL-EVENT-DISCONNECTED bssid=... reason=4 locally_generated=1 > > Apr 28 20:47:24 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4: > CTRL-EVENT-BEACON-LOSS > Apr 28 20:47:25 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4: > CTRL-EVENT-DISCONNECTED bssid=... reason=4 locally_generated=1 > > Apr 28 20:47:34 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4: > CTRL-EVENT-BEACON-LOSS > Apr 28 20:47:35 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4: > CTRL-EVENT-DISCONNECTED bssid=... reason=4 locally_generated=1 > > When the beacon loss happens, mac80211 makes rtw88 transmit a QOS > NULL frame and asks to confirm the ACK status. Even though rtw88 > confirms to mac80211 that the QOS NULL was transmitted successfully, > the connection still dies. This is because rtw88 is handing the QOS > NULL back to mac80211 with skb->data pointing to the headroom (the > TX descriptor) instead of ieee80211_hdr. > > Fix the disconnection by moving skb->data to the correct position > before ieee80211_tx_status_irqsafe(). > > The problem was observed with RTL8811AU (TP-Link Archer T2U Nano) > and the potential future rtw88_8821au driver. Also tested with > RTL8811CU (Tenda U9). > > Cc: stable@xxxxxxxxxxxxxxx > Signed-off-by: Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> 1 patch(es) applied to rtw-next branch of rtw.git, thanks. 28818b4d871b wifi: rtw88: usb: Fix disconnection after beacon loss --- https://github.com/pkshih/rtw.git
