On Fri, Oct 12, 2018 at 07:04:41PM +0100, Roger James wrote: > Hostapd has a hardcoded timeout length for receiving the response to initial > authentication message. > > static const u32 eapol_key_timeout_first = 100; /* ms */ in wpa_auth.c > > I have done a number of experiments testing the reliability of small soc > devices connecting to wifi access points. My test system is Raspberry Pi > Zero which is based on the Broadcom BCM2835 soc and BCM43438 wifi chips. > > Using wpa_supplicant for WPA2-PSK support struggle to respond to reliably > respond to the nonce within the 100 ms limit. I suspect this is at root of > the numerous problem reported with wifi connections with these type of > units. Do you have a sniffer capture that could be shared to show the exact timing of those EAPOL-Key frames? Some low-power devices may have significant latency in waking up the needed system modules to process frames and that might take more than 100 ms in some cases. That said, most such cases should not really be applicable to the EAPOL-Key msg 1/4 which is immediately following the association.. Furthermore, even if one were to miss this timeout, there will be three more attempts with 1000 ms timeout to give more than three seconds of time for the station to reply to any of the pending EAPOL-Key messages. > Is this hardcoded limit part of some conformance protocol or could it made > configurable? It is mandated by the standard.. IEEE Std 802.11-2016, 12.7.6.6.4: "If the Authenticator does not receive a reply to its messages, it shall attempt dot11RSNAConfigPairwiseUpdateCount transmits of the message, plus a final timeout. The retransmit timeout value shall be 100 ms for the first timeout, half the listen interval for the second timeout, and the listen interval for subsequent timeouts. If there is no listen interval or the listen interval is zero, then 100 ms shall be used for all timeout values." That said, most vendors tweak these values to some extend. I'm not sure it would make much sense to change the initial value, though, unless there is a clearly demonstrable case where a station goes to power save sleep before the AP has a chance to send out EAPOL-Key msg 1/4.. The Listen interval part is something I've considered implementing in hostapd so that the 1000 ms subsequent timeouts could be incremented (but not decremented) for stations that use power saving with very long interval between fetching buffered frames. > 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. I would be surprised if that actually worked.. I've seen response times in couple of millisecond time frame when using drivers that do not use excessive power saving mechanisms, i.e., it main reason for latency is likely somewhere else than within wpa_supplicant. At minimum, I'd recommend taking a much more detailed look at a sniffer trace and ideally some timestamped debug information from the driver/firmware to figure out where the delays are before using much effort in trying to modify wpa_supplicant behavior for this. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
