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 -- 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
