All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Hartmann <andihartmann@01019freenet.de>
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
Date: Fri, 29 Jul 2011 17:52:40 +0200	[thread overview]
Message-ID: <4E32D748.8050804@01019freenet.de> (raw)
In-Reply-To: <CAD2nsn33W8YxjROieEVgyX5N0Ypb9xO8m-H8yZ2pNO=DapxZGQ@mail.gmail.com>

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

  reply	other threads:[~2011-07-29 15:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-29  9:14 mac80211 + hostapd: EAPOL frames rate selection Helmut Schaa
2011-07-29 10:20 ` Mohammed Shafi
2011-07-29 15:17   ` Mohammed Shafi
2011-07-29 15:52     ` Andreas Hartmann [this message]
2011-07-29 17:37 ` Jouni Malinen
2011-07-29 17:55   ` Helmut Schaa
2011-07-29 18:05     ` Felix Fietkau
2012-12-17 17:26       ` Paul Stewart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E32D748.8050804@01019freenet.de \
    --to=andihartmann@01019freenet.de \
    --cc=helmut.schaa@googlemail.com \
    --cc=hostap@lists.shmoo.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=shafi.wireless@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.