Hello,
I hope this is the correct forum for this type of question.
What does mac80211 expect driver/hw to do when an A-MPDU is received
without an existing block ack agreement?
This may occur when an existing RX BACK agreement times out, and the
peer STA fails to hear the DELBA frame.
The best option I can think of would be to drop the subframes and
re-transmit the DELBA, but this (at least the second part) should be
handled by mac80211 and not the driver.
The standard doesn't seem to be clear on this point (not that it's
clear on many points).
/Johan
On Wednesday, January 09, 2013 02:54:33 PM Johannes Berg wrote:
> On Wed, 2013-01-09 at 14:46 +0100, Christian Lamparter wrote:
> Why do we even tear down RX sessions at all?
ti's wl1271 has fixed rx ba agreement limit.
Also 802.11-2012 10.5.4 states:
"Every STA shall maintain an inactivity timer for every negotiated
Block Ack Setup. [then it goes on what the originator and recipient
should do...]". The recipient needs to be able to tear down BA
session too.
Regards,
Chr
Hello Johan,
On Tuesday, January 08, 2013 10:47:22 PM Johan Danielsson wrote:
> Maybe I'm incomprehensible, so let me try to clarify my question.
Thanks! Hopefully we can clear up some confusion.
> The normal sequence of events for HT A-MPDU BlockAck agreements are:
>
> 1) we receive an ADDBA
> 2) ampdu_action is called with RX_START
> 3) we send an ADDBA response
> 4) time passes with no activity
> 5) ampdu_action is called with RX_STOP
> 6) a DELBA is sent to the peer STA
> 7) everything is cool and froody
>
> However if 6 results in a failed transmission, mac80211 doesn't care,
> and we have a situation where the peer may continue to send A-MPDU:s,
> but we don't have any agreement, so we can't properly ACK.
Ah, I think I didn't get the "This may occur when an existing RX BACK
agreement times out, and the peer STA fails to hear the DELBA frame."
sentence in your original post.
I thought that this was just an example. But a semi-rogue device can
sent AMPDUs to anyone at anytime, so I argued that if we have no (or
no longer) a BA agreement [even if the peer never got the DELBA] we can
discard the AMPDU data and sent a DELBAs to the HT peer once it tries
sent us an A-MPDU (again). This is actually what we should do according
to 802.11-2012 10.5.4 - instead of calling dont_reorder. This would also
cover your case where a HT peer suddenly reappears again. Because once
the HT peer sends an AMPDU and the BA agreement has timed out on our side,
it will get a DELBA back the stale BA agreement on the Phoenix HT peer
will be torn down [but the peer can be established it again by sending
out a new ADDBA].
> 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:
commit 07db218396650933abff3c5c1ad1e2a6e0cfedeb
Author: Ron Rindjunsky <[email protected]>
Date: Tue Dec 25 17:00:33 2007 +0200
mac80211: A-MPDU Rx adding basic functionality
Stanislaw, do you know if iwlegacy needs AGG_RX_STOP before it can sent out
the DELBA [Maybe something about flushing an FW internal RX reorder buffer,
or anything]?
> 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.]
[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.]
Regards,
Chr
On Wednesday, January 09, 2013 06:43:05 PM Christian Lamparter wrote:
> On Wednesday, January 09, 2013 11:05:20 AM Johan Danielsson wrote:
> > > [...] I argued that if we have no (or no longer) a BA agreement
> > > [even if the peer never got the DELBA] we can discard the AMPDU data
> > > and sent a DELBAs to the HT peer once it tries sent us an A-MPDU
> > > (again). This is actually what we should do according to 802.11-2012
> > > 10.5.4 - instead of calling dont_reorder.
> >
> > I think this is a reasonable interpretation, even though 10.5.4
> > doesn't explicitly cover this case (since the Ack Policy is set to
> > Normal Ack).
>
> This is were RX_FLAG_AMPDU_DETAILS would come into the game.
> If this rx flag is set we know that the frame was part of
> an AMPDU and not a normal non-aggregated QoS-Data frame.
>
In fact, here's what I had in mind [top of wireless-testing.git
just compiled-tested. I hope it doesn't Oops].
Does this patch help in your case?
Note: This patch will only work with drivers which sets
RX_FLAG_AMPDU_DETAILS accordingly [currently: iwlwifi or
carl9170].
---
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 0fa44a9..3fffc93 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -823,6 +823,7 @@ enum sdata_queue_type {
IEEE80211_SDATA_QUEUE_TYPE_FRAME = 0,
IEEE80211_SDATA_QUEUE_AGG_START = 1,
IEEE80211_SDATA_QUEUE_AGG_STOP = 2,
+ IEEE80211_SDATA_QUEUE_AGG_KILL = 3,
};
enum {
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 06fac29..16abbdc 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1086,6 +1086,31 @@ static void ieee80211_iface_work(struct work_struct *work)
ra_tid = (void *)&skb->cb;
ieee80211_stop_tx_ba_cb(&sdata->vif, ra_tid->ra,
ra_tid->tid);
+ } else if (skb->pkt_type == IEEE80211_SDATA_QUEUE_AGG_KILL) {
+ /* So the frame isn't mgmt, but frame_control
+ * is at the right place anyway, of course, so
+ * the if statement is correct.
+ */
+ struct ieee80211_hdr *hdr = (void *)mgmt;
+
+ /* This can happen because:
+ * - fragment of a frame, received while a block-ack
+ * session was active.
+ * - AMPDU while no block-ack session was active.
+ * That cannot be right, so terminate the session.
+ */
+ mutex_lock(&local->sta_mtx);
+ sta = sta_info_get_bss(sdata, mgmt->sa);
+ if (sta) {
+ u16 tid = *ieee80211_get_qos_ctl(hdr) &
+ IEEE80211_QOS_CTL_TID_MASK;
+
+ __ieee80211_stop_rx_ba_session(
+ sta, tid, WLAN_BACK_RECIPIENT,
+ WLAN_REASON_QSTA_REQUIRE_SETUP,
+ true);
+ }
+ mutex_unlock(&local->sta_mtx);
} else if (ieee80211_is_action(mgmt->frame_control) &&
mgmt->u.action.category == WLAN_CATEGORY_BACK) {
int len = skb->len;
@@ -1112,37 +1137,6 @@ static void ieee80211_iface_work(struct work_struct *work)
}
}
mutex_unlock(&local->sta_mtx);
- } else if (ieee80211_is_data_qos(mgmt->frame_control)) {
- struct ieee80211_hdr *hdr = (void *)mgmt;
- /*
- * So the frame isn't mgmt, but frame_control
- * is at the right place anyway, of course, so
- * the if statement is correct.
- *
- * Warn if we have other data frame types here,
- * they must not get here.
- */
- WARN_ON(hdr->frame_control &
- cpu_to_le16(IEEE80211_STYPE_NULLFUNC));
- WARN_ON(!(hdr->seq_ctrl &
- cpu_to_le16(IEEE80211_SCTL_FRAG)));
- /*
- * This was a fragment of a frame, received while
- * a block-ack session was active. That cannot be
- * right, so terminate the session.
- */
- mutex_lock(&local->sta_mtx);
- sta = sta_info_get_bss(sdata, mgmt->sa);
- if (sta) {
- u16 tid = *ieee80211_get_qos_ctl(hdr) &
- IEEE80211_QOS_CTL_TID_MASK;
-
- __ieee80211_stop_rx_ba_session(
- sta, tid, WLAN_BACK_RECIPIENT,
- WLAN_REASON_QSTA_REQUIRE_SETUP,
- true);
- }
- mutex_unlock(&local->sta_mtx);
} else switch (sdata->vif.type) {
case NL80211_IFTYPE_STATION:
ieee80211_sta_rx_queued_mgmt(sdata, skb);
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index a190895..0ba5b56 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -871,6 +871,10 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
if (!ieee80211_is_data_qos(hdr->frame_control))
goto dont_reorder;
+ /* qos null data frames are excluded */
+ if (unlikely(hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_NULLFUNC)))
+ goto dont_reorder;
+
/*
* filter the QoS data rx stream according to
* STA/TID and check if this STA/TID is on aggregation
@@ -884,12 +888,12 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
tid = *ieee80211_get_qos_ctl(hdr) & IEEE80211_QOS_CTL_TID_MASK;
tid_agg_rx = rcu_dereference(sta->ampdu_mlme.tid_rx[tid]);
- if (!tid_agg_rx)
- goto dont_reorder;
-
- /* qos null data frames are excluded */
- if (unlikely(hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_NULLFUNC)))
- goto dont_reorder;
+ if (!tid_agg_rx) {
+ if (status->flag & RX_FLAG_AMPDU_DETAILS)
+ goto ba_teardown;
+ else
+ goto dont_reorder;
+ }
/* not part of a BA session */
if (ack_policy != IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK &&
@@ -908,12 +912,8 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
/* if this mpdu is fragmented - terminate rx aggregation session */
sc = le16_to_cpu(hdr->seq_ctrl);
- if (sc & IEEE80211_SCTL_FRAG) {
- skb->pkt_type = IEEE80211_SDATA_QUEUE_TYPE_FRAME;
- skb_queue_tail(&rx->sdata->skb_queue, skb);
- ieee80211_queue_work(&local->hw, &rx->sdata->work);
- return;
- }
+ if (sc & IEEE80211_SCTL_FRAG)
+ goto ba_teardown;
/*
* No locking needed -- we will only ever process one
@@ -927,6 +927,12 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
dont_reorder:
skb_queue_tail(&local->rx_skb_queue, skb);
+ return;
+
+ ba_teardown:
+ skb->pkt_type = IEEE80211_SDATA_QUEUE_AGG_KILL;
+ skb_queue_tail(&rx->sdata->skb_queue, skb);
+ ieee80211_queue_work(&local->hw, &rx->sdata->work);
}
static ieee80211_rx_result debug_noinline
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
Hello Christian,
Maybe I'm incomprehensible, so let me try to clarify my question.
The normal sequence of events for HT A-MPDU BlockAck agreements are:
1) we receive an ADDBA
2) ampdu_action is called with RX_START
3) we send an ADDBA response
4) time passes with no activity
5) ampdu_action is called with RX_STOP
6) a DELBA is sent to the peer STA
7) everything is cool and froody
However if 6 results in a failed transmission, mac80211 doesn't care,
and we have a situation where the peer may continue to send A-MPDU:s,
but we don't have any agreement, so we can't properly ACK.
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.
Swapping 5 and 6, would prevent this from happening, if there are
enough retransmissions of the DELBA.
So, my question now is: Does this reasoning make sense, or have I
missed anything?
/Johan
Hi
On Wed, Jan 09, 2013 at 12:38:01AM +0100, Christian Lamparter wrote:
> 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:
>
> commit 07db218396650933abff3c5c1ad1e2a6e0cfedeb
> Author: Ron Rindjunsky <[email protected]>
> Date: Tue Dec 25 17:00:33 2007 +0200
>
> mac80211: A-MPDU Rx adding basic functionality
>
>
> Stanislaw, do you know if iwlegacy needs AGG_RX_STOP before it can sent out
> the DELBA [Maybe something about flushing an FW internal RX reorder buffer,
> or anything]?
I think not, AGG_RX_STOP disable in firmware (ht-immediate) BA response,
when receive AMPDU (for particular station/tid). So ordering: DELBA, then
AGG_RX_STOP should be fine for iwlegacy and iwlwifi.
Thanks
Stanislaw
On Monday, January 07, 2013 11:32:53 AM Johan Danielsson wrote:
> What does mac80211 expect driver/hw to do when an A-MPDU is received
> without an existing block ack agreement?
according to ieee80211_rx_reorder_ampdu in /net/mac80211/rx.c:
it goes to "goto dont_reorder;"
> This may occur when an existing RX BACK agreement times out, and the
> peer STA fails to hear the DELBA frame.
>
> The best option I can think of would be to drop the subframes and
> re-transmit the DELBA, but this (at least the second part) should be
> handled by mac80211 and not the driver.
>
> The standard doesn't seem to be clear on this point (not that it's
> clear on many points).
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...]"
Note: The Ack Policy subfield equal to Block Ack is according to
Table 8-6 (802.11-2012 8.2.4.5.4) either
- 11
Block Ack according to 9.21
- 00
Which is used for Implicit Block Ack Requests... However it's
also used for Normal ACKs.
However, some drivers [not all] set the RX_FLAG_AMPDU_DETAILS flag when
they receive a AMPDU. 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.
Regards,
Chr
On Wed, 2013-01-09 at 14:46 +0100, Christian Lamparter wrote:
> > > [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.
>
> DelBA is part of the Block Ack Actions as defined in 802.11-2012 8.5.5.
> The Block Ack category is marked in Table 8-38 as "robust"?!
>
> Was this changed from the original 11w spec? Maybe that would explain
> why the Nexus 4 thinks it doesn't need to de-/encrypt BA agreements?.
Oops, no. I'm confusing HT action frames and BA agreement frames. Maybe
the Nexus4 developers made the same mistake? :)
> > 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.
> Good. Then it was probably just more convenient ;). But we still need
> a case for HW which doesn't support IEEE80211_HW_REPORTS_TX_ACK_STATUS.
Yeah.
But I think we're concerned about RX sessions here, so this behaviour
isn't really all that relevant. Sorry, I'm still a bit confused I guess.
Why do we even tear down RX sessions at all?
> Uh, this note was out of context. It had to do with a sentence
> from a previous post that wasn't discussed:
>
> On Tuesday, January 08, 2013 11:39:10 AM Johan Danielsson wrote:
> > 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 around.
>
> If we only call ampdu_action(RX_STOP) as part of a callback when we have
> received an ACK from a outgoing DELBA [yes I know some HW doesn't support
> that] what happens to BA agreements after all DELBAs retries have been
> used up? Or do we have to retry them endlessly? [I'm asking this because
> we do have a retry-when-we-receive-unicast for BARs already...].
Oh, right, ok.
I tend to think that if a unicast management packet really didn't go
through there isn't much you can do. Typically it would have been
retried like a dozen times already ...
johannes
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
On Wednesday, January 09, 2013 11:05:20 AM Johan Danielsson wrote:
> > [...] I argued that if we have no (or no longer) a BA agreement
> > [even if the peer never got the DELBA] we can discard the AMPDU data
> > and sent a DELBAs to the HT peer once it tries sent us an A-MPDU
> > (again). This is actually what we should do according to 802.11-2012
> > 10.5.4 - instead of calling dont_reorder.
>
> I think this is a reasonable interpretation, even though 10.5.4
> doesn't explicitly cover this case (since the Ack Policy is set to
> Normal Ack).
This is were RX_FLAG_AMPDU_DETAILS would come into the game.
If this rx flag is set we know that the frame was part of
an AMPDU and not a normal non-aggregated QoS-Data frame.
Regards,
Chr
> [...] I argued that if we have no (or no longer) a BA agreement
> [even if the peer never got the DELBA] we can discard the AMPDU data
> and sent a DELBAs to the HT peer once it tries sent us an A-MPDU
> (again). This is actually what we should do according to 802.11-2012
> 10.5.4 - instead of calling dont_reorder.
I think this is a reasonable interpretation, even though 10.5.4
doesn't explicitly cover this case (since the Ack Policy is set to
Normal Ack).
We can send a DELBA for a number of reasons, and setting the
ReasonCode to UNKNOWN_BA seems appropriate in this case.
/Johan
On Wednesday, January 09, 2013 01:02:45 PM Johannes Berg wrote:
> On Wed, 2013-01-09 at 00:38 +0100, Christian Lamparter wrote:
> > > 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.
DelBA is part of the Block Ack Actions as defined in 802.11-2012 8.5.5.
The Block Ack category is marked in Table 8-38 as "robust"?!
Was this changed from the original 11w spec? Maybe that would explain
why the Nexus 4 thinks it doesn't need to de-/encrypt BA agreements?.
> 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.
Good. Then it was probably just more convenient ;). But we still need
a case for HW which doesn't support IEEE80211_HW_REPORTS_TX_ACK_STATUS.
> > [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.
Uh, this note was out of context. It had to do with a sentence
from a previous post that wasn't discussed:
On Tuesday, January 08, 2013 11:39:10 AM Johan Danielsson wrote:
> 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 around.
If we only call ampdu_action(RX_STOP) as part of a callback when we have
received an ACK from a outgoing DELBA [yes I know some HW doesn't support
that] what happens to BA agreements after all DELBAs retries have been
used up? Or do we have to retry them endlessly? [I'm asking this because
we do have a retry-when-we-receive-unicast for BARs already...].
Regards,
Chr
> according to ieee80211_rx_reorder_ampdu in /net/mac80211/rx.c:
> it goes to "goto dont_reorder;"
Yes.
> 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).
> 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
around.
/Johan