rt2x00: do not increment sequence number while re-transmitting [Linux 3.16.72]

This Linux kernel change "rt2x00: do not increment sequence number while re-transmitting" is included in the Linux 3.16.72 release. This change is authored by Vijayakumar Durai <vijayakumar.durai1 [at] vivint.com> on Wed Mar 27 11:03:17 2019 +0100. The commit for this change in Linux stable tree is 8fe41e8 (patch) which is from upstream commit 746ba11. The same Linux upstream change may have been applied to various maintained Linux releases and you can find all Linux releases containing changes from upstream 746ba11.

rt2x00: do not increment sequence number while re-transmitting

commit 746ba11f170603bf1eaade817553a6c2e9135bbe upstream.

Currently rt2x00 devices retransmit the management frames with
incremented sequence number if hardware is assigning the sequence.

This is HW bug fixed already for non-QOS data frames, but it should
be fixed for management frames except beacon.

Without fix retransmitted frames have wrong SN:

 AlphaNet_e8:fb:36 Vivotek_52:31:51 Authentication, SN=1648, FN=0, Flags=........C Frame is not being retransmitted 1648 1
 AlphaNet_e8:fb:36 Vivotek_52:31:51 Authentication, SN=1649, FN=0, Flags=....R...C Frame is being retransmitted 1649 1
 AlphaNet_e8:fb:36 Vivotek_52:31:51 Authentication, SN=1650, FN=0, Flags=....R...C Frame is being retransmitted 1650 1

With the fix SN stays correctly the same:

 88:6a:e3:e8:f9:a2 8c:f5:a3:88:76:87 Authentication, SN=1450, FN=0, Flags=........C
 88:6a:e3:e8:f9:a2 8c:f5:a3:88:76:87 Authentication, SN=1450, FN=0, Flags=....R...C
 88:6a:e3:e8:f9:a2 8c:f5:a3:88:76:87 Authentication, SN=1450, FN=0, Flags=....R...C

Signed-off-by: Vijayakumar Durai <vijayakumar.durai1@vivint.com>
[sgruszka: simplify code, change comments and changelog]
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
[bwh: Backported to 3.16: adjust filenames, context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

There are 26 lines of Linux source code added/deleted in this change. Code changes to Linux kernel are as follows.

 drivers/net/wireless/rt2x00/rt2x00.h      |  1 -
 drivers/net/wireless/rt2x00/rt2x00mac.c   | 10 ----------
 drivers/net/wireless/rt2x00/rt2x00queue.c | 15 +++++++++------
 3 files changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/rt2x00.h b/drivers/net/wireless/rt2x00/rt2x00.h
index d13f25c..91aebb0 100644
--- a/drivers/net/wireless/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/rt2x00/rt2x00.h
@@ -666,7 +666,6 @@ enum rt2x00_state_flags {
    CONFIG_CHANNEL_HT40,
    CONFIG_POWERSAVING,
    CONFIG_HT_DISABLED,
-   CONFIG_QOS_DISABLED,

    /*
     * Mark we currently are sequentially reading TX_STA_FIFO register
diff --git a/drivers/net/wireless/rt2x00/rt2x00mac.c b/drivers/net/wireless/rt2x00/rt2x00mac.c
index 004dff9..e7c152d 100644
--- a/drivers/net/wireless/rt2x00/rt2x00mac.c
+++ b/drivers/net/wireless/rt2x00/rt2x00mac.c
@@ -682,19 +682,9 @@ void rt2x00mac_bss_info_changed(struct ieee80211_hw *hw,
            rt2x00dev->intf_associated--;

        rt2x00leds_led_assoc(rt2x00dev, !!rt2x00dev->intf_associated);
-
-       clear_bit(CONFIG_QOS_DISABLED, &rt2x00dev->flags);
    }

    /*
-    * Check for access point which do not support 802.11e . We have to
-    * generate data frames sequence number in S/W for such AP, because
-    * of H/W bug.
-    */
-   if (changes & BSS_CHANGED_QOS && !bss_conf->qos)
-       set_bit(CONFIG_QOS_DISABLED, &rt2x00dev->flags);
-
-   /*
     * When the erp information has changed, we should perform
     * additional configuration steps. For all other changes we are done.
     */
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c b/drivers/net/wireless/rt2x00/rt2x00queue.c
index 22d49d5..8705092 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
@@ -201,15 +201,18 @@ static void rt2x00queue_create_tx_descriptor_seq(struct rt2x00_dev *rt2x00dev,
    if (!test_bit(REQUIRE_SW_SEQNO, &rt2x00dev->cap_flags)) {
        /*
         * rt2800 has a H/W (or F/W) bug, device incorrectly increase
-        * seqno on retransmited data (non-QOS) frames. To workaround
-        * the problem let's generate seqno in software if QOS is
-        * disabled.
+        * seqno on retransmitted data (non-QOS) and management frames.
+        * To workaround the problem let's generate seqno in software.
+        * Except for beacons which are transmitted periodically by H/W
+        * hence hardware has to assign seqno for them.
         */
-       if (test_bit(CONFIG_QOS_DISABLED, &rt2x00dev->flags))
-           __clear_bit(ENTRY_TXD_GENERATE_SEQ, &txdesc->flags);
-       else
+           if (ieee80211_is_beacon(hdr->frame_control)) {
+           __set_bit(ENTRY_TXD_GENERATE_SEQ, &txdesc->flags);
            /* H/W will generate sequence number */
            return;
+       }
+
+       __clear_bit(ENTRY_TXD_GENERATE_SEQ, &txdesc->flags);
    }

    /*

Leave a Reply

Your email address will not be published. Required fields are marked *