On 15 October 2018 20:35:35 Igor Mitsyanko
<igor.mitsyanko.os@xxxxxxxxxxxxx> wrote:
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.
Hi Igor,
Thanks for the interesting response. It has given me some new lines of inquiry.
The logs I am getting from wpa_supplicant seem to show me that at least for
the case of the raspberry pi zero w it does not it does not get as far as
sending a response to the to the initial EAPOL message before it gets a
timeout rejection from the AP.
I am still trying to analyse exactly what is going on in wpa_supplicant.
Roger
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
