When forming a Rx BA session, sometimes the ADDBA response gets lost.
This leads to a situation where the session is configured locally, but
doesn't exist on the remote side. Subsequent ADDBA requests are declined
by mac80211.
Fix this by assuming the session state of the initiator is the correct
one. When receiving an unexpected ADDBA request on a TID with an active
Rx BA session, delete the existing one and establish a new session.
Signed-off-by: Arik Nemtsov <[email protected]>
---
net/mac80211/agg-rx.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 0c9d0c0..5c35bd3 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -246,7 +246,11 @@ void ieee80211_process_addba_request(struct ieee80211_local *local,
"%pM on tid %u\n",
mgmt->sa, tid);
#endif /* CONFIG_MAC80211_HT_DEBUG */
- goto end;
+
+ /* delete existing Rx BA session on the same tid */
+ ___ieee80211_stop_rx_ba_session(sta, tid, WLAN_BACK_RECIPIENT,
+ WLAN_STATUS_UNSPECIFIED_QOS,
+ false);
}
/* prepare A-MPDU MLME for Rx aggregation */
--
1.7.4.1
On Tue, 2011-05-03 at 12:12 +0300, Arik Nemtsov wrote:
> When forming a Rx BA session, sometimes the ADDBA response gets lost.
> This leads to a situation where the session is configured locally, but
> doesn't exist on the remote side. Subsequent ADDBA requests are declined
> by mac80211.
>
> Fix this by assuming the session state of the initiator is the correct
> one. When receiving an unexpected ADDBA request on a TID with an active
> Rx BA session, delete the existing one and establish a new session.
I thought about this for a while but I don't really have an opinion I
think. Maybe the behaviour could be avoided by checking the ack status,
but that wouldn't be good enough for devices that don't have that...
johannes
On Thu, May 5, 2011 at 02:17, Arik Nemtsov <[email protected]> wrote:
> On Thu, May 5, 2011 at 02:15, Arik Nemtsov <[email protected]> wrote:
>>
>>
>> On Wed, May 4, 2011 at 19:50, Johannes Berg <[email protected]>
>> wrote:
>>>
>>> On Tue, 2011-05-03 at 12:12 +0300, Arik Nemtsov wrote:
>>> > When forming a Rx BA session, sometimes the ADDBA response gets lost.
>>> > This leads to a situation where the session is configured locally, but
>>> > doesn't exist on the remote side. Subsequent ADDBA requests are declined
>>> > by mac80211.
>>> >
>>> > Fix this by assuming the session state of the initiator is the correct
>>> > one. When receiving an unexpected ADDBA request on a TID with an active
>>> > Rx BA session, delete the existing one and establish a new session.
>>>
>>> I thought about this for a while but I don't really have an opinion I
>>> think. Maybe the behaviour could be avoided by checking the ack status,
>>> but that wouldn't be good enough for devices that don't have that...
>>
>> It helped me with at least two APs (when I put them far enough from the
>> station). I guess it won't hurt anything.
>> Checking the ack won't do any actual good - if the AP doesn't send another
>> ADDBA request we won't have a session up anyway. It just saves a little
>> memory on the reorder buffer.
>> Arik
>
> [replying again with a plain text email]
>
ping?
On Thu, May 5, 2011 at 02:15, Arik Nemtsov <[email protected]> wrote:
>
>
> On Wed, May 4, 2011 at 19:50, Johannes Berg <[email protected]>
> wrote:
>>
>> On Tue, 2011-05-03 at 12:12 +0300, Arik Nemtsov wrote:
>> > When forming a Rx BA session, sometimes the ADDBA response gets lost.
>> > This leads to a situation where the session is configured locally, but
>> > doesn't exist on the remote side. Subsequent ADDBA requests are declined
>> > by mac80211.
>> >
>> > Fix this by assuming the session state of the initiator is the correct
>> > one. When receiving an unexpected ADDBA request on a TID with an active
>> > Rx BA session, delete the existing one and establish a new session.
>>
>> I thought about this for a while but I don't really have an opinion I
>> think. Maybe the behaviour could be avoided by checking the ack status,
>> but that wouldn't be good enough for devices that don't have that...
>
> It helped me with at least two APs (when I put them far enough from the
> station). I guess it won't hurt anything.
> Checking the ack won't do any actual good - if the AP doesn't send another
> ADDBA request we won't have a session up anyway. It just saves a little
> memory on the reorder buffer.
> Arik
[replying again with a plain text email]