linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Igor Perminov <igor.perminov@inbox.ru>
To: Kalle Valo <kalle.valo@iki.fi>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	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: Mon, 14 Sep 2009 15:24:32 +0400	[thread overview]
Message-ID: <1252927472.26765.202.camel@sunlight> (raw)
In-Reply-To: <87my4z0w53.fsf@litku.valot.fi>

On Sun, 2009-09-13 at 17:14 +0300, Kalle Valo wrote:
> Igor Perminov <igor.perminov@inbox.ru> writes:
> 
> > On Sat, 2009-09-12 at 08:58 -0600, Johannes Berg wrote:
> >
> >> 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.
> 
> If this happens then the STA has really broken power save
> implementation. If a STA informs AP about going to power save it should
> _immediately_ start checking the TIM bits. Or is it so that STA actually
> hasn't informed AP about power save after association?

A step-by-step, which causes the issue, is:
1. A STA authenticates and associates with the AP and exchanges
traffic.
2. The STA reports to the AP that it is going to PS state.
3. Some time later (but before max_inactivity) the STA device goes to
the stand-by mode (not only its wi-fi card, but the device itself).
4. The STA device wakes up and begins authentication with an
Auth frame as it hasn't been authenticated/associated previously.

At the step 4 the AP "remembers" the STA and considers it is in the PS
state, so the AP buffers frames, which it has to send to the STA.
But the STA isn't actually in the PS state and so it doesn't check the
TIM bits.

The only inconsistency of the STA implementation may be at the step 3 -
it doesn't send a Disassoc frame before disconnecting.
But it doesn't lead to any issue with an ASUS "production" access point.

> My understanding is that the power save state after association should
> be disabled until STA informs otherwise. So there shouldn't be any
> synchronisation issues.
> 
> So mac80211 doesn't clear STA's power save state during association? To
> me that sounds like a bug.

Yes, mac80211 "remembers" STA's power save state.
And my question is - what an event should trigger clearing PS state:
A) An Auth/Assoc frame being received from the STA.
B) An Auth/Assoc Resp frame being sent to the STA.
C) A special API call from an application (hostapd).
D) Something else, may be.

The choice A can be easily implemented. It can be done in
ieee80211_rx_h_sta_process, as Christian Lamparter has written.
But I think, we shouldn't call ap_sta_ps_end as is done for normal PS
state switching, because that leads to sending buffered frames if any,
which is undesirable in our case. Instead, we should simply purge of
buffered frames and clear WLAN_STA_PS.

If nobody objects, I'll prepare an RFC patch.

Igor



  reply	other threads:[~2009-09-14 11:24 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
2009-09-13  0:24           ` Christian Lamparter
2009-09-13 14:14           ` Kalle Valo
2009-09-14 11:24             ` Igor Perminov [this message]
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=1252927472.26765.202.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=kalle.valo@iki.fi \
    --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).