Hi Jouni, >> 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.. You are absolutely right … as the tries are 0 as well, the 4th mrr[3] is not used. I missed that obvious point. >> 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. I do agree in changing the way to assign a (mrr) rate set for EAPOL frames in the most robust fashion. Greetings Thomas > > -- > Jouni Malinen PGP id EFC895FA > _______________________________________________ > ath9k-devel mailing list > ath9k-devel@xxxxxxxxxxxxxxx > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- 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
