On Saturday 30 July 2011 22:03:34 Andreas Hartmann wrote: > Jouni Malinen schrieb: > > On Fri, Jul 29, 2011 at 07:22:17PM +0200, Helmut Schaa wrote: > >> Since EAPOL frames are normal data frames they are treated by the > >> rate control algorithm as such. Thus it can happen that the rate > >> control algorithm chooses an inappropriate rate (minstrel_ht uses > >> MCS rates for example) for the 4-way handshake and under low signal > >> conditions the handshake may time out. > >> > >> To fix this issue always treat EAPOL frames the same as management > >> frames and send them with the lowest available rate. > > > > I don't think that this should be applied for the reasons given (and > > alternative mechanisms proposed) in the discussion. > > I tested it with AP (rt2860) (with STA rt3572sta) under load and > couldn't see any improvement. The first PTK-rekeying didn't work as > usual. Or should it be applied to STA? might be a shot into the dark. But who's assigning a proper frame sequence to each eapol? Hostapd certainly can't because it doesn't know what's the current sequence at the moment... and mac80211 won't assign one because the frame is injected by a monitor interface. So when the receiver gets the EAPOL it might drops it because the empty sequence might be not in the BA window anymore. Does this sound reasonable, or did I miss something? Regards, Chr -- 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
