From: Christian Lamparter <chunkeey@googlemail.com>
To: Andreas Hartmann <andihartmann@01019freenet.de>
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: Sat, 30 Jul 2011 22:32:27 +0200 [thread overview]
Message-ID: <201107302232.28582.chunkeey@googlemail.com> (raw)
In-Reply-To: <4E346396.9030707@01019freenet.de>
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?
Regards,
Chr
next prev parent reply other threads:[~2011-07-30 20:29 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 [this message]
2011-07-31 7:13 ` Andreas Hartmann
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=201107302232.28582.chunkeey@googlemail.com \
--to=chunkeey@googlemail.com \
--cc=andihartmann@01019freenet.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).