diff options
2 files changed, 109 insertions, 0 deletions
diff --git a/package/kernel/mac80211/patches/rt2x00/011-rt2x00-clear-up-IV-s-on-key-removal.patch b/package/kernel/mac80211/patches/rt2x00/011-rt2x00-clear-up-IV-s-on-key-removal.patch new file mode 100644 index 0000000000..06430b0ec9 --- /dev/null +++ b/package/kernel/mac80211/patches/rt2x00/011-rt2x00-clear-up-IV-s-on-key-removal.patch @@ -0,0 +1,57 @@ +From patchwork Fri Aug 23 12:48:03 2019 +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +X-Patchwork-Submitter: Stanislaw Gruszka <sgruszka@redhat.com> +X-Patchwork-Id: 11111605 +X-Patchwork-Delegate: kvalo@adurom.com +From: Stanislaw Gruszka <sgruszka@redhat.com> +To: linux-wireless@vger.kernel.org +Subject: [PATCH 5.3] rt2x00: clear up IV's on key removal +Date: Fri, 23 Aug 2019 14:48:03 +0200 +Message-Id: <1566564483-31088-1-git-send-email-sgruszka@redhat.com> +Sender: linux-wireless-owner@vger.kernel.org +List-ID: <linux-wireless.vger.kernel.org> +X-Mailing-List: linux-wireless@vger.kernel.org + +After looking at code I realized that my previous fix +95844124385e ("rt2x00: clear IV's on start to fix AP mode regression") +was incomplete. We can still have wrong IV's after re-keyring. +To fix that, clear up IV's also on key removal. + +Fixes: 710e6cc1595e ("rt2800: do not nullify initialization vector data") +Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> +--- + drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 19 ++++++++++++------- + 1 file changed, 12 insertions(+), 7 deletions(-) + +diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c +index ecbe78b8027b..28e2de04834e 100644 +--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c ++++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c +@@ -1654,13 +1654,18 @@ static void rt2800_config_wcid_attr_cipher(struct rt2x00_dev *rt2x00dev, + + offset = MAC_IVEIV_ENTRY(key->hw_key_idx); + +- rt2800_register_multiread(rt2x00dev, offset, +- &iveiv_entry, sizeof(iveiv_entry)); +- if ((crypto->cipher == CIPHER_TKIP) || +- (crypto->cipher == CIPHER_TKIP_NO_MIC) || +- (crypto->cipher == CIPHER_AES)) +- iveiv_entry.iv[3] |= 0x20; +- iveiv_entry.iv[3] |= key->keyidx << 6; ++ if (crypto->cmd == SET_KEY) { ++ rt2800_register_multiread(rt2x00dev, offset, ++ &iveiv_entry, sizeof(iveiv_entry)); ++ if ((crypto->cipher == CIPHER_TKIP) || ++ (crypto->cipher == CIPHER_TKIP_NO_MIC) || ++ (crypto->cipher == CIPHER_AES)) ++ iveiv_entry.iv[3] |= 0x20; ++ iveiv_entry.iv[3] |= key->keyidx << 6; ++ } else { ++ memset(&iveiv_entry, 0, sizeof(iveiv_entry)); ++ } ++ + rt2800_register_multiwrite(rt2x00dev, offset, + &iveiv_entry, sizeof(iveiv_entry)); + } diff --git a/package/kernel/mac80211/patches/rt2x00/015-rt2x00-do-not-set-IEEE80211_TX_STAT_AMPDU_NO_BACK-on-tx-status.patch b/package/kernel/mac80211/patches/rt2x00/015-rt2x00-do-not-set-IEEE80211_TX_STAT_AMPDU_NO_BACK-on-tx-status.patch new file mode 100644 index 0000000000..9ac115fd97 --- /dev/null +++ b/package/kernel/mac80211/patches/rt2x00/015-rt2x00-do-not-set-IEEE80211_TX_STAT_AMPDU_NO_BACK-on-tx-status.patch @@ -0,0 +1,52 @@ +From patchwork Fri Aug 23 07:09:56 2019 +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +X-Patchwork-Submitter: Stanislaw Gruszka <sgruszka@redhat.com> +X-Patchwork-Id: 11110703 +X-Patchwork-Delegate: kvalo@adurom.com +From: Stanislaw Gruszka <sgruszka@redhat.com> +To: linux-wireless@vger.kernel.org +Subject: [PATCH] rt2x00: do not set IEEE80211_TX_STAT_AMPDU_NO_BACK on tx + status +Date: Fri, 23 Aug 2019 09:09:56 +0200 +Message-Id: <1566544196-20371-1-git-send-email-sgruszka@redhat.com> +Sender: linux-wireless-owner@vger.kernel.org +List-ID: <linux-wireless.vger.kernel.org> +X-Mailing-List: linux-wireless@vger.kernel.org + +According to documentation IEEE80211_TX_STAT_AMPDU_NO_BACK is suppose +to be used when we do not recive BA (BlockAck). However on rt2x00 we +use it when remote station fail to decode one or more subframes within +AMPDU (some bits are not set in BlockAck bitmap). Setting the flag result +in sent of BAR (BlockAck Request) frame and this might result of abuse +of BA session, since remote station can sent BA with incorrect +sequence numbers after receiving BAR. This problem is visible especially +when connecting two rt2800 devices. + +Previously I observed some performance benefits when using the flag +when connecting with iwlwifi devices. But currently possibly due +to reacent changes in rt2x00 removing the flag has no effect on +those test cases. + +So remove the IEEE80211_TX_STAT_AMPDU_NO_BACK. + +Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> +--- + drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 3 --- + 1 file changed, 3 deletions(-) + +diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c +index 9d158237ac67..c3eab767bc21 100644 +--- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c ++++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c +@@ -371,9 +371,6 @@ static void rt2x00lib_fill_tx_status(struct rt2x00_dev *rt2x00dev, + IEEE80211_TX_CTL_AMPDU; + tx_info->status.ampdu_len = 1; + tx_info->status.ampdu_ack_len = success ? 1 : 0; +- +- if (!success) +- tx_info->flags |= IEEE80211_TX_STAT_AMPDU_NO_BACK; + } + + if (rate_flags & IEEE80211_TX_RC_USE_RTS_CTS) { |