[PATCH] mac80211: Send EAPOL frames at lowest rate

[PATCH] mac80211: Send EAPOL frames at lowest rate

[Jouni Malinen]

The current minstrel_ht rate control behavior is somewhat optimistic in
trying to find optimum TX rate. While this is usually fine for normal
Data frames, there are cases where a more conservative set of retry
parameters would be beneficial to make the connection more robust.

EAPOL frames are critical to the authentication and especially the
EAPOL-Key message 4/4 (the last message in the 4-way handshake) is
important to get through to the AP. If that message is lost, the only
recovery mechanism in many cases is to reassociate with the AP and start
from scratch. This can often be avoided by trying to send the frame with
more conservative rate and/or with more link layer retries.

In most cases, minstrel_ht is currently using the initial EAPOL-Key
frames for probing higher rates and this results in only five link layer
transmission attempts (one at high(ish) MCS and four at MCS0). While
this works with most APs, it looks like there are some deployed APs that
may have issues with the EAPOL frames using HT MCS immediately after
association. Similarly, there may be issues in cases where the signal
strength or radio environment is not good enough to be able to get
frames through even at couple of MCS 0 tries.

The best approach for this would likely to be to reduce the TX rate for
the last rate (3rd rate parameter in the set) to a low basic rate (say,
6 Mbps on 5 GHz and 2 or 5.5 Mbps on 2.4 GHz), but doing that cleanly
requires some more effort. For now, we can start with a simple one-liner
that forces the minimum rate to be used for EAPOL frames similarly how
the TX rate is selected for the IEEE 802.11 Management frames. This does
result in a small extra latency added to the cases where the AP would be
able to receive the higher rate, but taken into account how small number
of EAPOL frames are used, this is likely to be insignificant. A future
optimization in the minstrel_ht design can also allow this patch to be
reverted to get back to the more optimized initial TX rate.

It should also be noted that many drivers that do not use minstrel as
the rate control algorithm are already doing similar workarounds by
forcing the lowest TX rate to be used for EAPOL frames.

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
 net/mac80211/tx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index af5446c..14ff5e4 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -565,6 +565,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;
-- 
1.9.1

Re: [PATCH] mac80211: Send EAPOL frames at lowest rate

[Linus Torvalds]

Johannes,

On Thu, Feb 26, 2015 at 5:50 AM, Jouni Malinen <jouni@qca.qualcomm.com> wrote:
>
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>

Also "Tested-by:", and I'd suggest marking it for stable too (although
I understand that David generally doesn't use stable tags, and just
sends them separately to the stable tree).

This fixes both Atheros and brcmsmac for me (with Ubiquiti UniFi APs).

My main laptop is iwlwifi, and the only reason that worked is
apparently that the iwlwifi driver already basically does something
similar on its own.

All the other devices I have apparently don't use the 802.11 code even
if they are Linux-based (ie mostly android, and presumably they use
some vendor driver rather than the minstrel rate-handling code).

                         Linus

Re: [PATCH] mac80211: Send EAPOL frames at lowest rate

[Johannes Berg]

Linus, Jouni, all,

Thanks everyone. I've applied this patch to my mac80211 tree - I'll send
it out to davem tomorrow I think.

Jouni, given that hwsim uses minstrel as well, perhaps we could have a
test case in the wpa_supplicant tests in some way that checks this? I'm
thinking we could hook into the AP and remove it from the radio group
right after sending 3/4, so that 4/4 would get retransmitted? I don't
actually know though if hwsim really honours all the rate stuff,
something to look into perhaps.

> Also "Tested-by:", and I'd suggest marking it for stable too (although
> I understand that David generally doesn't use stable tags, and just
> sends them separately to the stable tree).

Done - and yeah, he does that, but I add stable tags anyway since I
don't want to track it down later. So far he hasn't complained :-)

> My main laptop is iwlwifi, and the only reason that worked is
> apparently that the iwlwifi driver already basically does something
> similar on its own.

Yes, and it also starts out at a lower rate.

> All the other devices I have apparently don't use the 802.11 code even
> if they are Linux-based (ie mostly android, and presumably they use
> some vendor driver rather than the minstrel rate-handling code).

Indeed, very few of them do. The only ones I'm aware of are (fairly old)
phones using the TI wifi chip - my Motorola razr i for example actually
runs mac80211. However, it also doesn't use minstrel, so I guess you
won't find a phone using this :-)

johannes

Re: [PATCH] mac80211: Send EAPOL frames at lowest rate

[John Lempkowski]

Jouni Malinen <jouni@...> writes:

> In most cases, minstrel_ht is currently using the initial EAPOL-Key
> frames for probing higher rates and this results in only five link layer
> transmission attempts (one at high(ish) MCS and four at MCS0). While
> this works with most APs, it looks like there are some deployed APs that
> may have issues with the EAPOL frames using HT MCS immediately after
> association. Similarly, there may be issues in cases where the signal
> strength or radio environment is not good enough to be able to get
> frames through even at couple of MCS 0 tries.

This sounds similar to a problem I discovered while hacking on older
software. EAPOL frames were being dropped at a higher rate than were UDP
frames of any size, but only when there was other traffic. Eventually I
proved that most EAPOL frames in my test setup were actually received by
ath9k, but mac80211 did not always pass them up the stack. It turned out
that hostapd and/or wpa_supplicant were getting the EAPOL frames if and only
if they were not the 2nd or later subframe in an A-MPDU. If this has since
been discovered and fixed upstream, I apologize for the noise.

I spent a couple days trying to find a breakage mac80211's rx handlers which
were definitely getting the disappearing EAPOL packets. Eventually I gave up
and hacked the ath9k transmit routine so it breaks from the aggregation
logic and form a new A-MPDU whenever it encounters an EAPOL frame. This
worked around the auth+reauth issues that caused me to investigate.

The software exhibiting this behavior is a hacked OpenWrt checkout using the
following base versions:

Linux version 3.10.21
Compat-wireless 2013-04-16
Hostapd 2.1-devel
    PKG_VERSION:=20130807
    PKG_REV:=d2ba3d6bd9336ef8fd761a0cc7999824d4c4da41)

> It should also be noted that many drivers that do not use minstrel as
> the rate control algorithm are already doing similar workarounds by
> forcing the lowest TX rate to be used for EAPOL frames.

Perhaps this workaround avoids MPDU aggregation in all those drivers as well.

-John