Hi all,
Some time ago there was discussion on this list regarding suspend/resume
support in mac80211 (See 05 Aug 2007, "suspend/resume support in
mac80211"). The conclusion of this thread was that mac80211 had no
suspend/resume support and that functionality to stop the stack needed
to be added to fully support suspend. Has anyone started working on
implementing this functionality?
If not, precisely what needs to be done to add robust suspend/resume
support to mac80211? Might this be a project that someone not presently
familiar with the mac80211 codebase could tackle with some guidance?
Thanks a ton,
- Ben
On Nov 15, 2007 8:51 AM, Ben Gamari <[email protected]> wrote:
> Hi all,
>
> Some time ago there was discussion on this list regarding suspend/resume
> support in mac80211 (See 05 Aug 2007, "suspend/resume support in
> mac80211"). The conclusion of this thread was that mac80211 had no
> suspend/resume support and that functionality to stop the stack needed
> to be added to fully support suspend. Has anyone started working on
> implementing this functionality?
>
> If not, precisely what needs to be done to add robust suspend/resume
> support to mac80211? Might this be a project that someone not presently
> familiar with the mac80211 codebase could tackle with some guidance?
> Thanks a ton,
>
Hope below link is helpful:
http://kernelnewbies.org/KernelProjects/Mac80211Suspend
Li YanBo
On Fri, Nov 16, 2007 at 03:41:07PM +0100, Johannes Berg wrote:
> mac80211 has a comment that NULL frames are just for PS control
> operation and otherwise ignored. So no idea.
Please note that this comment in ieee80211_rx_h_sta_process() is only
after having went through association state validation in
ieee80211_rx_h_check(). However, it looks like the sending of
deauth/disassoc based on Class 2/3 frames being received in wrong state
(IEEE 802.11, Clause 5.5) has been broken at some point..
mac80211 is supposed to notify userspace (hostapd) of this and hostapd
would then reply with disassoc/deauth depending on the current state of
the STA. The current mac80211 implementation is just silently dropping
the frames. The way this used to work was by sending the
ieee80211_msg_sta_not_assoc message with ieee80211_rx_mgmt() in
ieee80211_rx_h_check().
--
Jouni Malinen PGP id EFC895FA
Johannes Berg <[email protected]> writes:
> If it is, we need to determine whether we were suspended long enough
> for it to kick us off. It might be possible to do this by sending a
> null function frame to the AP and see if it replies with a deauth
> notification, I think it should if we're not associated [3].
I think that at least most (if not all) of the APs do send a deauth
frame in that case. I have seen this happening when debugging some
bugs. But I don't know if the standard specifies that.
--
Kalle Valo
On Fri, 2007-11-16 at 15:24 +0200, Kalle Valo wrote:
> I think that at least most (if not all) of the APs do send a deauth
> frame in that case. I have seen this happening when debugging some
> bugs. But I don't know if the standard specifies that.
mac80211 has a comment that NULL frames are just for PS control
operation and otherwise ignored. So no idea.
johannes
> > mac80211 has a comment that NULL frames are just for PS control
> > operation and otherwise ignored. So no idea.
>
> Please note that this comment in ieee80211_rx_h_sta_process() is only
> after having went through association state validation in
> ieee80211_rx_h_check().
Oh good point.
> However, it looks like the sending of
> deauth/disassoc based on Class 2/3 frames being received in wrong state
> (IEEE 802.11, Clause 5.5) has been broken at some point..
>
> mac80211 is supposed to notify userspace (hostapd) of this and hostapd
> would then reply with disassoc/deauth depending on the current state of
> the STA. The current mac80211 implementation is just silently dropping
> the frames. The way this used to work was by sending the
> ieee80211_msg_sta_not_assoc message with ieee80211_rx_mgmt() in
> ieee80211_rx_h_check().
Yes. This was removed along with the mgmt iface, it needs to be added
back.
johannes
On Fri, 16 Nov 2007 15:24:21 +0200
Kalle Valo <[email protected]> wrote:
> Johannes Berg <[email protected]> writes:
>
> > If it is, we need to determine whether we were suspended long enough
> > for it to kick us off. It might be possible to do this by sending a
> > null function frame to the AP and see if it replies with a deauth
> > notification, I think it should if we're not associated [3].
>
> I think that at least most (if not all) of the APs do send a deauth
> frame in that case. I have seen this happening when debugging some
> bugs. But I don't know if the standard specifies that.
Yes, it does - implicitly. Please see 802.11, 7.3.1.7, Table 18, reason
codes of deauthentication frames are 6 for "Class 2 [1] frame received from
nonauthenticated station" and 7 for "Class 3 [1] frame received from
nonassociated station". But IIRC hostapd doesn't do that, some APs in my
neighborhood and mine don't either - I'd say this isn't strongly required
by the standard. I'd suggest that, in case we don't get a reply for some
time, we should retry association. The problem here is that some userspace
tools like wpa_supplicant retry association by themselves, and there could
be issues with roaming. On the other side, if we don't want to break
wireless extensions compatibility, we should ensure that, once we set an
ESSID with - say - iwconfig, we stay associated and - in case - reassociate.
[1] 802.11, 5.5
--
Ciao
Stefano
On Fri, Nov 16, 2007 at 01:11:09AM +0100, Johannes Berg wrote:
> On the other hand, if you've suspended for a longer period of time, your
> AP will have kicked you off for not responding. This means you need to
> associate again (not even reassociate [1]) if the AP you were associated
> to is even still around.
> [1] the IEEE 802.11 specs define "reassociation" but that requires the
> AP keeping state about you which typically they won't do long
I would use reassociation whenever trying to get back to the same ESS
(when SSID does not change) and the previous BSSID is known. There
cannot be any requirement on the non-AP STA to somehow magically figure
out whether the APs have or have not state from the previous
association.
> I guess the way to handle it would be to send a probe request to the AP
> we're associated with first to see if it's still in range. If it is, we
> need to determine whether we were suspended long enough for it to kick
> us off. It might be possible to do this by sending a null function frame
> to the AP and see if it replies with a deauth notification, I think it
> should if we're not associated [3]. But then again I'm not sure whether
> we should rely on this.
This is perfectly valid way of validating whether the STA is still
associated (see rules on Class 2 and 3 frames in auth/assoc state in
Clause 5.5). In addition, there is no need for the probe request before
sending nullfunc data frame. If the nullfunc data frame is acknowledged,
the AP is still in range. If deauth or disassoc frame is received from
the AP, the association was not valid anymore. This should trigger
re-association.
> Another option would be to send it a reassociate
> request, it should simply respond with an OK, otherwise it sends a
> disassociate so we automatically restart the state machine and send
> appropriate notifications to userspace.
Reassociation will fail unless the STA in in authenticated state, i.e.,
this will need to start with 802.11 authentication. Though, if the
nullfunc data test is used, there is no need for this and it should be
possible to avoid the full cost of running whatever authentication
methods are required in the network (e.g., EAP).
--
Jouni Malinen PGP id EFC895FA
[reordering quotes]
> Hope below link is helpful:
> http://kernelnewbies.org/KernelProjects/Mac80211Suspend
Indeed, and somebody already "took" the project on
http://kernelnewbies.org/KernelProjects/.
> > Some time ago there was discussion on this list regarding suspend/resume
> > support in mac80211 (See 05 Aug 2007, "suspend/resume support in
> > mac80211"). The conclusion of this thread was that mac80211 had no
> > suspend/resume support and that functionality to stop the stack needed
> > to be added to fully support suspend. Has anyone started working on
> > implementing this functionality?
Jose told me he has started with reviewing the code.
> > Might this be a project that someone not presently
> > familiar with the mac80211 codebase could tackle with some guidance?
Yes, I think this is doable, although recent work wrt. 802.11n might
require more thinking.
> > If not, precisely what needs to be done to add robust suspend/resume
> > support to mac80211?
Well, that's really a can of worms. For one, you want to have as
seamless operation as possible if you're like me and just quickly
suspend the laptop to swap the battery because the one you're using is
running out of power. So that would usually be quick enough to make you
not lose your association. Obviously, hardware still loses state so
keys, BSSIDs and all other configuration needs to be programmed into the
hardware again. The driver shouldn't have to handle that except notify
mac80211 that the hardware was resumed and needs to be reprogrammed
which would cause mac80211 to call the appropriate callbacks.
On the other hand, if you've suspended for a longer period of time, your
AP will have kicked you off for not responding. This means you need to
associate again (not even reassociate [1]) if the AP you were associated
to is even still around. If kernel roaming is enabled then you would
want to try to associate to another AP in the same ESS, but I think the
state machine would do that automatically once it determined that the
connection was lost. Unless of course it gets stuck in the "can't do
anything" state Stefano was complaining about.
Now, consider the wpa_supplicant case. wpa_supplicant typically will
disable kernel roaming and choose an AP on its own. This is another case
we need to handle well, in the first case (just a short suspend) it's
not really necessary to do all the crypto handshake again etc. This
needs some thinking. Also, the integrated userspace MLME will have to
handle all this as well so we need to be able to notify it about a
suspend event in some way [2].
I guess the way to handle it would be to send a probe request to the AP
we're associated with first to see if it's still in range. If it is, we
need to determine whether we were suspended long enough for it to kick
us off. It might be possible to do this by sending a null function frame
to the AP and see if it replies with a deauth notification, I think it
should if we're not associated [3]. But then again I'm not sure whether
we should rely on this. Another option would be to send it a reassociate
request, it should simply respond with an OK, otherwise it sends a
disassociate so we automatically restart the state machine and send
appropriate notifications to userspace.
Whatever implementation you come up with will have to be duplicated into
wpa_supplicant's userspace MLME as well.
As you can see, it requires some creative thinking and probably fairly
good knowledge of the standard but less so knowledge of mac80211. Sure,
you need to know how to reconfigure the hardware at resume time, but
that shouldn't be too hard. Beware of locking problems when drivers call
a function that calls back into the driver :)
johannes
[1] the IEEE 802.11 specs define "reassociation" but that requires the
AP keeping state about you which typically they won't do long
[2] and no, system suspend doesn't cut it because we may be selectively
suspending just the wireless device or USB or ...
[3] not sure. reviewing the 802.11 spec didn't find anything useful.