releases/3.19.2/mac80211-send-eapol-frames-at-lowest-rate.patch

   1 From 9c1c98a3bb7b7593b60264b9a07e001e68b46697 Mon Sep 17 00:00:00 2001
   2 From: Jouni Malinen <jouni@qca.qualcomm.com>
   3 Date: Thu, 26 Feb 2015 15:50:50 +0200
   4 Subject: mac80211: Send EAPOL frames at lowest rate
   5
   6 From: Jouni Malinen <jouni@qca.qualcomm.com>
   7
   8 commit 9c1c98a3bb7b7593b60264b9a07e001e68b46697 upstream.
   9
  10 The current minstrel_ht rate control behavior is somewhat optimistic in
  11 trying to find optimum TX rate. While this is usually fine for normal
  12 Data frames, there are cases where a more conservative set of retry
  13 parameters would be beneficial to make the connection more robust.
  14
  15 EAPOL frames are critical to the authentication and especially the
  16 EAPOL-Key message 4/4 (the last message in the 4-way handshake) is
  17 important to get through to the AP. If that message is lost, the only
  18 recovery mechanism in many cases is to reassociate with the AP and start
  19 from scratch. This can often be avoided by trying to send the frame with
  20 more conservative rate and/or with more link layer retries.
  21
  22 In most cases, minstrel_ht is currently using the initial EAPOL-Key
  23 frames for probing higher rates and this results in only five link layer
  24 transmission attempts (one at high(ish) MCS and four at MCS0). While
  25 this works with most APs, it looks like there are some deployed APs that
  26 may have issues with the EAPOL frames using HT MCS immediately after
  27 association. Similarly, there may be issues in cases where the signal
  28 strength or radio environment is not good enough to be able to get
  29 frames through even at couple of MCS 0 tries.
  30
  31 The best approach for this would likely to be to reduce the TX rate for
  32 the last rate (3rd rate parameter in the set) to a low basic rate (say,
  33 6 Mbps on 5 GHz and 2 or 5.5 Mbps on 2.4 GHz), but doing that cleanly
  34 requires some more effort. For now, we can start with a simple one-liner
  35 that forces the minimum rate to be used for EAPOL frames similarly how
  36 the TX rate is selected for the IEEE 802.11 Management frames. This does
  37 result in a small extra latency added to the cases where the AP would be
  38 able to receive the higher rate, but taken into account how small number
  39 of EAPOL frames are used, this is likely to be insignificant. A future
  40 optimization in the minstrel_ht design can also allow this patch to be
  41 reverted to get back to the more optimized initial TX rate.
  42
  43 It should also be noted that many drivers that do not use minstrel as
  44 the rate control algorithm are already doing similar workarounds by
  45 forcing the lowest TX rate to be used for EAPOL frames.
  46
  47 Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
  48 Tested-by: Linus Torvalds <torvalds@linux-foundation.org>
  49 Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
  50 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
  51 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  52
  53 ---
  54  net/mac80211/tx.c |    1 +
  55  1 file changed, 1 insertion(+)
  56
  57 --- a/net/mac80211/tx.c
  58 +++ b/net/mac80211/tx.c
  59 @@ -566,6 +566,7 @@ ieee80211_tx_h_check_control_port_protoc
  60                 if (tx->sdata->control_port_no_encrypt)
  61                         info->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT;
  62                 info->control.flags |= IEEE80211_TX_CTRL_PORT_CTRL_PROTO;
  63 +               info->flags |= IEEE80211_TX_CTL_USE_MINRATE;
  64         }
  65
  66         return TX_CONTINUE;