Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 546C6602F2
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH 04/11] wil6210: fix PTK re-key race
From:   Kalle Valo <kvalo@codeaurora.org>
In-Reply-To: <1567931575-27984-5-git-send-email-merez@codeaurora.org>
References: <1567931575-27984-5-git-send-email-merez@codeaurora.org>
To:     Maya Erez <merez@codeaurora.org>
Cc:     Ahmad Masri <amasri@codeaurora.org>,
        linux-wireless@vger.kernel.org, wil6210@qti.qualcomm.com,
        Maya Erez <merez@codeaurora.org>
User-Agent: pwcli/0.0.0-git (https://github.com/kvalo/pwcli/) Python/2.7.12
Message-Id: <20190910132315.D7AC7602F2@smtp.codeaurora.org>
Date:   Tue, 10 Sep 2019 13:23:15 +0000 (UTC)
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Maya Erez <merez@codeaurora.org> wrote:

> Fix a race between cfg80211 add_key call and transmitting of 4/4 EAP
> packet. In case the transmit is delayed until after the add key takes
> place, message 4/4 will be encrypted with the new key, and the
> receiver side (AP) will drop it due to MIC error.
> 
> Wil6210 will monitor and look for the transmitted packet 4/4 eap key.
> In case add_key takes place before the transmission completed, then
> wil6210 will let the FW store the key and wil6210 will notify the FW
> to use the PTK key only after 4/4 eap packet transmission was
> completed.

This is rather ugly but I guess still ok. Or what do people think?

But for a proper fix you should look at:

[PATCH v2] wpa_supplicant: Send EAPoL-Key frames over NL80211 where available

http://lists.infradead.org/pipermail/hostap/2019-September/040516.html

-- 
https://patchwork.kernel.org/patch/11136851/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches