On Fri, Jul 29, 2011 at 11:14:20AM +0200, Helmut Schaa wrote: > I just noticed that EAPOL frames generated by hostapd during the 4-way > handshake are sent out by mac80211 using a rate as selected by the rc > algorithm for data frames. In my case minstrel_ht selects a MCS rate for > 11n clients which sometimes results in a 4-way handshake timeout under > low signal conditions. That sounds like an issue that should be fixed in the rate control algorithm if it is indeed using unsuitable rate immediately after association. Dropping data frames completely is not really a good thing regardless of whether they are EAPOL packets or not.. > I haven't found anything in 802.11-2007 if EAPOL frames have to be sent > at a low rate but I'd argue that it makes sense to send them at a basic > rate just like it's done for management frames. There is no such requirement in the standard and I don't see why basic rates would necessarily be better for this use. Basic rate set is just a common set of rates that can be used for broadcast/multicast since all stations in the BSS are known to support them. The EAPOL frames here are sent as unicast frames. > We've got a nice little helper in mac80211 (rate_control_send_low) that > allows the rc algorithm to check if a frame should be sent at a low rate. > I thought I'd hook in there and just check skb->protocol to force EAPOL > frames to the lowest rate. However, this didn't work out because in AP > mode the EAPOL frames are injected through a monitor interface and as > such skb->protocol is never initialized (ieee80211_monitor_start_xmit). Some EAPOL frames can be quite large (e.g., EAP-TLS). Forcing those to go out at 1 Mbps on a congested 2.4 GHz band channel sounds like a bad idea in general if the stations would be able to use HT rates at the time.. -- 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
