On Mon, Feb 23, 2015 at 02:22:32PM -0800, Adrian Chadd wrote: > On 23 February 2015 at 13:53, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > So the theory that the driver starts at too high a transmit rate, and > > then does not handle failures well, might be true. Of course, "not > > handle failures well" is something of an understatement. > Hm, can we just hack mac80211/ath9k to set /all/ EAPOL frames to the > lowest negotiated basic rate and test? That way we don't have to worry > about things resetting fixed rates or whatnot. This did not get exactly supportive response when this was proposed last time (Sep 2013). Anyway, for a quick test, this can be done with the following one-liner: diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index c314c59..b45038f 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -566,6 +566,7 @@ ieee80211_tx_h_check_control_port_protocol(struct ieee80211_tx_data *tx) if (tx->sdata->control_port_no_encrypt) info->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT; info->control.flags |= IEEE80211_TX_CTRL_PORT_CTRL_PROTO; + info->flags |= IEEE80211_TX_CTL_USE_MINRATE; } return TX_CONTINUE; Even I think that this goes a bit too far especially on 2.4 GHz band, but I would actually consider limiting EAPOL frames to using non-HT/VHT (e.g., 6 Mbps OFDM at least for EAPOL-Key frames) to avoid some interoperability issues. I would say that the current minstrel_ht behavior is somewhat excessive for EAPOL-Key frames in the other direction. Using MCS 14 with fallback to something like MCS 5 for the second Data frame after an association can certainly fail. Number of Linux drivers do already limit EAPOL frame TX rate, so this specific item is mainly applicable only to driver that use minstrel from mac80211 (e.g., ath9k). Though, that IEEE80211_TX_CTL_USE_MINRATE would likely affect most mac80211 drivers. -- 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
