Return-path: Received: from mail-gw0-f46.google.com ([74.125.83.46]:49525 "EHLO mail-gw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751797Ab1G2RzF (ORCPT ); Fri, 29 Jul 2011 13:55:05 -0400 Received: by gwaa12 with SMTP id a12so656589gwa.19 for ; Fri, 29 Jul 2011 10:55:04 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110729173754.GC3418@jm.kir.nu> References: <20110729173754.GC3418@jm.kir.nu> Date: Fri, 29 Jul 2011 19:55:04 +0200 Message-ID: (sfid-20110729_195510_005292_87854D07) Subject: Re: mac80211 + hostapd: EAPOL frames rate selection From: Helmut Schaa To: Helmut Schaa , linux-wireless , hostap@lists.shmoo.com Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: 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. > 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.. Good point. Helmut