On 10/12/2018 11:04 AM, Roger James wrote: > Is this hardcoded limit part of some conformance protocol or could it made > configurable? > > Can this problem be attacked from the wpa_supplicant side? Maybe by > optimisation of the processing path of the response, or moving the > processing to a sudo realtime thread. > To my knowledge this is indeed a problem for many devices, though this is not actually caused by small timeout value (100 ms is relatively huge + I recall there are two more retransmissions?), but rather by delays/drops in network frame processing system. As EAPOL frames are just data frames, they go through normal data packet path therefore can be dropped/delayed as any data packet. Especially this is a problem for lower performance systems. Solution that was introduced to kernel is to do EAPOL exchange through nl80211 interface to prioritize these packets https://www.spinics.net/lists/linux-wireless/msg168828.html I don't think it's in wpa_supplicant though, and it requires support in a specific wireless driver. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
