Re: Suspend/Resume support

[Stefano Brivio <stefano.brivio@polimi.it>]

On Fri, 16 Nov 2007 15:24:21 +0200
Kalle Valo <Kalle.Valo@nokia.com> wrote:

> Johannes Berg <johannes@sipsolutions.net> 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