[PATCH] mac80211: don't WARN on bad WMM parameters from buggy APs

Subsystems: mac80211, the rest

STALE3028d

3 messages, 3 authors, 2018-04-17 · open the first message on its own page

[PATCH] mac80211: don't WARN on bad WMM parameters from buggy APs

From: Emmanuel Grumbach <hidden>
Date: 2018-03-26 13:21:09

Apparently, some APs are buggy enough to send a zeroed
WMM IE. Don't WARN on this since this is not caused by a bug
on the client's system.

This aligns the condition of the WARNING in drv_conf_tx
with the validity check in ieee80211_sta_wmm_params.
We will now pick the default values whenever we get
a zeroed WMM IE.

This has been reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=199161

Signed-off-by: Emmanuel Grumbach <redacted>
---
 net/mac80211/mlme.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 39b660b9a908..a6b628964b84 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1785,7 +1785,8 @@ static bool ieee80211_sta_wmm_params(struct ieee80211_local *local,
 		params[ac].acm = acm;
 		params[ac].uapsd = uapsd;
 
-		if (params[ac].cw_min > params[ac].cw_max) {
+		if (params->cw_min == 0 ||
+		    params[ac].cw_min > params[ac].cw_max) {
 			sdata_info(sdata,
 				   "AP has invalid WMM params (CWmin/max=%d/%d for ACI %d), using defaults\n",
 				   params[ac].cw_min, params[ac].cw_max, aci);
-- 
2.14.3

Re: [PATCH] mac80211: don't WARN on bad WMM parameters from buggy APs

From: Christian Lamparter <hidden>
Date: 2018-04-17 12:11:03

Hello,

On Monday, 26. March 2018 15:21:04 CEST Emmanuel Grumbach wrote:
quoted hunk
Apparently, some APs are buggy enough to send a zeroed
WMM IE. Don't WARN on this since this is not caused by a bug
on the client's system.

This aligns the condition of the WARNING in drv_conf_tx
with the validity check in ieee80211_sta_wmm_params.
We will now pick the default values whenever we get
a zeroed WMM IE.

This has been reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=199161

Signed-off-by: Emmanuel Grumbach <redacted>
---
 net/mac80211/mlme.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 39b660b9a908..a6b628964b84 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1785,7 +1785,8 @@ static bool ieee80211_sta_wmm_params(struct ieee80211_local *local,
 		params[ac].acm = acm;
 		params[ac].uapsd = uapsd;
 
-		if (params[ac].cw_min > params[ac].cw_max) {
+		if (params->cw_min == 0 ||
I'm getting:
[  164.503843] wlan0: AP has invalid WMM params (CWmin/max=15/1023 for ACI 0), using defaults

The AP is running a recent OpenWrt and is using hostapd 2.7.

iw says the AP has the following WMM IE:
        Extended capabilities: Extended Channel Switching, SSID List, 6
        WMM:     * Parameter version 1
                 * u-APSD
                 * BE: CW 15-1023, AIFSN 3
                 * BK: CW 15-1023, AIFSN 7
                 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
                 * VO: CW 3-7, AIFSN 2, TXOP 1504 usec

which looks reasonable.

What seems to be happening is that the code now expects to start
with ac = 0.

802.11-2012's Figure 8-192 EDCA Parameter Set element lists the AC_BE as the
first element in the IE and because of this ac variable gets set to 
IEEE80211_AC_BE [1] in the first round. This would be fine, if 
IEEE80211_AC_BE was 0, but it is 2 [2].

Should this be params[ac].cw_min? or params[aci].cw_min?
Or should the params->cw_min check be placed after the loop?
Can you please sent a fix? Thanks.

Regards,
Christian

[1] <https://elixir.bootlin.com/linux/v4.17-rc1/source/net/mac80211/mlme.c#L1768>
[2] <https://elixir.bootlin.com/linux/v4.17-rc1/source/include/net/mac80211.h#L148>

Re: [PATCH] mac80211: don't WARN on bad WMM parameters from buggy APs

From: Johannes Berg <johannes@sipsolutions.net>
Date: 2018-04-17 14:51:11

On Tue, 2018-04-17 at 14:11 +0200, Christian Lamparter wrote:
quoted
-		if (params[ac].cw_min > params[ac].cw_max) {
+		if (params->cw_min == 0 ||
Yeah. We already have a fix pending

https://patchwork.kernel.org/patch/10320823/

I just haven't been keeping up during the merge window.

johannes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help