On 12/1/19 8:45 PM, Justin Capella wrote:
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?
I think you should completely re-associate the peer(s) when firmware
crashes. The driver does not cache all possible changes, so it cannot
exactly rebuild the config to the previous state.
Thanks,
Ben
On Thu, Nov 28, 2019 at 11:46 PM Kalle Valo <kv...@codeaurora.org> wrote:
Wen Gong <wg...@codeaurora.org> 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 <wg...@codeaurora.org>
Signed-off-by: Kalle Valo <kv...@codeaurora.org>
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
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
