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