Are there security concerns here? Was the peer known to be authorized beforehand? Would it be better to just trash the peer in the event of a fw crash?
On Thu, Nov 28, 2019 at 11:46 PM Kalle Valo <[email protected]> wrote: > > Wen Gong <[email protected]> wrote: > > > After the firmware crashes ath10k recovers via ieee80211_reconfig(), > > which eventually leads to firmware configuration and including the > > encryption keys. However, because there is no new auth/assoc and > > 4-way-handshake, and firmware set the authorize flag after > > 4-way-handshake, so the authorize flag in firmware is not set in > > firmware without 4-way-handshake. This will lead to a failure of data > > transmission after recovery done when using encrypted connections like > > WPA-PSK. Set authorize flag after installing keys to firmware will fix > > the issue. > > > > This was noticed by testing firmware crashing using simulate_fw_crash > > debugfs file. > > > > Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1. > > > > Signed-off-by: Wen Gong <[email protected]> > > Signed-off-by: Kalle Valo <[email protected]> > > Patch applied to ath-next branch of ath.git, thanks. > > 382e51c139ef ath10k: set WMI_PEER_AUTHORIZE after a firmware crash > > -- > https://patchwork.kernel.org/patch/11263357/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches > _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k
