> Reason=4 is in fact "Inactivity timer expired and station was > disassociated". According to my router log: > "Tuesday April 01, 2008 09:08:54 Disassociated: 00-19-D2-4F-22-4D > because idle 300 seconds" > > Indeed, the default behaviour goes for a reassocation Right, I just checked, we try to reassociate after one second. > but my hw/sw > combination (intel3945/dlink/wep) fails with a status=17 (AP unable to > handle new status). 17 actually is WLAN_REASON_IE_DIFFERENT, i.e. the WPA/RSN IE we send is no longer appropriate, something for wpa_supplicant to handle then. Are you using encryption? > After 3 tries, it dies with an AP association > timeout. From there is no recovery till I set the interface down and up. > > That's why I solved it (perhaps not in the best way) ignoring the > disassociation. Now it works. Your AP is broken. After it disassociates you and you ignore this status, it complains that it deauthenticated (!) you and then deauthenticates you again (with reason=6 meaning that you weren't authenticated.) The thing is, it's disassociating you and thinks it actually deauthenticated you since when you ignore the disassociation and continue sending it frames it starts complaining that you weren't authenticated (reason=6.) Your fix is obviously wrong, and only fixes the problem for you because it works around your broken AP that needs a re-authentication after it disassociated you. I'm not sure what we can do about that. Assuming we're deauthenticated seems completely wrong, and I fear that if we assume deauthentication if the association times out then we may easily end up in a loop there. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
