linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 

  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).