On Tue, Feb 24, 2015 at 11:38:02PM +0100, Thomas Hühn wrote: > Minstrel_HT does only set mrr[0..2] and does not touch the fourth mrr[3], > assumed chips with 4 mrr stages. > In function minstrel_ht_update_rates() the rate table struct > ieee80211_sta_rates is set for the first 3 out of 4 rates and the fouth rate > (mrr[3]) is „-1“.
Agreed. > In case of ath9k, the driver in xmit.c allocates in function > ath_tx_fill_desc() a struct ath_tx_info info by memset(&info, 0, > sizeof(info)) .. so all info->rates[xy].Rate == 0. > Than function ath_buf_set_rate() sets all info->rates[xy].Rate to those > values specified in the rate table (struct ieee8021_sta_rate) IF > (!rates[i].count || (rates[i].idx < 0)) … > … so info->rates[3].Rate is untouched and still „0“. Sure, it can be 0 and so is the number of tries at that rate.. > I just added a printk() to xmit.c in function ath_tx_fill_desc() just before > ath9k_hw_set_txdesc() is called. > From the log I get, e.g.: > > [ 169.543554] mrr setup: mrr[0]:133 mrr[1]:132 mrr[2]:134 mrr[3]:0 > > I have not check yet if info->rates[3].Rate == 0 is the lowest possible rate… > but I would guess so. It is not and even if it were, it does not matter since this 4th item is used for _0_ tries. I've verified the exact behavior with a sniffer for a case where the target device does not ACK frames. ath9k ends up sending at exactly the three different rates indicated in the first three values and nothing else. With RC probing (which happens to occur for the initial EAPOL frames, this results in only one attempt at MCS(>0) and two + two attempts at MCS0. No non-MCS rates are tried. As pointed out previously, this is likely fine for normal data frames, but not for EAPOL. -- Jouni Malinen PGP id EFC895FA -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
