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

[Jouni Malinen <j@w1.fi>]

On Tue, Feb 24, 2015 at 06:54:47PM +0100, Thomas Hühn wrote:
> Currently Minstrel_HT just skips EAPOL packets for its rate sampling on non-mrr chips by testing: (info->control.flags & IEEE80211_TX_CTRL_PORT_CTRL_PROTO)

Yeah, I noticed that when going through the implementation, but it was
indeed only for cases other than ath9k-like drivers.

> On mrr hardware it uses them for probing. 
> But the general MRR-chain should look like this for ath5k and ath9k chips that support 4 mrr chains:
> 
> mrr[0]:= max_tp_rate[0]
> mrr[1]:= max_tp_rate[1]
> mrr[2]:= max_prob_rate
> mrr[3]:= basic_rate

Where is that mrr[3] part implemented? I did not find it when reviewing
the design (hw->max_rates >= 3 is used, but not >= 4) and this does not
match my experiments either when printing out all four values from
ath9k. In every single case I observed, the last entry was unused (idx =
-1) and only MCS values were used (i.e., not even a single case of basic
rate visible; basic rates being 6, 12, 24 Mbps OFDM in this specific
case with the AP that I used in the tests).

> So for Minstrel Sampling Packets as well as for data packets, the 4th mrr stage should use the slowest rate in case all other 3 mrr stages failed with their retry attempts.
> 
> I do see two possible options for control frames like EAPOL to be send out in a more robust fashion:
>  - exclude those frames from AMPDU aggragates 

ath9k does that for IEEE80211_TX_CTL_RATE_CTRL_PROBE which seemed to
get set for the initial EAPOL frames. I guess this could be done more
generically for all EAPOL frames.

>  - change their mrr setup to be more conservative

That mrr[3]:= basic_rate is the part I was really asking for as far as
EAPOL frames are concerned.

-- 
Jouni Malinen                                            PGP id EFC895FA