Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 03 3月, 2015 1 次提交
  3. 27 2月, 2015 1 次提交
    • J
      mac80211: Send EAPOL frames at lowest rate · 9c1c98a3
      由 Jouni Malinen 提交于 
      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.

Cc: stable@vger.kernel.org
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9c1c98a3
  5. 25 2月, 2015 1 次提交
    • J
      mac80211/minstrel: fix !x!=0 confusion · 17dce158
      由 Jiri Slaby 提交于 
      Commit 06d961a8 ("mac80211/minstrel: use the new rate control API")
inverted the condition 'if (msr->sample_limit != 0)' to
'if (!msr->sample_limit != 0)'. But it is confusing both to people and
compilers (gcc5):
net/mac80211/rc80211_minstrel.c: In function 'minstrel_get_rate':
net/mac80211/rc80211_minstrel.c:376:26: warning: logical not is only applied to the left hand side of comparison
   if (!msr->sample_limit != 0)
                          ^

Let there be only 'if (!msr->sample_limit)'.

Fixes: 06d961a8 ("mac80211/minstrel: use the new rate control API")
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      17dce158
  7. 24 2月, 2015 6 次提交
  9. 23 2月, 2015 6 次提交
  11. 22 2月, 2015 3 次提交
  13. 21 2月, 2015 20 次提交
  15. 20 2月, 2015 2 次提交