Ben Hutchings wrote:

On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote:

quoted

On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote:

quoted

quoted

To be clear, I have all of these in the queue:

be03d4a45c09 rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails
5b632fe85ec8 mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL
ab9d6e4ffe19 Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"

and I'm intending to drop/defer them all.

Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches,
or only patch 2.

No, actually all 3 patches have to be applied. Because last one, except
revert, include flag IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL setting in rt2x00
driver, which make patch 2 work.

Andreas said that that after ab9d6e4ffe19 there was still a regression.
But maybe he was confused.  I know I'm confused.

:-))

No, the thing is:
rt2800pci misses an appropriate handling of aggregation (which meets the
requirements of mac80211).

Both workarounds, mine and the new workaround from Stanislaw (which is
nothing more than a restricted version of my initial workaround), work
like this:
Let the peer do the aggregation handling. If it's not done by the peer,
the connection will break down.

Therefore:
The solution would be IMHO, to implement an own aggregation handling,
maybe the same way as it was done for carl9170, which had the same problem:

http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793/focus=1405

I prefer to have solutions (if one is known) instead of another workaround.
If I use my device as STA instead of an AP, it even works fine w/o
Stanislaws patch. Do you understand what I'm trying to say?



Thanks,
kind regards,
Andreas