On 09/10/2017 02:27 AM, Jouni Malinen wrote:
On Tue, Jun 13, 2017 at 11:29:16AM -0700, greearb@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
