[PATCH] wcn36xx: Fix (QoS) null data frame bitrate/modulation

Subsystems: atheros ath generic utilities, qualcomm wcn36xx wireless driver, the rest

STALE1778d LANDED

Landed in mainline as d3fd2c95c1c1 on 2021-10-25.

2 messages, 2 authors, 2021-10-25 · open the first message on its own page

[PATCH] wcn36xx: Fix (QoS) null data frame bitrate/modulation

From: Loic Poulain <hidden>
Date: 2021-10-18 12:22:04

We observe unexpected connection drops with some APs due to
non-acked mac80211 generated null data frames (keep-alive).
After debugging and capture, we noticed that null frames are
submitted at standard data bitrate and that the given APs are
in trouble with that.

After setting the null frame bitrate to control bitrate, all
null frames are acked as expected and connection is maintained.

Not sure if it's a requirement of the specification, but it seems
the right thing to do anyway, null frames are mostly used for control
purpose (power-saving, keep-alive...), and submitting them with
a slower/simpler bitrate/modulation is more robust.

Cc: stable@vger.kernel.org
Fixes: 512b191d9652 ("wcn36xx: Fix TX data path")
Signed-off-by: Loic Poulain <redacted>
---
 drivers/net/wireless/ath/wcn36xx/txrx.c | 1 +
 1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/wcn36xx/txrx.c b/drivers/net/wireless/ath/wcn36xx/txrx.c
index ef1b133..ce4f631 100644
--- a/drivers/net/wireless/ath/wcn36xx/txrx.c
+++ b/drivers/net/wireless/ath/wcn36xx/txrx.c
@@ -535,6 +535,7 @@ static void wcn36xx_set_tx_data(struct wcn36xx_tx_bd *bd,
 	if (ieee80211_is_any_nullfunc(hdr->frame_control)) {
 		/* Don't use a regular queue for null packet (no ampdu) */
 		bd->queue_id = WCN36XX_TX_U_WQ_ID;
+		bd->bd_rate = WCN36XX_BD_RATE_CTRL;
 	}
 
 	if (bcast) {
-- 
2.7.4

Re: [PATCH] wcn36xx: Fix (QoS) null data frame bitrate/modulation

From: Kalle Valo <hidden>
Date: 2021-10-25 13:24:09

Loic Poulain [off-list ref] wrote:
We observe unexpected connection drops with some APs due to
non-acked mac80211 generated null data frames (keep-alive).
After debugging and capture, we noticed that null frames are
submitted at standard data bitrate and that the given APs are
in trouble with that.

After setting the null frame bitrate to control bitrate, all
null frames are acked as expected and connection is maintained.

Not sure if it's a requirement of the specification, but it seems
the right thing to do anyway, null frames are mostly used for control
purpose (power-saving, keep-alive...), and submitting them with
a slower/simpler bitrate/modulation is more robust.

Cc: stable@vger.kernel.org
Fixes: 512b191d9652 ("wcn36xx: Fix TX data path")
Signed-off-by: Loic Poulain <redacted>
Signed-off-by: Kalle Valo <redacted>
Patch applied to ath-next branch of ath.git, thanks.

d3fd2c95c1c1 wcn36xx: Fix (QoS) null data frame bitrate/modulation

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/1634560399-15290-1-git-send-email-loic.poulain@linaro.org/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help