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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 03, 2018 at 12:15:01PM -0800, 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.
> 
> 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.

As noted on the earlier version of this patch, this is not going to the
correct direction: the key needs to be set as soon as possible to be
able to receive encrypted frames from the AP. Those frame may be
delivered before the TX status for EAPOL-Key msg 4/4 gets to
wpa_supplicant. In other words, for this to be acceptable, the change
would need to configure the key for RX-only (and do this ideally before
sending msg 4/4) and then update that key to TX+RX once msg 4/4 gets TX
status. It would also be better to default to accepting ACK frame loss
than forcing disconnection. Disconnection could be forced if no data
frame TX/RX is detected during a short period following the TX status
indicating no ack.

> NOTE:  This does NOT fix the other complaint for the original
> patch about waiting longer to set the key..that still seems like
> a good thing to me so I didn't change that behaviour.

If you are referring to my previous comment here, I'm disagreeing with
this conclusion. There is no room for making this behave worse in the
expected success case in order to try to make the failure case recover
better. Both cases can be improved as long as the driver interface
provides means for RX-only keys and transfer from that to TX+RX; or
alternatively, this might also be doable with a TX operation for
EAPOL-Key that prevents encryption from being used even when the key is
already configured. That said, this would also need to take into account
PTK rekeying where the TX needs to be selected between the old key and
new key instead of no encryption vs. encryption.

-- 
Jouni Malinen                                            PGP id EFC895FA

_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux