On Fri, 16 Nov 2007 15:24:21 +0200 Kalle Valo <Kalle.Valo@xxxxxxxxx> wrote: > Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
