Message-ID: <4E32D748.8050804@01019freenet.de> (sfid-20110729_175114_756160_803C8019)
Date: Fri, 29 Jul 2011 17:52:40 +0200
From: Andreas Hartmann <andihartmann@01019freenet.de>
MIME-Version: 1.0
To: Mohammed Shafi <shafi.wireless@gmail.com>
CC: Helmut Schaa <helmut.schaa@googlemail.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	hostap@lists.shmoo.com
Subject: Re: mac80211 + hostapd: EAPOL frames rate selection
References: <CAGXE3d9gX0LQjHiYB6vpD8AvfdrwOr5DZs=sGxZzHYW5RSZHsQ@mail.gmail.com> <CAD2nsn1KzOkZ1r9ekoSJOwZNACeOqv7i83uDygMbC6u4Hx5yqA@mail.gmail.com> <CAD2nsn33W8YxjROieEVgyX5N0Ypb9xO8m-H8yZ2pNO=DapxZGQ@mail.gmail.com>
In-Reply-To: <CAD2nsn33W8YxjROieEVgyX5N0Ypb9xO8m-H8yZ2pNO=DapxZGQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Sender: linux-wireless-owner@vger.kernel.org

Mohammed Shafi schrieb:
> On Fri, Jul 29, 2011 at 3:50 PM, Mohammed Shafi
> <shafi.wireless@gmail.com> wrote:
>> 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 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.

Well, that's what I always can see, too: the supplicant get's the 3/4
packet and says, it would be ok, after it send the 4/4 packet. But I
can't say, if this packet really ever gets send out or if hostapd just
doesn't see it even though it was send. Fact is: hostapd reports the 4/4
packet as missing and breaks the connection after the defined number of
retries.

Besides that, I see this problem always under middle or high load,
seldom (or never?) on low load or during idle state.


Andreas