[PATCH] wpa_supplicant: Wait for eapol 4/4 tx-status before setting key.

[Ben Greear]

On 09/10/2017 02:27 AM, Jouni Malinen wrote:
> On Tue, Jun 13, 2017 at 11:29:16AM -0700, greearb at candelatech.com wrote:
>> Supplicant is using generic L2 send function for EAPOL
>> messages which doesn't give back status whether frame has been
>> acked or not. It can lead to wrong wpa states when EAPOL 4/4
>> is lost i.e. client is in connected state but keys aren't
>> established on AP side.
>> Fix that by using nl80211_send_eapol_data as for AP side
>> and check in conneced state that 4/4 EAPOL has been acked.
>
> That part about tracking TX status sounds fine..
>
>> As a combined improvement, do not actually set the keys until
>> we receive notification that the 4/4 message was sent.  This fixes
>> races in ath10k CT firmware, and may eventually let other firmware
>> remove hacks that were needed to work around this key-setting
>> race.
>
> However, this is going to the wrong direction to work around an issue.
> The pairwise key (TK) needs to be set sooner, not later; but only for RX
> first. Delaying setting of the TK for RX will introduce more issues with
> Action frame RX when using PMF. There are number of cases where the AP
> sends a protected Action frame immediately after receiving the EAPOL-Key
> msg 4/4. Any extra delay on the station side will increase likelihood of
> dropping such frames. The correct way to fix this is to finally provide
> means for setting RX-only key that is then converted to TX+RX at a
> suitable point in time. In practice, doing EAPOL over nl80211 with extra
> flags for controlling whether to encrypt (and even more complicated,
> whether to use the previous key during PTK rekeying) may end up being
> the easiest way of fixing this.


I don't think there is any API that can do this for ath10k firmware
currently.

But, if I were able to fix the driver & firmware somehow to allow setting an
rx-key only, then I guess that should work for any type of frame, not just EAPOL?

In other words, is it *just* the need for setting an rx-only key, or are there
more strange issues that need to be resolved at the same time?

Even if I do this, it will probably not make it upstream since QCA is unlikely
to take my patches...but maybe that is OK and other vendors at least could
do the right thing in the future?

I guess a new netlink flag to the set-key command that was 'RX-ONLY' or similar
could be used on the set-key where it currently is in un-patched supplicant, and
then the normal set-key could be called after the 4/4 is received like in the patch
I posted?

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com