linux-kernel - Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50EAE3E1.4010809@01019freenet.de>
Date:	Mon, 07 Jan 2013 16:04:01 +0100
From:	Andreas Hartmann <andihartmann@...19freenet.de>
To:	Ben Hutchings <ben@...adent.org.uk>
CC:	Stanislaw Gruszka <sgruszka@...hat.com>,
	Andreas Hartmann <andihartmann@...19freenet.de>,
	Johannes Berg <johannes@...solutions.net>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	Helmut Schaa <helmut.schaa@...glemail.com>,
	"John W. Linville" <linville@...driver.com>
Subject: Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU
 subframe fails

Ben Hutchings wrote:
> On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote:
>> On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote:
>>>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/