Message-ID: <1357732965.9757.4.camel@jlt4.sipsolutions.net> (sfid-20130109_130235_428725_25E5D1E3)
Subject: Re: mac80211 and RX of A-MPDU with missing back agreement
From: Johannes Berg <johannes@sipsolutions.net>
To: Christian Lamparter <chunkeey@googlemail.com>
Cc: Johan Danielsson <joda@kth.se>, linux-wireless@vger.kernel.org,
	sgruszka@redhat.com
Date: Wed, 09 Jan 2013 13:02:45 +0100
In-Reply-To: <201301090038.01984.chunkeey@googlemail.com> (sfid-20130109_003827_192837_F2D7BAE7)
References: <CAESKgcgVQYwT770OfOXZnB-06SnidfxV7DnUrAMquJZtLNsYHg@mail.gmail.com>
	 <201301081715.49672.chunkeey@googlemail.com>
	 <CAESKgcgN+ev0f-PewqP7k5E-Bq2uR2OPKDiYwrPot4B=CAiffA@mail.gmail.com>
	 <201301090038.01984.chunkeey@googlemail.com>
	 (sfid-20130109_003827_192837_F2D7BAE7)
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Sender: linux-wireless-owner@vger.kernel.org

On Wed, 2013-01-09 at 00:38 +0100, Christian Lamparter wrote:

> > My feeling is that nothing in 802.11-2012 covers this scenario. There
> > are some paragraphs that deal with similar situations when using the
> > other flavour of BlockAcks (originally defined in 802.11e I believe),
> > but in my experience, you can't assume much based in this.
> > 
> > And even if the DELBA in 6 is sent ok, there is a race between 5 and
> > 6, where the originator has block ack state, but the recipient does not.
> 
> Yes, this sounds wrong. Was there a historic reason why RX_STOP was put before
> DELBA? I've traced the code back to Intel's initial A-MPDU RX contribution:

I'm not aware of any particular reason. However, not all devices/drivers
properly report TX status, so waiting for TX status won't be feasible
with all devices/drivers.

> > So, my question now is: Does this reasoning make sense, or have I
> > missed anything?
>  
> I think reordering 5 and 6 won't stop the race entirely. ACKs are 
> usually generated by hardware (or firmware) right away when the received
> frame passed the CRC checks and found a place to stay in the HW's FIFOs.
> However by the time DELBA is processed by the peers' 802.11 stack, some
> frames on the tx-path might have left the DELBA in the dust [keep-alives
> and friends].
> 
> [Note: Action frames like DELBA have to be encrypted/decrypted when 
> MFP/802.11w is enabled on the link and some HW/FW can't do that. So
> it takes even longer to react to those.]

Actually no: HT action frames aren't robust management frames.

FWIW, our (Intel's) firmware will send frames from the aggregation
queues unaggregated as soon as it receives a DelBA frame from the peer,
so as long as it receives it there's no issue.

> [Note2: Some hardware (rtlwifi) only have some sort of "fire and forget"
> TX. The we don't know when, or even if a frame (like a DELBA) was received...]
> 
> [Note3: What will happen to DELBAs if they aren't acked? Is there a timeout
> or are they retried until the peer is dropped by other means?
> I'm asking this because with some hardware we have to be greedy with the
> number of open BA Agreements. For example ti's wl12xx can only support a
> limited number of open RX BA Agreements.]

DelBA frames are unicast frames, so they're retried normally.

johannes