| From 9c1c98a3bb7b7593b60264b9a07e001e68b46697 Mon Sep 17 00:00:00 2001 |
| From: Jouni Malinen <jouni@qca.qualcomm.com> |
| Date: Thu, 26 Feb 2015 15:50:50 +0200 |
| Subject: mac80211: Send EAPOL frames at lowest rate |
| |
| From: Jouni Malinen <jouni@qca.qualcomm.com> |
| |
| commit 9c1c98a3bb7b7593b60264b9a07e001e68b46697 upstream. |
| |
| 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 <torvalds@linux-foundation.org> |
| Tested-by: Linus Torvalds <torvalds@linux-foundation.org> |
| Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> |
| Signed-off-by: Johannes Berg <johannes.berg@intel.com> |
| Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| |
| --- |
| net/mac80211/tx.c | 1 + |
| 1 file changed, 1 insertion(+) |
| |
| --- a/net/mac80211/tx.c |
| +++ b/net/mac80211/tx.c |
| @@ -566,6 +566,7 @@ ieee80211_tx_h_check_control_port_protoc |
| 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; |