There are a few situations where it's completely pointless
to send delBA action frames, so let's remove them.
johannes
On Wed, Sep 19, 2012 at 1:08 PM, Johannes Berg
<[email protected]> wrote:
> There are a few situations where it's completely pointless
> to send delBA action frames, so let's remove them.
Maybe it's a good opportunity to also fix ieee80211_reconfig? I
remember you mentioned some FW/HW issue there, perhaps this was solved
in the meantime. Otherwise we can add a HW flag for that I guess.
Arik
From: Johannes Berg <[email protected]>
There's no reason to send a delBA when the
peer refused our addBA, so change that.
Signed-off-by: Johannes Berg <[email protected]>
---
net/mac80211/agg-tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index d0deb3e..3195a63 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -869,7 +869,7 @@ void ieee80211_process_addba_resp(struct ieee80211_local *local,
} else {
___ieee80211_stop_tx_ba_session(sta, tid, WLAN_BACK_INITIATOR,
- true);
+ false);
}
out:
--
1.7.10.4
On Wed, 2012-09-19 at 22:45 +0300, Arik Nemtsov wrote:
> >> Maybe it's a good opportunity to also fix ieee80211_reconfig? I
> >> remember you mentioned some FW/HW issue there, perhaps this was solved
> >> in the meantime. Otherwise we can add a HW flag for that I guess.
> >
> > Not sure what you mean?
>
> All BA sessions are destroyed right after reconfig. For devices that
> manage these in FW, the FW was just reloaded and doesn't know about
> existing sessions at all.
> So I guess there's sense in sending the delBA, but no sense calling
> the driver ampdu callback (at least for how 12xx works).
Oh right. This is more of a workaround I guess, since we can't restore
them very well after a firmware reload won't know anything about them. I
haven't really thought much about this at all.
johannes
On Wed, 2012-09-19 at 12:08 +0200, Johannes Berg wrote:
> There are a few situations where it's completely pointless
> to send delBA action frames, so let's remove them.
Applied all three.
johannes
From: Johannes Berg <[email protected]>
When a station is removed and we stop the aggregation
sessions, it's not useful to send delBA since this is
due to us or the station disassociating or dropping
the connection in some other way, so change that.
Signed-off-by: Johannes Berg <[email protected]>
---
net/mac80211/sta_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 9c8cd8b..797dd36 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -738,7 +738,7 @@ int __must_check __sta_info_destroy(struct sta_info *sta)
* will be sufficient.
*/
set_sta_flag(sta, WLAN_STA_BLOCK_BA);
- ieee80211_sta_tear_down_BA_sessions(sta, true);
+ ieee80211_sta_tear_down_BA_sessions(sta, false);
ret = sta_info_hash_del(local, sta);
if (ret)
--
1.7.10.4
On Wed, Sep 19, 2012 at 10:34 PM, Johannes Berg
<[email protected]> wrote:
> On Wed, 2012-09-19 at 22:32 +0300, Arik Nemtsov wrote:
>> On Wed, Sep 19, 2012 at 1:08 PM, Johannes Berg
>> <[email protected]> wrote:
>> > There are a few situations where it's completely pointless
>> > to send delBA action frames, so let's remove them.
>>
>> Maybe it's a good opportunity to also fix ieee80211_reconfig? I
>> remember you mentioned some FW/HW issue there, perhaps this was solved
>> in the meantime. Otherwise we can add a HW flag for that I guess.
>
> Not sure what you mean?
All BA sessions are destroyed right after reconfig. For devices that
manage these in FW, the FW was just reloaded and doesn't know about
existing sessions at all.
So I guess there's sense in sending the delBA, but no sense calling
the driver ampdu callback (at least for how 12xx works).
>
> FWIW these patches were sitting in my tree as part of a larger set of
> changes around the driver ampdu callback to help drivers with internal
> queues drop or flush frames appropriately and to react to the different
> situations. I didn't think about reconfig at all with this.
Yea. These handle other situations.
From: Johannes Berg <[email protected]>
When we disassociate, it's not really useful to
send delBA action frames since we're going to send
disassoc/deauth anyway, so change that.
Signed-off-by: Johannes Berg <[email protected]>
---
net/mac80211/mlme.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 2dbd9e1..e714ed8 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1399,7 +1399,7 @@ static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata,
sta = sta_info_get(sdata, ifmgd->bssid);
if (sta) {
set_sta_flag(sta, WLAN_STA_BLOCK_BA);
- ieee80211_sta_tear_down_BA_sessions(sta, tx);
+ ieee80211_sta_tear_down_BA_sessions(sta, false);
}
mutex_unlock(&local->sta_mtx);
--
1.7.10.4
On Wed, 2012-09-19 at 22:32 +0300, Arik Nemtsov wrote:
> On Wed, Sep 19, 2012 at 1:08 PM, Johannes Berg
> <[email protected]> wrote:
> > There are a few situations where it's completely pointless
> > to send delBA action frames, so let's remove them.
>
> Maybe it's a good opportunity to also fix ieee80211_reconfig? I
> remember you mentioned some FW/HW issue there, perhaps this was solved
> in the meantime. Otherwise we can add a HW flag for that I guess.
Not sure what you mean?
FWIW these patches were sitting in my tree as part of a larger set of
changes around the driver ampdu callback to help drivers with internal
queues drop or flush frames appropriately and to react to the different
situations. I didn't think about reconfig at all with this.
johannes