]>
Commit | Line | Data |
---|---|---|
85647c5c GKH |
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 | |
5 | ||
6 | From: Vijayakumar Durai <vijayakumar.durai1@vivint.com> | |
7 | ||
8 | commit 746ba11f170603bf1eaade817553a6c2e9135bbe upstream. | |
9 | ||
10 | Currently rt2x00 devices retransmit the management frames with | |
11 | incremented sequence number if hardware is assigning the sequence. | |
12 | ||
13 | This is HW bug fixed already for non-QOS data frames, but it should | |
14 | be fixed for management frames except beacon. | |
15 | ||
16 | Without fix retransmitted frames have wrong SN: | |
17 | ||
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 | |
21 | ||
22 | With the fix SN stays correctly the same: | |
23 | ||
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 | |
27 | ||
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> | |
34 | ||
35 | --- | |
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(-) | |
40 | ||
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 { | |
44 | CONFIG_CHANNEL_HT40, | |
45 | CONFIG_POWERSAVING, | |
46 | CONFIG_HT_DISABLED, | |
47 | - CONFIG_QOS_DISABLED, | |
48 | CONFIG_MONITORING, | |
49 | ||
50 | /* | |
51 | --- a/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | |
52 | +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | |
53 | @@ -642,19 +642,9 @@ void rt2x00mac_bss_info_changed(struct i | |
54 | rt2x00dev->intf_associated--; | |
55 | ||
56 | rt2x00leds_led_assoc(rt2x00dev, !!rt2x00dev->intf_associated); | |
57 | - | |
58 | - clear_bit(CONFIG_QOS_DISABLED, &rt2x00dev->flags); | |
59 | } | |
60 | ||
61 | /* | |
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 | |
64 | - * of H/W bug. | |
65 | - */ | |
66 | - if (changes & BSS_CHANGED_QOS && !bss_conf->qos) | |
67 | - set_bit(CONFIG_QOS_DISABLED, &rt2x00dev->flags); | |
68 | - | |
69 | - /* | |
70 | * When the erp information has changed, we should perform | |
71 | * additional configuration steps. For all other changes we are done. | |
72 | */ | |
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)) { | |
77 | /* | |
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 | |
81 | - * disabled. | |
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. | |
86 | */ | |
87 | - if (test_bit(CONFIG_QOS_DISABLED, &rt2x00dev->flags)) | |
88 | - __clear_bit(ENTRY_TXD_GENERATE_SEQ, &txdesc->flags); | |
89 | - else | |
90 | + if (ieee80211_is_beacon(hdr->frame_control)) { | |
91 | + __set_bit(ENTRY_TXD_GENERATE_SEQ, &txdesc->flags); | |
92 | /* H/W will generate sequence number */ | |
93 | return; | |
94 | + } | |
95 | + | |
96 | + __clear_bit(ENTRY_TXD_GENERATE_SEQ, &txdesc->flags); | |
97 | } | |
98 | ||
99 | /* |