MIME-Version: 1.0
In-Reply-To: <CAGXE3d9gX0LQjHiYB6vpD8AvfdrwOr5DZs=sGxZzHYW5RSZHsQ@mail.gmail.com>
References: <CAGXE3d9gX0LQjHiYB6vpD8AvfdrwOr5DZs=sGxZzHYW5RSZHsQ@mail.gmail.com>
Date: Fri, 29 Jul 2011 15:50:21 +0530
Message-ID: <CAD2nsn1KzOkZ1r9ekoSJOwZNACeOqv7i83uDygMbC6u4Hx5yqA@mail.gmail.com> (sfid-20110729_122029_715663_CB10B893)
Subject: Re: mac80211 + hostapd: EAPOL frames rate selection
From: Mohammed Shafi <shafi.wireless@gmail.com>
To: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
	hostap@lists.shmoo.com
Content-Type: text/plain; charset=ISO-8859-1
Sender: linux-wireless-owner@vger.kernel.org

On Fri, Jul 29, 2011 at 2:44 PM, Helmut Schaa
<helmut.schaa@googlemail.com> 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 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.
>
> 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