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

[Ben Greear]

On 07/09/2017 12:28 AM, Ayun, Amir wrote:
>> -----Original Message-----
>> From: Hostap [mailto:hostap-bounces at lists.infradead.org] On Behalf Of Ben
>> Greear
>> Sent: Friday, July 07, 2017 12:42 AM
>> To: hostap at lists.infradead.org
>> Cc: Wojciech Dubowik
>> Subject: Re: [PATCH] wpa_supplicant: Wait for eapol 4/4 tx-status before
>> setting key.
>>
>> On 06/13/2017 11:29 AM, greearb at candelatech.com wrote:
>>> From: Wojciech Dubowik <Wojciech.Dubowik at neratec.com>
>>>
>>> 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.
>>>
>>> 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.
>>
>> Any comments on this?  We have been testing it for a while, and it seems to
>> work well.
>
> I think that delaying the 'set_key' too much might also be problematic since it may raise interop issues
> where we might lose the first frames sent from the remote device which will be already encrypted.

It should not delay it by more than a milisecond or so, and most of the time stations are going
to do DHCP before the AP will send them anything useful?

Without having supplicant wait, drivers/firmware are forced to implement various hacks and/or
just accept races and retry when things go wrong.  At least things like ath10k firmware are still
going to wait for the ACK to actually set the key, but they will do all of that logic in firmware
instead of supplicant, which complicates and adds bugs to the firmware.

Thanks,
Ben

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