Johannes Berg wrote:
>> 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

Hi,

Taking your advice in order to avoid ignoring disassociation, I looked 
for another way to achieve the same result.

As you recall, my AP sends a disassociation message due to inactivity
after 300 seconds. A plain re-association ends with a AP timeout due to
the re-association fails with a code=17 after three tries.

wlan0: RX disassociation from 00:17:9a:63:d2:21 (reason=4)
wlan0: disassociated
wlan0: associate with AP 00:17:9a:63:d2:21
wlan0: RX ReassocResp from 00:17:9a:63:d2:21 (capab=0x431 status=17 aid=1)
wlan0: AP denied association (code=17)
wlan0: associate with AP 00:17:9a:63:d2:21
wlan0: RX AssocResp from 00:17:9a:63:d2:21 (capab=0x431 status=17 aid=1073)
wlan0: AP denied association (code=17)
wlan0: associate with AP 00:17:9a:63:d2:21
wlan0: RX AssocResp from 00:17:9a:63:d2:21 (capab=0x431 status=17 aid=1073)
wlan0: AP denied association (code=17)
wlan0: association with AP 00:17:9a:63:d2:21 timed out

When I ignore the disassociation, from the trace I read that process
goes through an authentication/association pair and the link is restored ok.

In order to do not ignore disassociation and following the previous
sequence, after the disassociation is handled I changed the state to
un-authenticated instead of un-associated in order to force an
authentication first (I assume I'am already deauthenticated by
disassociation). It works and the trace is as follows:

wlan0: RX disassociation from 00:17:9a:63:d2:21 (reason=4)
wlan0: disassociated
wlan0: authenticate with AP 00:17:9a:63:d2:21
wlan0: RX authentication from 00:17:9a:63:d2:21 (alg=0 transaction=2
status=0)
wlan0: authenticated
wlan0: associate with AP 00:17:9a:63:d2:21
wlan0: RX ReassocResp from 00:17:9a:63:d2:21 (capab=0x431 status=0 aid=1)
wlan0: associated

Patch attached.

Is this a better solution than to ignore disassociation?

Regards,
Andres