From patchwork Thu Feb 26 13:50:50 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jouni Malinen X-Patchwork-Id: 5892851 X-Patchwork-Delegate: johannes@sipsolutions.net Return-Path: X-Original-To: patchwork-linux-wireless@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 36294BF6C3 for ; Thu, 26 Feb 2015 13:52:47 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 58D162013D for ; Thu, 26 Feb 2015 13:52:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 42214203A4 for ; Thu, 26 Feb 2015 13:52:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932286AbbBZNwi (ORCPT ); Thu, 26 Feb 2015 08:52:38 -0500 Received: from wolverine02.qualcomm.com ([199.106.114.251]:38864 "EHLO wolverine02.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932523AbbBZNvd (ORCPT ); Thu, 26 Feb 2015 08:51:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qca.qualcomm.com; i=@qca.qualcomm.com; q=dns/txt; s=qcdkim; t=1424958692; x=1456494692; h=from:to:cc:subject:date:message-id:mime-version; bh=UA7g5o/J7nk2rbpIzfKBYHzvvUe0Y8czcUJcBt8pdc0=; b=jPRlwbFlrDYMAAPyMUnJ3ocdn8AfuCfuZdHnvheOIwXm7spkxm9nqIoF GWbIfsLuYxyEPj+QaeFfQImx/xXMU2snob0WtSxRLSYYudIT+Psn2sKTH 5qdTfQ1vzCoJV9nziYHqLC8BdKbVSAAsBIO0pQfpLAGJTZuiH491AJs2A I=; X-IronPort-AV: E=McAfee;i="5600,1067,7723"; a="197320536" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Feb 2015 05:51:32 -0800 X-IronPort-AV: E=Sophos;i="5.09,652,1418112000"; d="scan'208";a="823491030" Received: from nasanexm01e.na.qualcomm.com ([10.85.0.31]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 26 Feb 2015 05:51:32 -0800 Received: from jouni.qca.qualcomm.com (10.80.80.8) by NASANEXM01E.na.qualcomm.com (10.85.0.31) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 26 Feb 2015 05:51:30 -0800 From: Jouni Malinen To: Johannes Berg CC: , Linus Torvalds , Jouni Malinen Subject: [PATCH] mac80211: Send EAPOL frames at lowest rate Date: Thu, 26 Feb 2015 15:50:50 +0200 Message-ID: <1424958650-11165-1-git-send-email-jouni@qca.qualcomm.com> X-Mailer: git-send-email 1.9.1 MIME-Version: 1.0 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To NASANEXM01E.na.qualcomm.com (10.85.0.31) Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The current minstrel_ht rate control behavior is somewhat optimistic in trying to find optimum TX rate. While this is usually fine for normal Data frames, there are cases where a more conservative set of retry parameters would be beneficial to make the connection more robust. EAPOL frames are critical to the authentication and especially the EAPOL-Key message 4/4 (the last message in the 4-way handshake) is important to get through to the AP. If that message is lost, the only recovery mechanism in many cases is to reassociate with the AP and start from scratch. This can often be avoided by trying to send the frame with more conservative rate and/or with more link layer retries. In most cases, minstrel_ht is currently using the initial EAPOL-Key frames for probing higher rates and this results in only five link layer transmission attempts (one at high(ish) MCS and four at MCS0). While this works with most APs, it looks like there are some deployed APs that may have issues with the EAPOL frames using HT MCS immediately after association. Similarly, there may be issues in cases where the signal strength or radio environment is not good enough to be able to get frames through even at couple of MCS 0 tries. The best approach for this would likely to be to reduce the TX rate for the last rate (3rd rate parameter in the set) to a low basic rate (say, 6 Mbps on 5 GHz and 2 or 5.5 Mbps on 2.4 GHz), but doing that cleanly requires some more effort. For now, we can start with a simple one-liner that forces the minimum rate to be used for EAPOL frames similarly how the TX rate is selected for the IEEE 802.11 Management frames. This does result in a small extra latency added to the cases where the AP would be able to receive the higher rate, but taken into account how small number of EAPOL frames are used, this is likely to be insignificant. A future optimization in the minstrel_ht design can also allow this patch to be reverted to get back to the more optimized initial TX rate. It should also be noted that many drivers that do not use minstrel as the rate control algorithm are already doing similar workarounds by forcing the lowest TX rate to be used for EAPOL frames. Reported-by: Linus Torvalds Signed-off-by: Jouni Malinen --- net/mac80211/tx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index af5446c..14ff5e4 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -565,6 +565,7 @@ ieee80211_tx_h_check_control_port_protocol(struct ieee80211_tx_data *tx) if (tx->sdata->control_port_no_encrypt) info->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT; info->control.flags |= IEEE80211_TX_CTRL_PORT_CTRL_PROTO; + info->flags |= IEEE80211_TX_CTL_USE_MINRATE; } return TX_CONTINUE;