On Mon, Dec 19, 2016 at 05:06:11PM +0100, Günther Kelleter wrote: > We are experiencing frequent deauthentication of Android stations due to > GTK rekey failures: EAPOL frames are not answered during the total timeout > peroid of 3.5 s. Increase retries to cover a bigger timeout period. That's quite unfortunate, but I'm not going to accept this change to hardcode a larger dot11RSNAConfig*UpdateCount value. We'll need to find a better way of addressing this. > IMHO a proper fix for this issue would be to implement retransmit timeouts as > mandated by 802.11-2012 Ch. 11.6.7.4: > "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." The parts here about 100 ms are not practical in real world and because of that, I have not implement this exact behavior. Nor do I think we should implement that either. However, it would be reasonable to think about the listen interval part here while ignoring the 100 ms part. > But 802.11 doesn't give any hints about the number of retries in > dot11RSNAConfigGroupUpdateCount. It does.. That's a configurable MIB variable with range of 1..4294967295 and default value of 3. hostapd is currently hardcoded to 4 because of this type of timeout issues. If someone wants to increase this above 4, I'd like to do that as a properly configurable parameter rather than hardcoded value since increasing the rekeying times unconditionally can be harmful for some use cases. > In our test case with Galaxy S6 the station announces a listen interval of > 10 beacon periods corresponding in 1.024 seconds. But it remains in power > save mode for about 5 seconds. That's not really nice behavior if that does indeed mean it fails to receive a unicast EAPOL-Key frames for five seconds when connected to an AP using 100 TU beacon interval. That would sound like something that would constantly fail the default IEEE 802.11 behavior for group rekeying.. > Isn't that a bug in Android which violates 802.11-2012 Ch. 10.2.1.8.a? > "The STA shall wake up early enough to be able to receive the first Beacon > frame scheduled for transmission at the time corresponding to the last TBTT > plus the ListenInterval." This is driver specific functionality, so I would not consider it as a generic Android issue, but anyway, this is an area where various vendors do various things to save power regardless of what the standard says.. So yes, it might be noncompliant with the standard, but a compromise may be needed here.. It would be nicer to advertise a larger Listen Interval value in that case, though. Some APs might reject the association if a larger value is used there which may make it less convenient for vendors to advertise the accurate value. > This Android bug would still require dot11RSNAConfigGroupUpdateCount to be at > least 6 for successful GTK rekeying. That or using longer retry time based on not receiving an ACK from the STA. As noted above, I don't really want to increase the hardcoded value for all cases, but conditionally allowing larger number of TX tries or longer wait for a response when the STA does not ACK any of the frames could be a reasonable compromise to address the case where a STA is indeed in sleep and not receive any of the frames. If the frame remains in local TX queue waiting for the STA to wake up, there would be no TX status events at all. If the driver is known to support TX status events for EAPOL frames, local timeout could be adjusted based on not having received the event to detect this case. > Obviously the same applies to PTK rekeying, where 802.11 mandates the same > interval specification. PTK rekeying has somewhat different requirements since it does not block key changes for every other STA in the BSS. As such, it might be easier to justify larger number of retries or longer timeouts there. > Is there a reason that hostapd does not implement retransmit timeouts as > mandated by 802.11? Yes, the standard behavior is not ideal in real world and does not take into account the possibility of using TX status (ACK frames) to adjust behavior. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
