linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Igor Perminov <igor.perminov@inbox.ru>
To: linux-wireless@vger.kernel.org
Subject: A station can't reconnect after it wakes up
Date: Tue, 28 Jul 2009 19:38:05 +0400	[thread overview]
Message-ID: <1248795485.29068.144.camel@sunlight> (raw)

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



             reply	other threads:[~2009-07-28 15:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-28 15:38 Igor Perminov [this message]
     [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
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

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=1248795485.29068.144.camel@sunlight \
    --to=igor.perminov@inbox.ru \
    --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).