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]
Date:	Mon, 07 Jan 2013 19:38:35 +0100
From:	Andreas Hartmann <andihartmann@...19freenet.de>
To:	Stanislaw Gruszka <sgruszka@...hat.com>
CC:	Andreas Hartmann <andihartmann@...19freenet.de>,
	Ben Hutchings <ben@...adent.org.uk>,
	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

Stanislaw Gruszka wrote:
> On Mon, Jan 07, 2013 at 04:04:01PM +0100, Andreas Hartmann wrote:
>> 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.
> 
> That's not true. There will be no regression after ab9d6e4ffe20. The
> only thing is that solution is not perfect. But perfect solution require
> lot of changes i.e. is not -stable appropriate (and does not exist currently).
> 
>>> 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
> 
> Your workaround broke STA mode on some environment.

Why are you sure, that this workaround doesn't break some other devices
running in AP mode? We believed at that time too, it wouldn't harm even
STA. But this was wrong for some (which?) devices.


Anyway: As Helmut meanwhile mentioned that he thankfully works on a
solution now, I'm fine with the second round of workaround.



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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ