A station can't reconnect after it wakes up

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.

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.

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

hostapd/ieee802_11.c +7 -0

@@ -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 ===

[linux-wireless added to cc list]

Quoted 38 lines · Igor Perminov

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.

Quoted 4 lines

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

Quoted 4 lines

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

Quoted 24 lines

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

hostapd/ieee802_11.c +7 -0

@@ -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) {

Quoted 1 line

=== End diff ===

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

artur

On Fri, 31/07/2009 at 18:16 +0200, Artur Skawina wrote:
[linux-wireless added to cc list]

Quoted 86 lines

Quoted 38 lines · Igor Perminov

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.

Quoted 4 lines

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

Quoted 4 lines

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

Quoted 24 lines

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

hostapd/ieee802_11.c +7 -0

@@ -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) {

Quoted 1 line

=== End diff ===

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

Quoted 1 line

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

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?

Quoted 2 lines · Igor Perminov

Jouni suggests to not buffer Auth/Assoc frames at all, independently of station's PS state.

Ok, works for me.

Quoted 3 lines

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.

Quoted 10 lines

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.

Quoted 1 line

Johannes, what do you think of these approaches?

I think this is not necessary. Just make sure that auth/assoc frames aren't buffered.

Quoted 24 lines · Johannes Berg

Quoted 2 lines · Igor Perminov

Jouni suggests to not buffer Auth/Assoc frames at all, independently of station's PS state.

Ok, works for me.

Quoted 3 lines

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.

Quoted 10 lines

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.

Quoted 4 lines

Quoted 1 line

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?

Quoted 2 lines · Johannes Berg

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

Quoted 10 lines · Igor Perminov

Quoted 2 lines · Johannes Berg

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?

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.

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

Quoted 3 lines

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.

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.

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.

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.

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.

Quoted 4 lines

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,