Linux wireless drivers development
 help / color / mirror / Atom feed
From: Helmut Schaa <helmut.schaa@googlemail.com>
To: John Linville <linville@tuxdriver.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless@vger.kernel.org,
	Helmut Schaa <helmut.schaa@googlemail.com>
Subject: [PATCH] mac80211: Tear down BA session on BAR tx failure
Date: Thu, 11 Aug 2011 11:08:17 +0200	[thread overview]
Message-ID: <1313053697-19544-1-git-send-email-helmut.schaa@googlemail.com> (raw)

As described at [1] some STAs (i.e. Intel 5100 on Windows) can end up
correctly BlockAcking incoming frames without delivering them to user
space if a AMPDU subframe got lost and its reorder buffer isn't flushed
by a BlockAckReq. This in turn results in up to 64 frames being stuck
in the reorder buffer.

Accroding to 802.11n-2009 it is not necessary to send a BAR to flush
the receipients RX reorder buffer but we still do that to be polite.

However, assume the following frame exchange:

AP -> STA, AMPDU (failed)
AP -> STA, BAR (failed)

The client in question then ends up in the same situation and won't
deliver frames to userspace anymore since we weren't able to flush
its reorder buffer.

This is not a hypothetical situation but I was able to observe this
exact behavior during a stress test between a rt2800pci AP and a Intel
5100 Windows client.

In order to work around this issue just tear down the BA session as
soon as a BAR failed to be TX'ed.

[1] http://comments.gmane.org/gmane.linux.kernel.wireless.general/66867

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---

IMHO the Windows driver is just buggy and should be fixed to use a
reasonable timeout for flushing its reorder buffer but the described
behavior doesn't appear with the Ralink Legacy drivers for example since
they trigger a tear down of the BA session in several other situations
as well (a single failed AMPDU :) for example) and thus don't end up in
this situation.

Johannes, feel free to NACK this patch as it really is just a
workaround for buggy clients but I'd say it still makes sense to fall
back to non-aggregated frames in such a situation. Furthermore, this
situation is unlikely to happen very often but as written before I was
able to reproduce it a couple of times.

Thanks,
Helmut
 
 net/mac80211/status.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 1658efa..6c4b728 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -187,6 +187,7 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
 	int rates_idx = -1;
 	bool send_to_cooked;
 	bool acked;
+	struct ieee80211_bar *bar;
 
 	for (i = 0; i < IEEE80211_TX_MAX_RATES; i++) {
 		if (info->status.rates[i].idx < 0) {
@@ -243,6 +244,18 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
 					   tid, ssn);
 		}
 
+		if (!acked && ieee80211_is_back_req(fc)) {
+			/*
+			 * BAR failed, let's tear down the BA session as a
+			 * last resort as some STAs (Intel 5100 on Windows)
+			 * can get stuck when the BA window isn't flushed
+			 * correctly.
+			 */
+			bar = (struct ieee80211_bar *) skb->data;
+			ieee80211_stop_tx_ba_session(&sta->sta,
+						     bar->control >> 12 & 0xf);
+		}
+
 		if (info->flags & IEEE80211_TX_STAT_TX_FILTERED) {
 			ieee80211_handle_filtered_frame(local, sta, skb);
 			rcu_read_unlock();
-- 
1.7.3.4


             reply	other threads:[~2011-08-11  9:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-11  9:08 Helmut Schaa [this message]
2011-08-11 10:05 ` [PATCH] mac80211: Tear down BA session on BAR tx failure Adrian Chadd
2011-08-11 12:58 ` Johannes Berg
2011-08-11 13:25   ` Helmut Schaa
2011-08-11 14:17 ` [PATCH 1/2] wireless: Introduce defines for BAR TID_INFO & MULTI_TID fields Helmut Schaa
2011-08-11 14:17 ` [PATCHv2 2/2] mac80211: Tear down BA session on BAR tx failure Helmut Schaa
2011-09-06 19:39   ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1313053697-19544-1-git-send-email-helmut.schaa@googlemail.com \
    --to=helmut.schaa@googlemail.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox