| Message ID | 1304413928-17673-1-git-send-email-arik@wizery.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 5, 2011 at 02:15, Arik Nemtsov <arik@wizery.com> wrote: > > > On Wed, May 4, 2011 at 19:50, Johannes Berg <johannes@sipsolutions.net> > 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] -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 5, 2011 at 02:17, Arik Nemtsov <arik@wizery.com> wrote: > On Thu, May 5, 2011 at 02:15, Arik Nemtsov <arik@wizery.com> wrote: >> >> >> On Wed, May 4, 2011 at 19:50, Johannes Berg <johannes@sipsolutions.net> >> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 */
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 <arik@wizery.com> --- net/mac80211/agg-rx.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-)