| Message ID | 20161219160611.12862-1-guenther.kelleter@devolo.de |
|---|---|
| State | Changes Requested |
| Headers | show |
Hi I forgot to add the log which shows the error case: Hostapd tries to negotiate a new GTK 4 times with timeouts 500ms, 1s, 1s, 1s before giving up and deauthenticating the station. Log shows that the EAPOL messages are all acked only after 4s when the deauthentication already finished. (log filtered for specific MAC address and 'EAPOL') Dec 15 17:09:12 192.168.19.225 hostapd: WPA: e8:50:8b:xx:xx:xx WPA_PTK_GROUP entering state REKEYNEGOTIATING Dec 15 17:09:12 192.168.19.225 hostapd: WPA: Send EAPOL(version=2 secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=24 keyidx=2 encr=1) Dec 15 17:09:12 192.168.19.225 hostapd: Plaintext EAPOL-Key Key Data - hexdump(len=32): [REMOVED] Dec 15 17:09:12 192.168.19.225 hostapd: WPA: Use EAPOL-Key timeout of 500 ms (retry counter 1) Dec 15 17:09:13 192.168.19.225 hostapd: WPA: e8:50:8b:xx:xx:xx WPA_PTK_GROUP entering state REKEYNEGOTIATING Dec 15 17:09:13 192.168.19.225 hostapd: WPA: Send EAPOL(version=2 secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=24 keyidx=2 encr=1) Dec 15 17:09:13 192.168.19.225 hostapd: Plaintext EAPOL-Key Key Data - hexdump(len=32): [REMOVED] Dec 15 17:09:13 192.168.19.225 hostapd: WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 2) Dec 15 17:09:14 192.168.19.225 hostapd: WPA: e8:50:8b:xx:xx:xx WPA_PTK_GROUP entering state REKEYNEGOTIATING Dec 15 17:09:14 192.168.19.225 hostapd: WPA: Send EAPOL(version=2 secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=24 keyidx=2 encr=1) Dec 15 17:09:14 192.168.19.225 hostapd: Plaintext EAPOL-Key Key Data - hexdump(len=32): [REMOVED] Dec 15 17:09:14 192.168.19.225 hostapd: WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 3) Dec 15 17:09:15 192.168.19.225 hostapd: WPA: e8:50:8b:xx:xx:xx WPA_PTK_GROUP entering state REKEYNEGOTIATING Dec 15 17:09:15 192.168.19.225 hostapd: WPA: Send EAPOL(version=2 secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=24 keyidx=2 encr=1) Dec 15 17:09:15 192.168.19.225 hostapd: Plaintext EAPOL-Key Key Data - hexdump(len=32): [REMOVED] Dec 15 17:09:15 192.168.19.225 hostapd: WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 4) Dec 15 17:09:16 192.168.19.225 hostapd: WPA: e8:50:8b:xx:xx:xx WPA_PTK_GROUP entering state REKEYNEGOTIATING Dec 15 17:09:16 192.168.19.225 hostapd: WPA: e8:50:8b:xx:xx:xx WPA_PTK_GROUP entering state KEYERROR Dec 15 17:09:16 192.168.19.225 hostapd: WPA: e8:50:8b:xx:xx:xx WPA_PTK entering state DISCONNECT Dec 15 17:09:16 192.168.19.225 hostapd: wpa_sta_disconnect STA e8:50:8b:xx:xx:xx Dec 15 17:09:16 192.168.19.225 hostapd: hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA e8:50:8b:xx:xx:xx reason 2 Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: send_mlme - da= e8:50:8b:xx:xx:xx noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xc0 (WLAN_FC_STYPE_DEAUTH) nlmode=3 Dec 15 17:09:16 192.168.19.225 hostapd: wlan1: AP-STA-DISCONNECTED e8:50:8b:xx:xx:xx Dec 15 17:09:16 192.168.19.225 hostapd: addr=e8:50:8b:xx:xx:xx Dec 15 17:09:16 192.168.19.225 hostapd: ap_sta_disconnect: reschedule ap_handle_timer timeout for e8:50:8b:xx:xx:xx (5 seconds - AP_MAX_INACTIVITY_AFTER_DEAUTH) Dec 15 17:09:16 192.168.19.225 hostapd: WPA: e8:50:8b:xx:xx:xx WPA_PTK_GROUP entering state IDLE Dec 15 17:09:16 192.168.19.225 hostapd: WPA: e8:50:8b:xx:xx:xx WPA_PTK entering state DISCONNECTED Dec 15 17:09:16 192.168.19.225 hostapd: WPA: e8:50:8b:xx:xx:xx WPA_PTK entering state INITIALIZE Dec 15 17:09:16 192.168.19.225 hostapd: addr=e8:50:8b:xx:xx:xx Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: Set STA flags - ifname=wlan1-2 addr=e8:50:8b:xx:xx:xx total_flags=0x6 flags_or=0x0 flags_and=0xfffffffe authorized=0 Dec 15 17:09:16 192.168.19.225 hostapd: wlan1: Event EAPOL_TX_STATUS (38) received Dec 15 17:09:16 192.168.19.225 hostapd: Ignore TX status for Data frame to STA e8:50:8b:xx:xx:xx that is not currently associated Dec 15 17:09:16 192.168.19.225 hostapd: STA e8:50:8b:xx:xx:xx acknowledged deauth Dec 15 17:09:16 192.168.19.225 hostapd: Removing STA e8:50:8b:xx:xx:xx from kernel driver Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: sta_remove -> DEL_STATION wlan1-2 e8:50:8b:xx:xx:xx --> 0 (Success) Dec 15 17:09:16 192.168.19.225 hostapd: addr=e8:50:8b:xx:xx:xx Dec 15 17:09:16 192.168.19.225 hostapd: wlan1: Event EAPOL_TX_STATUS (38) received Dec 15 17:09:16 192.168.19.225 hostapd: Ignore TX status for Data frame to STA e8:50:8b:xx:xx:xx that is not currently associated Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: Delete station e8:50:8b:xx:xx:xx Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: RX frame sa=e8:50:8b:xx:xx:xx freq=2412 ssi_signal=-48 fc=0x40 seq_ctrl=0x83f0 stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=142 Dec 15 17:09:16 192.168.19.225 hostapd: wlan1: Event EAPOL_TX_STATUS (38) received Dec 15 17:09:16 192.168.19.225 hostapd: Ignore TX status for Data frame to STA e8:50:8b:xx:xx:xx that is not currently associated Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: RX frame sa=e8:50:8b:xx:xx:xx freq=2412 ssi_signal=-48 fc=0x40 seq_ctrl=0x83f0 stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=142 Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: send_mlme - da= e8:50:8b:xx:xx:xx noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3 Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: RX frame sa=e8:50:8b:xx:xx:xx freq=5180 ssi_signal=-44 fc=0x40 seq_ctrl=0x8410 stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=133 Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: RX frame sa=e8:50:8b:xx:xx:xx freq=5180 ssi_signal=-44 fc=0x40 seq_ctrl=0x8410 stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=133 Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: RX frame sa=e8:50:8b:xx:xx:xx freq=5180 ssi_signal=-44 fc=0x40 seq_ctrl=0x8410 stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=133 Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: send_mlme - da= e8:50:8b:xx:xx:xx noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3 Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: RX frame sa=e8:50:8b:xx:xx:xx freq=2412 ssi_signal=-47 fc=0x40 seq_ctrl=0x8400 stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=142 Dec 15 17:09:16 192.168.19.225 hostapd: wlan1: Event EAPOL_TX_STATUS (38) received Dec 15 17:09:16 192.168.19.225 hostapd: Ignore TX status for Data frame to STA e8:50:8b:xx:xx:xx that is not currently associated Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: RX frame sa=e8:50:8b:xx:xx:xx freq=2412 ssi_signal=-47 fc=0x40 seq_ctrl=0x8400 stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=142 Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: RX frame sa=e8:50:8b:xx:xx:xx freq=2412 ssi_signal=-47 fc=0x40 seq_ctrl=0x8400 stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=142 Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: send_mlme - da= e8:50:8b:xx:xx:xx noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3 Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: RX frame sa=e8:50:8b:xx:xx:xx freq=5180 ssi_signal=-44 fc=0xb0 seq_ctrl=0x8430 stype=11 (WLAN_FC_STYPE_AUTH) len=41 Dec 15 17:09:16 192.168.19.225 hostapd: authentication: STA=e8:50:8b:xx:xx:xx auth_alg=0 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x8430 Dec 15 17:09:16 192.168.19.225 hostapd: ap_sta_add: register ap_handle_timer timeout for e8:50:8b:xx:xx:xx (300 seconds - ap_max_inactivity) Dec 15 17:09:16 192.168.19.225 hostapd: authentication reply: STA=e8:50:8b:xx:xx:xx auth_alg=0 auth_transaction=2 resp=0 (IE len=0) Dec 15 17:09:16 192.168.19.225 hostapd: nl80211: send_mlme - da= e8:50:8b:xx:xx:xx noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=3 Dec 15 17:09:16 192.168.19.225 hostapd: wlan0-2: STA e8:50:8b:xx:xx:xx IEEE 802.11: authenticated Günther > -----Original Message----- > From: Hostap [mailto:hostap-bounces@lists.infradead.org] On Behalf Of > Günther Kelleter > Sent: Monday, December 19, 2016 5:06 PM > To: hostap@lists.infradead.org > Subject: [RFC PATCH] Increase GTK/PTK rekey retries > > 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. > > Signed-off-by: Günther Kelleter <guenther.kelleter@devolo.de> > --- > src/ap/wpa_auth.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > There seems to be a common problem with Android devices getting > deauthenticated > frequently due to GTK rekey timeouts > (https://code.google.com/p/android/issues/detail?id=196035#c56) > This patch fixes it by increasing the total timeout period. > > 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." > > But 802.11 doesn't give any hints about the number of retries in > dot11RSNAConfigGroupUpdateCount. > > 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. > > 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 Android bug would still require dot11RSNAConfigGroupUpdateCount to > be at > least 6 for successful GTK rekeying. > > Obviously the same applies to PTK rekeying, where 802.11 mandates the > same > interval specification. > > Is there a reason that hostapd does not implement retransmit timeouts as > mandated by 802.11? > > > diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c > index 43e3558..ba1b58d 100644 > --- a/src/ap/wpa_auth.c > +++ b/src/ap/wpa_auth.c > @@ -60,8 +60,8 @@ static void wpa_group_put(struct wpa_authenticator > *wpa_auth, > struct wpa_group *group); > static u8 * ieee80211w_kde_add(struct wpa_state_machine *sm, u8 *pos); > > -static const u32 dot11RSNAConfigGroupUpdateCount = 4; > -static const u32 dot11RSNAConfigPairwiseUpdateCount = 4; > +static const u32 dot11RSNAConfigGroupUpdateCount = 8; > +static const u32 dot11RSNAConfigPairwiseUpdateCount = 8; > static const u32 eapol_key_timeout_first = 100; /* ms */ > static const u32 eapol_key_timeout_subseq = 1000; /* ms */ > static const u32 eapol_key_timeout_first_group = 500; /* ms */ > -- > 2.10.0.100.gddd73ec > > > _______________________________________________ > Hostap mailing list > Hostap@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/hostap
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.
Hi Jouni Thank you for the valuable comments > -----Original Message----- > From: Jouni Malinen [mailto:j@w1.fi] > Sent: Thursday, December 22, 2016 1:59 PM > To: Guenther Kelleter <Guenther.Kelleter@devolo.de> > Cc: hostap@lists.infradead.org > 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
diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c index 43e3558..ba1b58d 100644 --- a/src/ap/wpa_auth.c +++ b/src/ap/wpa_auth.c @@ -60,8 +60,8 @@ static void wpa_group_put(struct wpa_authenticator *wpa_auth, struct wpa_group *group); static u8 * ieee80211w_kde_add(struct wpa_state_machine *sm, u8 *pos); -static const u32 dot11RSNAConfigGroupUpdateCount = 4; -static const u32 dot11RSNAConfigPairwiseUpdateCount = 4; +static const u32 dot11RSNAConfigGroupUpdateCount = 8; +static const u32 dot11RSNAConfigPairwiseUpdateCount = 8; static const u32 eapol_key_timeout_first = 100; /* ms */ static const u32 eapol_key_timeout_subseq = 1000; /* ms */ static const u32 eapol_key_timeout_first_group = 500; /* ms */
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. Signed-off-by: Günther Kelleter <guenther.kelleter@devolo.de> --- src/ap/wpa_auth.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) There seems to be a common problem with Android devices getting deauthenticated frequently due to GTK rekey timeouts (https://code.google.com/p/android/issues/detail?id=196035#c56) This patch fixes it by increasing the total timeout period. 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." But 802.11 doesn't give any hints about the number of retries in dot11RSNAConfigGroupUpdateCount. 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. 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 Android bug would still require dot11RSNAConfigGroupUpdateCount to be at least 6 for successful GTK rekeying. Obviously the same applies to PTK rekeying, where 802.11 mandates the same interval specification. Is there a reason that hostapd does not implement retransmit timeouts as mandated by 802.11?