Hi Felix,
On 2012-02-02 13:35, Felix Fietkau wrote:
Please try this patch:
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1061,13 +1061,16 @@ void ath9k_hw_init_global_settings(struc
/*
* Workaround for early ACK timeouts, add an offset to match the
- * initval's 64us ack timeout value.
+ * initval's 64us ack timeout value. Use 48us for the CTS timeout.
* This was initially only meant to work around an issue with delayed
* BA frames in some implementations, but it has been found to fix ACK
* timeout issues in other cases as well.
*/
- if (conf->channel&& conf->channel->band == IEEE80211_BAND_2GHZ)
+ if (conf->channel&& conf->channel->band == IEEE80211_BAND_2GHZ) {
acktimeout += 64 - sifstime - ah->slottime;
+ ctstimeout += 48 - sifstime - ah->slottime;
+ }
+
ath9k_hw_set_sifs_time(ah, sifstime);
ath9k_hw_setslottime(ah, slottime);
I have been seeing the same issues with the Atheros 9170 USB chipset using the carl9170 driver and firmware, where RST are transmitted repeatidly, even though a CTS-reply is seen on the air. I suspect the issue to be related to this one, but I am unable to locate any calculation or setting of CTS timeout in the driver or firmware.
Can anyone point me in the right direction to tune the CTS timeout with the 9170 chip?
Regards,
Martin Hundebøll
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
