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-de...@lists.ath9k.org
> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to