A station can't reconnect after it wakes up

A station can't reconnect after it wakes up

[Igor Perminov]

Dear colleagues,

I have an issue related to handling power-saving stations in mac80211
(AP mode) or may be to hostapd. A station can't reconnect after it wakes
up (see the link to the rt2x00 forum below, issue #4).

AP: Linux box with D-Link DWA-110 USB Wi-Fi stick (rt73usb kernel
driver), kernel 2.6.30 with some patches, hostapd 0.6.9.
Station: Toshiba G900 PDA under Windows Mobile 6.0.

The environment is described in details here:
http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=5486&start=10

Consider the following step-by-step:
1. A station authenticates and associates with the AP and exchanges
traffic.
2. The station indicates to the AP that it is going to sleep.
3. The station device goes to the stand-by mode (not only its wi-fi
card, but the device itself).
4. The station device wakes up and begins authentication with an
Authentication management frame.
This is the behavior of my PDA.

The problem is the mac80211 stack remembers that the station has gone to
sleep. So, the response frames from hostapd are buffered by mac80211.
The station indicates in the Authentication frame that it isn't sleeping
anymore. But the mac80211 stack analyzes sleep/wake transitions in
_data_ frames only, but not in management ones. See
ieee80211_rx_h_sta_process in net/mac80211/rx.c. A comment there notes:
"Ignore doze->wake transitions that are indicated by non-data frames,
the standard is unclear here".
As the result, the station never receives the authentication response
from the AP.

The wireless-testing kernel seems to have this problem too.

As a workaround I've added a code in hostapd, which forces the mac80211
stack to "forget" the station just after receiving an authentication
frame. After this change the station can reconnect successfully.

And may be it would be better to analyze not only data frames, but also
some of management ones in ieee80211_rx_h_sta_process?
What does the standard tell here?

Best regards,
Igor Perminov

Re: A station can't reconnect after it wakes up

[Artur Skawina]

[linux-wireless added to cc list]

Igor Perminov wrote:
> I have an issue related to handling power-saving stations by hostapd
> and/or mac80211 stack. A station can't reconnect after it wakes up.
> 
> The problems looks similar to another one having been reported to this
> list earlier (STA can connect, but fails to reconnect within
> ap_max_inactivity):
> http://lists.shmoo.com/pipermail/hostap/2009-February/019192.html
> 
> AP: Linux box with D-Link DWA-110 USB Wi-Fi stick (rt73usb kernel
> driver), kernel 2.6.30 with some patches, hostapd 0.6.9.
> Station: Toshiba G900 PDA under Windows Mobile 6.0.
> 
> The environment is described in details here:
> http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=5486&start=10
> 
> Consider the following step-by-step:
> 1. A station authenticates and associates with the AP and exchanges
> traffic.
> 2. The station indicates to the AP that it is going to sleep.
> 3. The station device goes to the stand-by mode (not only its wi-fi
> card, but the device itself).
> 4. The station device wakes up and begins authentication with an
> Authentication management frame.
> 
> This is the behavior of my PDA.
> 
> The problem is the mac80211 stack at the point 4 "remembers" that the
> station has gone to sleep. So, the response frames from hostapd are
> buffered by mac80211.
> The station indicates in the Authentication frame that it isn't sleeping
> anymore. But the mac80211 stack analyzes sleep/wake transitions in
> _data_ frames only, but not in management ones. See
> ieee80211_rx_h_sta_process in net/mac80211/rx.c. A comment there notes:
> "Ignore doze->wake transitions that are indicated by non-data frames,
> the standard is unclear here".
> As the result, the station never receives the authentication response
> from the AP.
> 
> One solution against this problem could be implemented in hostapd: to
> force the mac80211 stack to "forget" the station just after receiving an
> authentication frame (the patch is below). After this change the station
> can reconnect successfully.

i just did a quick test and your hostapd patch does indeed fix my problem
too (p54+hostapd with a winmobile device that couldn't reconnect after
turning the wifi module off and on). 

> Another solution (in theory) would be to improve the mac80211
> implementation: to analyze not only data frames, but also
> management ones (or may be just some kinds of them) in
> ieee80211_rx_h_sta_process.

would seem to make sense, but having not read the spec i have no idea
if that's the right answer; hence the linux-wireless cc...

> I've asked this question to the linux-wireless mailing list few days
> ago, but nobody has answered still:
> http://marc.info/?l=linux-wireless&m=124879549212741&w=2
> 
> And what is your opinion, what is a better way: should this problem be
> fixed in hostapd or in mac80211?
> 
> === Begin diff ===
> --- a/hostapd/ieee802_11.c	2009-06-29 14:21:59.000000000 +0400
> +++ b/hostapd/ieee802_11.c	2009-07-21 16:28:17.000000000 +0400
> @@ -583,6 +583,13 @@
>  		goto fail;
>  	}
>  
> +	res = hostapd_sta_remove(hapd, mgmt->sa);
> +	if (res) {
> +		wpa_printf(MSG_DEBUG, "authentication: STA=" MACSTR
> +				", hostapd_sta_remove returned %d\n",
> +				MAC2STR(mgmt->sa), res);
> +	}
> +
>  	if (vlan_id > 0) {
>  		if (hostapd_get_vlan_id_ifname(hapd->conf->vlan,
>  					       sta->vlan_id) == NULL) {
> === End diff ===

Thanks for the cc, added this to my local hostapd patch set, until the
issue gets resolved one way or another.

artur

Re: A station can't reconnect after it wakes up

[Igor Perminov]

On Fri, 31/07/2009 at 18:16 +0200, Artur Skawina wrote:
> [linux-wireless added to cc list]
> 
> Igor Perminov wrote:
> > I have an issue related to handling power-saving stations by hostapd
> > and/or mac80211 stack. A station can't reconnect after it wakes up.
> > 
> > The problems looks similar to another one having been reported to this
> > list earlier (STA can connect, but fails to reconnect within
> > ap_max_inactivity):
> > http://lists.shmoo.com/pipermail/hostap/2009-February/019192.html
> > 
> > AP: Linux box with D-Link DWA-110 USB Wi-Fi stick (rt73usb kernel
> > driver), kernel 2.6.30 with some patches, hostapd 0.6.9.
> > Station: Toshiba G900 PDA under Windows Mobile 6.0.
> > 
> > The environment is described in details here:
> > http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=5486&start=10
> > 
> > Consider the following step-by-step:
> > 1. A station authenticates and associates with the AP and exchanges
> > traffic.
> > 2. The station indicates to the AP that it is going to sleep.
> > 3. The station device goes to the stand-by mode (not only its wi-fi
> > card, but the device itself).
> > 4. The station device wakes up and begins authentication with an
> > Authentication management frame.
> > 
> > This is the behavior of my PDA.
> > 
> > The problem is the mac80211 stack at the point 4 "remembers" that the
> > station has gone to sleep. So, the response frames from hostapd are
> > buffered by mac80211.
> > The station indicates in the Authentication frame that it isn't sleeping
> > anymore. But the mac80211 stack analyzes sleep/wake transitions in
> > _data_ frames only, but not in management ones. See
> > ieee80211_rx_h_sta_process in net/mac80211/rx.c. A comment there notes:
> > "Ignore doze->wake transitions that are indicated by non-data frames,
> > the standard is unclear here".
> > As the result, the station never receives the authentication response
> > from the AP.
> > 
> > One solution against this problem could be implemented in hostapd: to
> > force the mac80211 stack to "forget" the station just after receiving an
> > authentication frame (the patch is below). After this change the station
> > can reconnect successfully.
> 
> i just did a quick test and your hostapd patch does indeed fix my problem
> too (p54+hostapd with a winmobile device that couldn't reconnect after
> turning the wifi module off and on). 
> 
> > Another solution (in theory) would be to improve the mac80211
> > implementation: to analyze not only data frames, but also
> > management ones (or may be just some kinds of them) in
> > ieee80211_rx_h_sta_process.
> 
> would seem to make sense, but having not read the spec i have no idea
> if that's the right answer; hence the linux-wireless cc...
> 
> > I've asked this question to the linux-wireless mailing list few days
> > ago, but nobody has answered still:
> > http://marc.info/?l=linux-wireless&m=124879549212741&w=2
> > 
> > And what is your opinion, what is a better way: should this problem be
> > fixed in hostapd or in mac80211?
> > 
> > === Begin diff ===
> > --- a/hostapd/ieee802_11.c	2009-06-29 14:21:59.000000000 +0400
> > +++ b/hostapd/ieee802_11.c	2009-07-21 16:28:17.000000000 +0400
> > @@ -583,6 +583,13 @@
> >  		goto fail;
> >  	}
> >  
> > +	res = hostapd_sta_remove(hapd, mgmt->sa);
> > +	if (res) {
> > +		wpa_printf(MSG_DEBUG, "authentication: STA=" MACSTR
> > +				", hostapd_sta_remove returned %d\n",
> > +				MAC2STR(mgmt->sa), res);
> > +	}
> > +
> >  	if (vlan_id > 0) {
> >  		if (hostapd_get_vlan_id_ifname(hapd->conf->vlan,
> >  					       sta->vlan_id) == NULL) {
> > === End diff ===
> 
> Thanks for the cc, added this to my local hostapd patch set, until the
> issue gets resolved one way or another.
> 
> artur

I've looked through the 802-11.2007 document and now I consider the
source of the problem is misunderstanding by an AP and a STA states of
each other. When the station tries to reconnect it considers itself
non-authenticated. Whereas the AP considers the station both
authenticated and associated.

I think it would be better to fix the problem in hostapd, because it's a
hostapd's responsibility - to manage the state of a station being known
to the AP. So, when hostapd receives an Auth frame from a station it
should consider the station being non-authenticated and force removing
the station from the underlying stack.

I'll submit a patch for hostapd in a nearest future.

Best regards,
Igor

Re: A station can't reconnect after it wakes up

[Igor Perminov]

On Mon, 03/08/2009 at 19:22:05 +0400, Igor Perminov wrote:
> On Fri, 31/07/2009 at 18:16 +0200, Artur Skawina wrote:
> [linux-wireless added to cc list]
> > 
> > Igor Perminov wrote:
> > > I have an issue related to handling power-saving stations by hostapd
> > > and/or mac80211 stack. A station can't reconnect after it wakes up.
> > > 
> > > The problems looks similar to another one having been reported to this
> > > list earlier (STA can connect, but fails to reconnect within
> > > ap_max_inactivity):
> > > http://lists.shmoo.com/pipermail/hostap/2009-February/019192.html
> > > 
> > > AP: Linux box with D-Link DWA-110 USB Wi-Fi stick (rt73usb kernel
> > > driver), kernel 2.6.30 with some patches, hostapd 0.6.9.
> > > Station: Toshiba G900 PDA under Windows Mobile 6.0.
> > > 
> > > The environment is described in details here:
> > > http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=5486&start=10
> > > 
> > > Consider the following step-by-step:
> > > 1. A station authenticates and associates with the AP and exchanges
> > > traffic.
> > > 2. The station indicates to the AP that it is going to sleep.
> > > 3. The station device goes to the stand-by mode (not only its wi-fi
> > > card, but the device itself).
> > > 4. The station device wakes up and begins authentication with an
> > > Authentication management frame.
> > > 
> > > This is the behavior of my PDA.
> > > 
> > > The problem is the mac80211 stack at the point 4 "remembers" that the
> > > station has gone to sleep. So, the response frames from hostapd are
> > > buffered by mac80211.
> > > The station indicates in the Authentication frame that it isn't sleeping
> > > anymore. But the mac80211 stack analyzes sleep/wake transitions in
> > > _data_ frames only, but not in management ones. See
> > > ieee80211_rx_h_sta_process in net/mac80211/rx.c. A comment there notes:
> > > "Ignore doze->wake transitions that are indicated by non-data frames,
> > > the standard is unclear here".
> > > As the result, the station never receives the authentication response
> > > from the AP.
> > > 
> > > One solution against this problem could be implemented in hostapd: to
> > > force the mac80211 stack to "forget" the station just after receiving an
> > > authentication frame (the patch is below). After this change the station
> > > can reconnect successfully.
> > 
> > i just did a quick test and your hostapd patch does indeed fix my problem
> > too (p54+hostapd with a winmobile device that couldn't reconnect after
> > turning the wifi module off and on). 
> > 
> > > Another solution (in theory) would be to improve the mac80211
> > > implementation: to analyze not only data frames, but also
> > > management ones (or may be just some kinds of them) in
> > > ieee80211_rx_h_sta_process.
> > 
> > would seem to make sense, but having not read the spec i have no idea
> > if that's the right answer; hence the linux-wireless cc...
> > 
> > > I've asked this question to the linux-wireless mailing list few days
> > > ago, but nobody has answered still:
> > > http://marc.info/?l=linux-wireless&m=124879549212741&w=2
> > > 
> > > And what is your opinion, what is a better way: should this problem be
> > > fixed in hostapd or in mac80211?
> > > 
> > > === Begin diff ===
> > > --- a/hostapd/ieee802_11.c	2009-06-29 14:21:59.000000000 +0400
> > > +++ b/hostapd/ieee802_11.c	2009-07-21 16:28:17.000000000 +0400
> > > @@ -583,6 +583,13 @@
> > >  		goto fail;
> > >  	}
> > >  
> > > +	res = hostapd_sta_remove(hapd, mgmt->sa);
> > > +	if (res) {
> > > +		wpa_printf(MSG_DEBUG, "authentication: STA=" MACSTR
> > > +				", hostapd_sta_remove returned %d\n",
> > > +				MAC2STR(mgmt->sa), res);
> > > +	}
> > > +
> > >  	if (vlan_id > 0) {
> > >  		if (hostapd_get_vlan_id_ifname(hapd->conf->vlan,
> > >  					       sta->vlan_id) == NULL) {
> > > === End diff ===
> > 
> > Thanks for the cc, added this to my local hostapd patch set, until the
> > issue gets resolved one way or another.
> > 
> > artur
> 
> I've looked through the 802-11.2007 document and now I consider the
> source of the problem is misunderstanding by an AP and a STA states of
> each other. When the station tries to reconnect it considers itself
> non-authenticated. Whereas the AP considers the station both
> authenticated and associated.
> 
> I think it would be better to fix the problem in hostapd, because it's a
> hostapd's responsibility - to manage the state of a station being known
> to the AP. So, when hostapd receives an Auth frame from a station it
> should consider the station being non-authenticated and force removing
> the station from the underlying stack.
> 
> I'll submit a patch for hostapd in a nearest future.
> 
> Best regards,
> Igor

Hi,

I've submitted the hostapd patch mentioned above to the hostap mailing
list and have got a comment from Jouni Malinen (I haven't received a
e-mail from Jouni for an odd reason and have found his reply in the
mailing list archive by accident just now).

Remember, the patch forces mac80211 to "forget" the station just after
receiving an authentication frame. Jouni's comment can be found here:
http://lists.shmoo.com/pipermail/hostap/2009-August/020083.html
In general, Jouni has rejected the patch, because such "forgetting"
should not be done in number of cases (e.g., 802.11r).
So, the only place to recover from "misunderstanding" station's state is
mac80211.

Jouni suggests to not buffer Auth/Assoc frames at all, independently of
station's PS state. 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.

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?

Regards,
Igor

Re: A station can't reconnect after it wakes up

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]

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.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: A station can't reconnect after it wakes up

[Igor Perminov]

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

Re: A station can't reconnect after it wakes up

[Christian Lamparter]

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 

Re: A station can't reconnect after it wakes up

[Kalle Valo]

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?


[...]

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

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.

> 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?

So mac80211 doesn't clear STA's power save state during association? To
me that sounds like a bug.

-- 
Kalle Valo

Re: A station can't reconnect after it wakes up

[Igor Perminov]

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

Re: A station can't reconnect after it wakes up

[Holger Schurig]

> 4. The STA device wakes up and begins 
> authentication with an Auth frame as it hasn't been
> authenticated/associated previously.

What's the status of the PS bit of this Auth Frame?

Does the station here send a NULL func packet with the "I'm under 
power again" bit?   It might be necessary to do this via a 
null-func packet towards some broken APs.

-- 
http://www.holgerschurig.de

Re: A station can't reconnect after it wakes up

[Igor Perminov]

On Mon, 2009-09-14 at 14:31 +0200, Holger Schurig wrote:
> > 4. The STA device wakes up and begins 
> > authentication with an Auth frame as it hasn't been
> > authenticated/associated previously.
> 
> What's the status of the PS bit of this Auth Frame?

The PS bit of the Auth frame indicates that the STA is under power.
And mac80211 checks the PS bit in data frames only, but not in
management ones.

> Does the station here send a NULL func packet with the "I'm under 
> power again" bit?   It might be necessary to do this via a 
> null-func packet towards some broken APs.

No, it doesn't send. The station works under Windows Mobile 6, and I
can't change its implementation. Contrary, I'm working on making a
Linux/hostapd AP non-broken.

Igor

Re: A station can't reconnect after it wakes up

[Jouni Malinen]

On Mon, Sep 14, 2009 at 03:24:32PM +0400, Igor Perminov wrote:

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

and drops the association state without sending disassociation frame..

> 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 authentication and association frames should work fine even in this
case since they should not be buffered.

> The only inconsistency of the STA implementation may be at the step 3 -
> it doesn't send a Disassoc frame before disconnecting.

Which it is free to do. Likewise, the STA would be free to send a data
nullfunc frame with PwrMgt field set to 0 immediately after association
to clear the PS state.

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

This is somewhat unclear.. Based on the current P802.11REVmb_D1.01, the
authentication or association frame exchange itself would not clear the
PS state at least as far as the use of PwrMgt field in the frame control
field is concerned. Furthermore, there is still discussion on how
exactly the authentication/association state changes in case of this
type of reassociation back to the same AP.

I think it would be a fair design to drop the power save buffered frames
and PS state information on disassociation or in general, when on the
AP, the STA State changes from 3 to 2 or 1. However, it is not clear
whether that happens in this particular case.

Taken into account that the AP can even change the Association ID for
the STA during reassociation, I would be fine with dropping the buffered
frames and clearing the PS state when association is completed
successfully (the STA ACKs the (Re)Association Response frame that had
status code 0). I would hope that the authentication frame sequence or
failed (re)association would not touch the PS buffer or state.

The real time when the association state changes in the AP is when the
ACK frame is received for (Re)Association Response frame. Of the options
you listed, this would be bit after (B), i.e., (C) might be needed to
get the exact timing right. However, I could probably live with (B),
too, in practice.

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

This is a very good point and we much indeed make sure we do not end up
sending the buffered frames out based on a new authentication or
association frame. This is especially important for the case when the
frames were buffered in RSNA, i.e., they were to be encrypted. During
association, there is no encryption keys available (well, apart from
802.11r FT protocol case when they are ready immediately after
association). However, if everything goes through fine, this may already
be protected by the IEEE 802.1X controlled port, i.e., the frames would
be dropped here if the new authentication has not been completed (but I
have not verified whether this is indeed the case in the current
implementation).

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: A station can't reconnect after it wakes up

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

On Mon, 2009-09-14 at 15:50 +0300, Jouni Malinen wrote:

> Taken into account that the AP can even change the Association ID for
> the STA during reassociation, I would be fine with dropping the buffered
> frames and clearing the PS state when association is completed
> successfully (the STA ACKs the (Re)Association Response frame that had
> status code 0). I would hope that the authentication frame sequence or
> failed (re)association would not touch the PS buffer or state.
> 
> The real time when the association state changes in the AP is when the
> ACK frame is received for (Re)Association Response frame. Of the options
> you listed, this would be bit after (B), i.e., (C) might be needed to
> get the exact timing right. However, I could probably live with (B),
> too, in practice.



> > 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.
> 
> This is a very good point and we much indeed make sure we do not end up
> sending the buffered frames out based on a new authentication or
> association frame. This is especially important for the case when the
> frames were buffered in RSNA,

Given all this, I still think it would be a lot simpler to just have
hostapd remove the station once.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]