Re: mac80211 + hostapd: EAPOL frames rate selection

[Jouni Malinen <j@w1.fi>]

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