linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Igor Perminov <igor.perminov@inbox.ru>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org, hostap@lists.shmoo.com,
	Jouni Malinen <j@w1.fi>, Artur Skawina <art.08.09@gmail.com>
Subject: Re: A station can't reconnect after it wakes up
Date: Sun, 13 Sep 2009 03:51:21 +0400	[thread overview]
Message-ID: <1252799481.26765.145.camel@sunlight> (raw)
In-Reply-To: <1252767513.23427.26.camel@johannes.local>

On Sat, 2009-09-12 at 08:58 -0600, Johannes Berg wrote:
> On Fri, 2009-09-11 at 02:03 +0400, Igor Perminov wrote:
> 
> > Jouni suggests to not buffer Auth/Assoc frames at all, independently of
> > station's PS state. 
> 
> Ok, works for me.
> 
> > I think, it isn't enough, because an AP should send
> > a number of EAPOL Key frames after that, which are data frames and
> > therefore will be buffered anyway.
> 
> That's not a problem though since the handshake will be in data frames
> and synchronise the PS state on both ends via the sleep bit.
> 
> > I think mac80211 in AP mode should reset WLAN_STA_PS flag of the station
> > (and purge frames having been buffered previously if any) on an event
> > indicating beginning of authentication.
> > The event may be one of the following:
> > A) An Auth frame being received from the station.
> > B) An Auth frame being sent to the station.
> > C) A special API call from an application (hostapd), when it is
> > receiving an Auth frame from the station and is beginning
> > authentication/association.
> > 
> > Johannes, what do you think of these approaches?
> 
> I think this is not necessary. Just make sure that auth/assoc frames
> aren't buffered.

The handshake is begun by the AP, which considers the STA is in PS mode.
So, first EAPOL Key frame is buffered already.
The AP informs the STA by TIM after that of course. But I think, there
is no any guarantee that the STA analyzes TIM at this point, because the
STA considers itself not power-saving.

I've implemented transmitting Auth and Assoc Response frames without
buffering on current wireless-testing and got the following result with
my Windows Mobile 6 PDA as a STA.
The AP buffers first EAPOL Key frame, gets a timeout, tries to resend
the frame and buffers it again. Some time later the STA sends EAPOL
Start frame, which reports to the AP that the STA isn't sleeping. After
that reconnection succeeds.
Normally the PDA doesn't send EAPOL Start, and I have no idea, why it
does so when it doesn't receive a EAPOL Key frame in time.
And I can at least assume that the PDA ignores TIM at the handshake
stage.

Unfortunately, I can't test another STA implementation, because my
laptop under Ubuntu Linux sends a Disassoc frame before going down,
which prevents PS state misunderstanding.

I've nowhere found in 802.11-2007 document that a STA should send EAPOL
Start at the beginning of 4-way handshake. So, there is no any guarantee
that every STA implementation can synchronize its PS state with the AP.

And moreover, my ASUS WL-500GP access point (it works under Linux 2.4
and doesn't utilize hostapd) processes reconnection without manipulating
TIM and causing a STA to send EAPOL Start. Probably, it just reset its
internal PS state of the STA at the beginning of reconnection.

Would it be better to reset WLAN_STA_PS flag to get a more reliable
solution may be?

Igor



  reply	other threads:[~2009-09-13  0:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1248969930.29068.224.camel@sunlight>
2009-07-31 16:16 ` A station can't reconnect after it wakes up Artur Skawina
2009-08-03 15:22   ` Igor Perminov
2009-09-10 22:03     ` Igor Perminov
2009-09-12 14:58       ` Johannes Berg
2009-09-12 23:51         ` Igor Perminov [this message]
2009-09-13  0:24           ` Christian Lamparter
2009-09-13 14:14           ` Kalle Valo
2009-09-14 11:24             ` Igor Perminov
2009-09-14 12:31               ` Holger Schurig
2009-09-14 22:55                 ` Igor Perminov
2009-09-14 12:50               ` Jouni Malinen
2009-09-14 17:42                 ` Johannes Berg
2009-07-28 15:38 Igor Perminov

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=1252799481.26765.145.camel@sunlight \
    --to=igor.perminov@inbox.ru \
    --cc=art.08.09@gmail.com \
    --cc=hostap@lists.shmoo.com \
    --cc=j@w1.fi \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /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).