1 From 746ba11f170603bf1eaade817553a6c2e9135bbe Mon Sep 17 00:00:00 2001
2 From: Vijayakumar Durai <vijayakumar.durai1@vivint.com>
3 Date: Wed, 27 Mar 2019 11:03:17 +0100
4 Subject: rt2x00: do not increment sequence number while re-transmitting
6 From: Vijayakumar Durai <vijayakumar.durai1@vivint.com>
8 commit 746ba11f170603bf1eaade817553a6c2e9135bbe upstream.
10 Currently rt2x00 devices retransmit the management frames with
11 incremented sequence number if hardware is assigning the sequence.
13 This is HW bug fixed already for non-QOS data frames, but it should
14 be fixed for management frames except beacon.
16 Without fix retransmitted frames have wrong SN:
18 AlphaNet_e8:fb:36 Vivotek_52:31:51 Authentication, SN=1648, FN=0, Flags=........C Frame is not being retransmitted 1648 1
19 AlphaNet_e8:fb:36 Vivotek_52:31:51 Authentication, SN=1649, FN=0, Flags=....R...C Frame is being retransmitted 1649 1
20 AlphaNet_e8:fb:36 Vivotek_52:31:51 Authentication, SN=1650, FN=0, Flags=....R...C Frame is being retransmitted 1650 1
22 With the fix SN stays correctly the same:
24 88:6a:e3:e8:f9:a2 8c:f5:a3:88:76:87 Authentication, SN=1450, FN=0, Flags=........C
25 88:6a:e3:e8:f9:a2 8c:f5:a3:88:76:87 Authentication, SN=1450, FN=0, Flags=....R...C
26 88:6a:e3:e8:f9:a2 8c:f5:a3:88:76:87 Authentication, SN=1450, FN=0, Flags=....R...C
28 Cc: stable@vger.kernel.org
29 Signed-off-by: Vijayakumar Durai <vijayakumar.durai1@vivint.com>
30 [sgruszka: simplify code, change comments and changelog]
31 Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
32 Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
33 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
36 drivers/net/wireless/ralink/rt2x00/rt2x00.h | 1 -
37 drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | 10 ----------
38 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 15 +++++++++------
39 3 files changed, 9 insertions(+), 17 deletions(-)
41 --- a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
42 +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
43 @@ -672,7 +672,6 @@ enum rt2x00_state_flags {
47 - CONFIG_QOS_DISABLED,
51 --- a/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c
52 +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c
53 @@ -670,19 +670,9 @@ void rt2x00mac_bss_info_changed(struct i
54 rt2x00dev->intf_associated--;
56 rt2x00leds_led_assoc(rt2x00dev, !!rt2x00dev->intf_associated);
58 - clear_bit(CONFIG_QOS_DISABLED, &rt2x00dev->flags);
62 - * Check for access point which do not support 802.11e . We have to
63 - * generate data frames sequence number in S/W for such AP, because
66 - if (changes & BSS_CHANGED_QOS && !bss_conf->qos)
67 - set_bit(CONFIG_QOS_DISABLED, &rt2x00dev->flags);
70 * When the erp information has changed, we should perform
71 * additional configuration steps. For all other changes we are done.
73 --- a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
74 +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
75 @@ -200,15 +200,18 @@ static void rt2x00queue_create_tx_descri
76 if (!rt2x00_has_cap_flag(rt2x00dev, REQUIRE_SW_SEQNO)) {
78 * rt2800 has a H/W (or F/W) bug, device incorrectly increase
79 - * seqno on retransmited data (non-QOS) frames. To workaround
80 - * the problem let's generate seqno in software if QOS is
82 + * seqno on retransmitted data (non-QOS) and management frames.
83 + * To workaround the problem let's generate seqno in software.
84 + * Except for beacons which are transmitted periodically by H/W
85 + * hence hardware has to assign seqno for them.
87 - if (test_bit(CONFIG_QOS_DISABLED, &rt2x00dev->flags))
88 - __clear_bit(ENTRY_TXD_GENERATE_SEQ, &txdesc->flags);
90 + if (ieee80211_is_beacon(hdr->frame_control)) {
91 + __set_bit(ENTRY_TXD_GENERATE_SEQ, &txdesc->flags);
92 /* H/W will generate sequence number */
96 + __clear_bit(ENTRY_TXD_GENERATE_SEQ, &txdesc->flags);