| Message ID | 1312537579-18950-1-git-send-email-helmut.schaa@googlemail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Fri, 2011-08-05 at 11:46 +0200, Helmut Schaa wrote: > According to 802.11-2007, 7.3.1.14 it is compliant to use a buf_size of > 0 in ADDBA requests. But some devices (AVM Fritz Stick N) arn't able to > handle that correctly and will reply with an ADDBA reponse with a > buf_size of 0 which in turn will disallow BA sessions for these > devices. > > To work around this problem, initialize hw.max_tx_aggregation_subframes > to the maximum AMPDU buffer size 0x40. > > Using 0 as default for the bufsize was introduced in commit > 5dd36bc933e8be84f8369ac64505a2938f9ce036 (mac80211: allow advertising > correct maximum aggregate size). So, are you saying the problem with getting 0 in replies is solved by not sending 0 in requests? Patch looks fine to me, but it's not clear to me that it's the only thing needed? Acked-by: Johannes Berg <johannes@sipsolutions.net> 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 Mon, Aug 8, 2011 at 10:29 AM, Johannes Berg <johannes@sipsolutions.net> wrote: > So, are you saying the problem with getting 0 in replies is solved by > not sending 0 in requests? This specific device always replies with a buf_size=0 _if_ we send an ADDBA request with a buf_size=0. The first patch in this series solves a problem were mac80211 would buffer frames to this STA forever when the ADDBA response contains a buf_size=0 since the BA session is stuck in an intermediate state. However, the AVM Fritz Stick N client behaves correctly if we're using a buf_size != 0 in the ADDBA request. This is a bug in the Fritz Stick Windows driver (it should use the default size of its rx reorder buffer if the ADDBA request contains 0). However, this bug can be worked around by using a buf_size != 0 in ADDBA requests. And that's what the second patch does. Hope this clarifies my intention :) Helmut -- 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 Mon, 2011-08-08 at 10:40 +0200, Helmut Schaa wrote: > On Mon, Aug 8, 2011 at 10:29 AM, Johannes Berg > <johannes@sipsolutions.net> wrote: > > So, are you saying the problem with getting 0 in replies is solved by > > not sending 0 in requests? > > This specific device always replies with a buf_size=0 _if_ we send an > ADDBA request > with a buf_size=0. > > The first patch in this series solves a problem were mac80211 would > buffer frames to > this STA forever when the ADDBA response contains a buf_size=0 since the BA > session is stuck in an intermediate state. > > However, the AVM Fritz Stick N client behaves correctly if we're using > a buf_size != 0 > in the ADDBA request. This is a bug in the Fritz Stick Windows driver > (it should use > the default size of its rx reorder buffer if the ADDBA request > contains 0). However, this > bug can be worked around by using a buf_size != 0 in ADDBA requests. And that's > what the second patch does. > > Hope this clarifies my intention :) Yes, thanks. 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
diff --git a/net/mac80211/main.c b/net/mac80211/main.c index 866f269..104fdd9 100644 --- a/net/mac80211/main.c +++ b/net/mac80211/main.c @@ -608,6 +608,7 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len, local->hw.max_rates = 1; local->hw.max_report_rates = 0; local->hw.max_rx_aggregation_subframes = IEEE80211_MAX_AMPDU_BUF; + local->hw.max_tx_aggregation_subframes = IEEE80211_MAX_AMPDU_BUF; local->hw.conf.long_frame_max_tx_count = wiphy->retry_long; local->hw.conf.short_frame_max_tx_count = wiphy->retry_short; local->user_power_level = -1;
According to 802.11-2007, 7.3.1.14 it is compliant to use a buf_size of 0 in ADDBA requests. But some devices (AVM Fritz Stick N) arn't able to handle that correctly and will reply with an ADDBA reponse with a buf_size of 0 which in turn will disallow BA sessions for these devices. To work around this problem, initialize hw.max_tx_aggregation_subframes to the maximum AMPDU buffer size 0x40. Using 0 as default for the bufsize was introduced in commit 5dd36bc933e8be84f8369ac64505a2938f9ce036 (mac80211: allow advertising correct maximum aggregate size). Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> --- net/mac80211/main.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)