On 07/09/2017 12:28 AM, Ayun, Amir wrote:
-----Original Message-----
From: Hostap [mailto:hostap-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Ben
Greear
Sent: Friday, July 07, 2017 12:42 AM
To: hostap@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx wrote:
From: Wojciech Dubowik <Wojciech.Dubowik@xxxxxxxxxxx>
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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
