From patchwork Mon Dec 19 16:06:11 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?G=C3=BCnther_Kelleter?= X-Patchwork-Id: 707137 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3tj5VS5MLWz9t1d for ; Tue, 20 Dec 2016 03:10:24 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1cJ0Vq-0004qc-EP; Mon, 19 Dec 2016 16:10:06 +0000 Received: from mout3.freenet.de ([2001:748:100:40::2:5]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1cJ0Vl-0004YV-N2 for hostap@lists.infradead.org; Mon, 19 Dec 2016 16:10:03 +0000 Received: from [195.4.92.141] (helo=mjail1.freenet.de) by mout3.freenet.de with esmtpa (ID gnther.kelleter@freenet.de) (port 25) (Exim 4.85 #1) id 1cJ0VG-00053h-2p for hostap@lists.infradead.org; Mon, 19 Dec 2016 17:09:30 +0100 Received: from localhost ([::1]:38746 helo=mjail1.freenet.de) by mjail1.freenet.de with esmtpa (ID gnther.kelleter@freenet.de) (Exim 4.85 #1) id 1cJ0VF-0000bs-4T for hostap@lists.infradead.org; Mon, 19 Dec 2016 17:09:29 +0100 Received: from mx13.freenet.de ([195.4.92.23]:41659) by mjail1.freenet.de with esmtpa (ID gnther.kelleter@freenet.de) (Exim 4.85 #1) id 1cJ0SC-0001m8-6S for hostap@lists.infradead.org; Mon, 19 Dec 2016 17:06:20 +0100 Received: from gate.devolo.com ([5.145.130.200]:57488 helo=gkelleter.devolo.com) by mx13.freenet.de with esmtpsa (ID gnther.kelleter@freenet.de) (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (port 25) (Exim 4.85 #1) id 1cJ0SB-0005b1-Ta for hostap@lists.infradead.org; Mon, 19 Dec 2016 17:06:20 +0100 Received: by gkelleter.devolo.com (Postfix, from userid 1000) id 4556F63B98; Mon, 19 Dec 2016 17:06:18 +0100 (CET) From: =?UTF-8?q?G=C3=BCnther=20Kelleter?= To: hostap@lists.infradead.org Subject: [RFC PATCH] Increase GTK/PTK rekey retries Date: Mon, 19 Dec 2016 17:06:11 +0100 Message-Id: <20161219160611.12862-1-guenther.kelleter@devolo.de> X-Mailer: git-send-email 2.10.0.100.gddd73ec MIME-Version: 1.0 X-Originated-At: 5.145.130.200!57488 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20161219_081001_956121_468C064D X-CRM114-Status: GOOD ( 10.50 ) X-Spam-Score: -2.6 (--) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-2.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [2001:748:100:40:0:0:2:5 listed in] [list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: hostap@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Hostap" Errors-To: hostap-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org 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 --- 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 */