On Monday, December 03, 2012 03:13:55 PM Andreas Hartmann wrote: > Stanislaw Gruszka wrote: > > Commit f0425beda4d404a6e751439b562100b902ba9c98 "mac80211: retry sending > > failed BAR frames later instead of tearing down aggr" caused regression > > on rt2x00 hardware (connection hangs). > > This patch caused a problem, too, with carl9170 > (http://thread.gmane.org/gmane.linux.kernel.wireless.general/92203/focus=92376). > How did they fix it (the thread unfortunately ends without any solution > / patch). This was fixed by: carl9170: fix HT peer BA session corruption (c9122c0d63a50 in wireless-testing). The issue here is that the hardware does not set the tx success bit when it receives a BA for a sent BAR [looks like it is expecting a legacy ACK?! but who knows - the original vendor driver [otus] didn't really deal with BARs anyway]. So the driver has to do that job and currently it's done in the following way: When mac80211 sends a BAR, the driver will keep a reference of the frame around in ar->bar_list, before it is sent on its way. If the device receives a BA within the retry window then the driver's rx-path will enter carl9170_ba_check. This function sets the TX_STAT_ACK flag [for the BAR] if the incoming BA matches. While there are a few problems with this approach [added tx and rx overhead due to flexible ba filtering and bar queuing, unwanted BAR retries, ...], it was one of the better solution which was within the capabilities of the hardware, firmware and driver. Obviously, if the ar9170 hardware would just set that tx success bit [ath9k mac does this properly], this wouldn't be necessary. Regards, Chr -- 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
