Re: [ath9k-devel] AR9462 problems connecting again..

[Jouni Malinen <j@w1.fi>]

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