From: Christian Lamparter <chunkeey@googlemail.com>
To: Johan Danielsson <joda@kth.se>
Cc: linux-wireless@vger.kernel.org
Subject: Re: mac80211 and RX of A-MPDU with missing back agreement
Date: Tue, 8 Jan 2013 17:15:49 +0100 [thread overview]
Message-ID: <201301081715.49672.chunkeey@googlemail.com> (raw)
In-Reply-To: <CAESKgcitzBNvSYC44Raw2SXbZeGKv1+SB3Q+uwO2MngOP6V5EA@mail.gmail.com>
On Tuesday, January 08, 2013 11:39:10 AM Johan Danielsson wrote:
> > 802.11-2012 in 10.5.4 should cover your approach:
> >
> > "When a recipient does not have an active Block ack for a TID, but
> > receives data MPDUs with the Ack Policy subfield equal to Block Ack,
> > it shall discard them and shall send a DELBA frame within its own
> > TXOP. [... keep on reading...]"
>
> Well, a HT STA would normally use HT-immediate block acks, so the
> policy will be Normal Ack, not Block Ack (this can be found in
> 9.21.7.7).
[Sounds like you are trying to argue with a paragraph you've removed?!].
Anyway, I've read it again. But I don't see how this affects the definition
of the Ack Policy subfield in Table 8-6 (802.11-2012 8.2.4.5.4)? Was it simply
too "much" to put both options there? Or am I missing the point of "a HT STA
WOULD NORMALLY use HT-..."? Or is there some confusion about the
"Ack Policy subfield" from a QoS frame (as defined in 8.2.4.5.4) vs.
"BAR Ack Policy subfield" from a BAR (8.3.1.8) [yes, they are different!]
> > So you should be able to extend the checks in
> > ieee80211_rx_reorder_ampdu and generate a delba from there [in a
> > similar way of how delba is sent when the stack receives a illegal,
> > fragmented frame when a BA session is in place.
>
> You could do that, but I'm not convinced it is correct. It seems more
> reasonable to send the DELBA and wait for an ACK before removing the
> BACK state (with ampdu_action). Currently this is done the other way
Are you now refering to the AMPDU teardown because of a "fragmented frame"
thing, or are you talking about your original question in this case?
[i.e.: "What does mac80211 expect driver/hw to do when an A-MPDU is received
without an existing block ack agreement?"]
For the latter: We can't call ampdu_action IEEE80211_AMPDU_RX_STOP without an
existing ba agreement in the first place. I suppose: communication-wise
something is wrong.
Regards,
Chr
next prev parent reply other threads:[~2013-01-08 16:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-07 10:32 mac80211 and RX of A-MPDU with missing back agreement Johan Danielsson
2013-01-07 19:53 ` Christian Lamparter
2013-01-08 10:39 ` Johan Danielsson
2013-01-08 16:15 ` Christian Lamparter [this message]
2013-01-08 21:47 ` Johan Danielsson
2013-01-08 23:38 ` Christian Lamparter
2013-01-09 10:05 ` Johan Danielsson
2013-01-09 17:43 ` Christian Lamparter
2013-01-09 18:32 ` Christian Lamparter
2013-01-09 10:54 ` Stanislaw Gruszka
2013-01-09 12:02 ` Johannes Berg
2013-01-09 13:46 ` Christian Lamparter
2013-01-09 13:54 ` Johannes Berg
2013-01-09 18:05 ` Christian Lamparter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201301081715.49672.chunkeey@googlemail.com \
--to=chunkeey@googlemail.com \
--cc=joda@kth.se \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.