Return-path: Received: from nbd.name ([46.4.11.11]:42083 "EHLO nbd.name" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752476Ab1G2SFU (ORCPT ); Fri, 29 Jul 2011 14:05:20 -0400 Message-ID: <4E32F65D.6030703@openwrt.org> (sfid-20110729_200524_287041_C868F027) Date: Fri, 29 Jul 2011 20:05:17 +0200 From: Felix Fietkau MIME-Version: 1.0 To: Helmut Schaa CC: linux-wireless , hostap@lists.shmoo.com Subject: Re: mac80211 + hostapd: EAPOL frames rate selection References: <20110729173754.GC3418@jm.kir.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: On 2011-07-29 7:55 PM, Helmut Schaa wrote: > On Fri, Jul 29, 2011 at 7:37 PM, Jouni Malinen wrote: >> 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.. > > True. Nevertheless other drivers like madwifi or the ralink legacy drivers also > force EAPOL frames to a low rate. That's why I had the idea in the first place. I think this mainly occurs on devices/drivers that use minstrel_ht, but lack proper multi-rate retry. minstrel_ht may pick a high rate for probing and on devices with a simple fallback table (e.g. rt2x00), it may give up on the frame before having tried a low enough rate. On ath9k this shouldn't be an issue with minstrel_ht, because it always keeps the max_prob_rate in a retry slot. - Felix