Hi Jouni Thank you for the valuable comments > -----Original Message----- > From: Jouni Malinen [mailto:j@xxxxx] > Sent: Thursday, December 22, 2016 1:59 PM > To: Guenther Kelleter <Guenther.Kelleter@xxxxxxxxx> > Cc: hostap@xxxxxxxxxxxxxxxxxxx > Subject: Re: [RFC PATCH] Increase GTK/PTK rekey retries > > 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. I did some tests with a Windows 7 netbook. Regardless of the AP's announced Beacon interval it always announces a listen interval of 10. But: the time in power save mode seems to depend somehow on the beacon interval, at least for lower BI. BI=100: sleep time max ~1s (max ping delay detected) BI=200: sleep time max ~2s BI=1000: sleep time max ~4s And then if the station is scanning off channel time is always >3s regardless of the BI. My conclusion is depending on the listen interval wouldn't fix anything here in general. So I'm not implementing this now, it requires more evaluation with real world devices. > > > 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 You're right, I finally found the default definition in the MIB. > 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 But how often should it be retried in this case? Would require another (hardcoded) upper limit of the retries for non-ack case. > 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. Hmm, drivers not supporting TX status would nevertheless require the configurable dot11RSNAConfigGroupUpdateCount. So I'll send a new patch to make both UpdateCounts configurable. > > > 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 Günther _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
