From: Andreas Hartmann <andihartmann@01019freenet.de>
To: Christian Lamparter <chunkeey@googlemail.com>
Cc: Jouni Malinen <j@w1.fi>,
Helmut Schaa <helmut.schaa@googlemail.com>,
John Linville <linville@tuxdriver.com>,
linux-wireless@vger.kernel.org,
Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [PATCH 2/2] mac80211: Always send EAPOL frames at lowest rate
Date: Sun, 31 Jul 2011 09:13:25 +0200 [thread overview]
Message-ID: <4E350095.5050002@01019freenet.de> (raw)
In-Reply-To: <201107302232.28582.chunkeey@googlemail.com>
Christian Lamparter schrieb:
> On Saturday 30 July 2011 22:03:34 Andreas Hartmann wrote:
>> Jouni Malinen schrieb:
>>> On Fri, Jul 29, 2011 at 07:22:17PM +0200, Helmut Schaa wrote:
>>>> Since EAPOL frames are normal data frames they are treated by the
>>>> rate control algorithm as such. Thus it can happen that the rate
>>>> control algorithm chooses an inappropriate rate (minstrel_ht uses
>>>> MCS rates for example) for the 4-way handshake and under low signal
>>>> conditions the handshake may time out.
>>>>
>>>> To fix this issue always treat EAPOL frames the same as management
>>>> frames and send them with the lowest available rate.
>>>
>>> I don't think that this should be applied for the reasons given (and
>>> alternative mechanisms proposed) in the discussion.
>>
>> I tested it with AP (rt2860) (with STA rt3572sta) under load and
>> couldn't see any improvement. The first PTK-rekeying didn't work as
>> usual. Or should it be applied to STA?
>
> might be a shot into the dark. But who's assigning a proper frame sequence
> to each eapol? Hostapd certainly can't because it doesn't know what's the
> current sequence at the moment... and mac80211 won't assign one because
> the frame is injected by a monitor interface. So when the receiver gets the
> EAPOL it might drops it because the empty sequence might be not in the
> BA window anymore. Does this sound reasonable, or did I miss something?
Meanwhile I tested with the patch on both sides, AP (rt2800pci / rt2860)
and STA (ath9k / ar9582) and compat-wireless-2011-07-28. The result is
unchanged the same: the first ptk rekeying (4 way handshake) just didn't
work.
Another thing: I don't think, that the wireless modules are the reason
of the problem. If I'm using the following test setup, I get no problem
at all:
AP: (rt2800pci / rt2860 - without patch)
STA: (rt3572 / rt3572sta - used without wpa_supplicant, but just
rt3572sta stack - rt3572sta ships with an own WPA2-PSK-stack)
-> Why is it working without any problems, if wpa_supplicant isn't used
at all?
Andreas
next prev parent reply other threads:[~2011-07-31 7:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-29 17:22 [PATCH 1/2] mac80211: Fill in skb->protocol information for injected frames Helmut Schaa
2011-07-29 17:22 ` [PATCH 2/2] mac80211: Always send EAPOL frames at lowest rate Helmut Schaa
2011-07-29 17:51 ` Felix Fietkau
2011-07-29 17:56 ` Helmut Schaa
2011-07-29 18:00 ` Helmut Schaa
2011-07-29 18:05 ` Felix Fietkau
2011-07-29 18:10 ` Helmut Schaa
2011-07-30 18:28 ` Jouni Malinen
2011-07-30 20:03 ` Andreas Hartmann
2011-07-30 20:32 ` Christian Lamparter
2011-07-31 7:13 ` Andreas Hartmann [this message]
2011-07-31 9:30 ` Helmut Schaa
2011-07-31 9:26 ` Helmut Schaa
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=4E350095.5050002@01019freenet.de \
--to=andihartmann@01019freenet.de \
--cc=chunkeey@googlemail.com \
--cc=helmut.schaa@googlemail.com \
--cc=j@w1.fi \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.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.