From: Christian Lamparter <chunkeey@googlemail.com>
To: hostap@lists.shmoo.com
Cc: Igor Perminov <igor.perminov@inbox.ru>,
Johannes Berg <johannes@sipsolutions.net>,
Jouni Malinen <j@w1.fi>,
linux-wireless@vger.kernel.org,
Artur Skawina <art.08.09@gmail.com>
Subject: Re: A station can't reconnect after it wakes up
Date: Sun, 13 Sep 2009 02:24:43 +0200 [thread overview]
Message-ID: <200909130224.43258.chunkeey@googlemail.com> (raw)
In-Reply-To: <1252799481.26765.145.camel@sunlight>
On Sunday 13 September 2009 01:51:21 Igor Perminov wrote:
> 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?
well, you can take a look right here: (comment)
net/mac80211/rx.c - ieee80211_rx_h_sta_process
/*
* Change STA power saving mode only at the end of a frame
* exchange sequence.
*/
if (!ieee80211_has_morefrags(hdr->frame_control) &&
(rx->sdata->vif.type == NL80211_IFTYPE_AP ||
rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN)) {
if (test_sta_flags(sta, WLAN_STA_PS)) {
/*
* Ignore doze->wake transitions that are
* indicated by non-data frames, the standard
* is unclear here, but for example going to
* PS mode and then scanning would cause a
* doze->wake transition for the probe request,
* and that is clearly undesirable.
*/
--- from here ---
if (ieee80211_is_data(hdr->frame_control) &&
!ieee80211_has_pm(hdr->frame_control))
rx->sent_ps_buffered += ap_sta_ps_end(sta);
--- to here ---
} else {
if (ieee80211_has_pm(hdr->frame_control))
ap_sta_ps_start(sta);
}
}
to trigger for (de-)auth/(de/re)assoc too in order to reset the PS state.
Regards,
Chr
next prev parent reply other threads:[~2009-09-13 0: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 [this message]
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=200909130224.43258.chunkeey@googlemail.com \
--to=chunkeey@googlemail.com \
--cc=art.08.09@gmail.com \
--cc=hostap@lists.shmoo.com \
--cc=igor.perminov@inbox.ru \
--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).