Re: [PATCH] mac80211: Tear down BA session on BAR tx failure

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2011-08-11 at 11:08 +0200, Helmut Schaa wrote:
> 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

typo

>  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.

typo


> 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.

Seems ok to me, hopefully won't happen often :)

> +		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);
> +		}

Hmm, that shift & mask makes me think twice, are there constants, and
maybe there should be some parentheses?

johannes