Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:46568 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751358Ab1G2PRD convert rfc822-to-8bit (ORCPT ); Fri, 29 Jul 2011 11:17:03 -0400 Received: by wyg8 with SMTP id 8so253578wyg.19 for ; Fri, 29 Jul 2011 08:17:02 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 29 Jul 2011 20:47:02 +0530 Message-ID: (sfid-20110729_171708_245341_8961E1FF) Subject: Re: mac80211 + hostapd: EAPOL frames rate selection From: Mohammed Shafi To: Helmut Schaa Cc: 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 3:50 PM, Mohammed Shafi wrote: > On Fri, Jul 29, 2011 at 2:44 PM, Helmut Schaa > wrote: >> Hi, >> > Hi Helmut, > >> 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. > > I am occasionally seeing this issue in ath9k Station under ?heavy > traffic conditions > and low signal(only when I the distance between STA and AP is very > much significant), > some times I could no recreate the issue. I use ath9k-rate control and > I still found that the > EAPOL frames are being sent at lower rate. > with the sniffer capture there are lot of retries for 2nd message. > the timeout comes after 2nd message I might have missed out. looking back at one of the sniffer capture it seems the AP(very reliable one) is sending EAPOL to my STA at 1Mbps while the STA does not seems to be sending at legacy rate. > >> >> 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. let me try I can send it in lower rate and fixes the issue. >> >> 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). >> >> The injected frames however already have an 802.11 header and therefore >> figuring out the ethertype of the injected frame is not as straightforward as >> I liked it to be :( >> >> Can I always be sure that an injected data frame (!=nullfunc) has a rfc1042 >> header following after the 802.11 header? >> >> Another option would be to let hostapd specify a fixed tx rate in the radiotap >> header (and extend mac80211 to understand it). However, since some drivers >> also make use of skb->protocol (to forbid aggregation for example) it sounds >> more sane to initialize it also for injected frames. > > in ath9k Raj pointed out that we are not doing aggregation if the > frame is of EAPOL, I can > check if I am missing something. > > >> >> Any other ideas? >> >> Thanks, >> Helmut >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at ?http://vger.kernel.org/majordomo-info.html >> > > > > -- > shafi > -- shafi