The assumption is that during the hw config, transmission was
already stopped by mac80211. Sometimes the AP can be switching
b/w the ht modes due to intolerant or etc where STA is in
the middle of transmission. In such scenario, buffer overflow
was observed at driver side. And also before updating the rate
control, the frames are continued to xmited with older rates.
This patch ensures that the frames are always xmitted with
updated rates and avoid buffer overflow.
Signed-off-by: Rajkumar Manoharan <[email protected]>
---
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/mlme.c | 16 ++++++++++++++++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c204cee..8db9f9a 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -670,6 +670,7 @@ enum queue_stop_reason {
IEEE80211_QUEUE_STOP_REASON_AGGREGATION,
IEEE80211_QUEUE_STOP_REASON_SUSPEND,
IEEE80211_QUEUE_STOP_REASON_SKB_ADD,
+ IEEE80211_QUEUE_STOP_REASON_CHTYPE_CHANGE,
};
#ifdef CONFIG_MAC80211_LEDS
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 60a6f27..edd2518 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1922,8 +1922,24 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
rcu_read_unlock();
+ /*
+ * Whenever the AP announces the HT mode change that can be
+ * 40MHz intolerant or etc., it would be safer to stop tx
+ * queues before doing hw config to avoid buffer overflow.
+ */
+ ieee80211_stop_queues_by_reason(&sdata->local->hw,
+ IEEE80211_QUEUE_STOP_REASON_CHTYPE_CHANGE);
+
+ /* flush out all packets */
+ synchronize_net();
+
+ drv_flush(local, false);
+
changed |= ieee80211_enable_ht(sdata, elems.ht_info_elem,
bssid, ap_ht_cap_flags);
+
+ ieee80211_wake_queues_by_reason(&sdata->local->hw,
+ IEEE80211_QUEUE_STOP_REASON_CHTYPE_CHANGE);
}
/* Note: country IE parsing is done for us by cfg80211 */
--
1.7.6.1
On 2011-09-02 10:21 AM, Rajkumar Manoharan wrote:
> The assumption is that during the hw config, transmission was
> already stopped by mac80211. Sometimes the AP can be switching
> b/w the ht modes due to intolerant or etc where STA is in
> the middle of transmission. In such scenario, buffer overflow
> was observed at driver side. And also before updating the rate
> control, the frames are continued to xmited with older rates.
> This patch ensures that the frames are always xmitted with
> updated rates and avoid buffer overflow.
>
> Signed-off-by: Rajkumar Manoharan<[email protected]>
John, please revert this one, it's completely messed up. It stops
queues, and calls drv_flush whenever it receives a beacon with 802.11n
information, even if 802.11n is already enabled and the mode is the
correct one.
Additionally, it even wakes the queues again before the settings have
been applied, so it's 100% useless.
- Felix
On Fri, 2011-09-02 at 13:51 +0530, Rajkumar Manoharan wrote:
> The assumption is that during the hw config, transmission was
> already stopped by mac80211. Sometimes the AP can be switching
> b/w the ht modes due to intolerant or etc where STA is in
> the middle of transmission. In such scenario, buffer overflow
> was observed at driver side. And also before updating the rate
> control, the frames are continued to xmited with older rates.
> This patch ensures that the frames are always xmitted with
> updated rates and avoid buffer overflow.
>
> Signed-off-by: Rajkumar Manoharan <[email protected]>
Reviewed-by: Johannes Berg <[email protected]>
Thanks for your patience!
johannes
On Fri, Sep 16, 2011 at 09:56:55AM +0200, Felix Fietkau wrote:
> On 2011-09-02 10:21 AM, Rajkumar Manoharan wrote:
> >The assumption is that during the hw config, transmission was
> >already stopped by mac80211. Sometimes the AP can be switching
> >b/w the ht modes due to intolerant or etc where STA is in
> >the middle of transmission. In such scenario, buffer overflow
> >was observed at driver side. And also before updating the rate
> >control, the frames are continued to xmited with older rates.
> >This patch ensures that the frames are always xmitted with
> >updated rates and avoid buffer overflow.
> >
> >Signed-off-by: Rajkumar Manoharan<[email protected]>
> John, please revert this one, it's completely messed up. It stops
> queues, and calls drv_flush whenever it receives a beacon with
> 802.11n information, even if 802.11n is already enabled and the mode
> is the correct one.
> Additionally, it even wakes the queues again before the settings
> have been applied, so it's 100% useless.
As we discussed in irc, drv_flush & queue stop shouldn't be called
so frequently. It is a bug. But this patch prevents the transmission
while doing hw config because of 20/40 switch from beacon ie. So
this patch is really needed and also there is not point in covering
bss_info_change state. To avoid the accidential queue wakeup by
flush, this patch defines new reason code. I will send the followup
patch ASAP.
--
Rajkumar