All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.