From: Jouni Malinen (jkm_at_ssh.com)
Date: 2002-02-11 15:13:20 UTC
On Sat, Feb 09, 2002 at 12:32:13PM -0800, Magnus Carlsson wrote:
> What seems to happen is that when I approach the range limit, the
> cards lower the rates. Then, the station driver resets its card, and
> after this, the station cannot associate any more with the access
> point. Removing and re-inserting the card in the station doesn't
> help, but doing it in the access point does solve the problem.
I haven't noticed this in my tests, but I found a clear bug in the driver that explains your case.
> /var/log/messages on the access point:
>
> Jan 30 09:03:17 accesspoint kernel: wlan0: deauthentication: 00:05:5d:a7:52:c4 len=2, reason_code=3
> Jan 30 09:03:19 accesspoint kernel: wlan0: authentication: 00:05:5d:a7:52:c4 len=6, auth_alg=0, auth_transaction=1, status_code=0
> Jan 30 09:03:19 accesspoint kernel: wlan0: association request: 00:05:5d:a7:52:c4 len=16
> Jan 30 09:03:19 accesspoint kernel: AP: STA 00:05:5d:a7:52:c4 trying to associate before authentication
Here the station deauthenticates itself for some reason (3 = station is leaving ESS) and then re-authenticates. However, prism2_ap.c has a bug in handle_authen(); it does not mark the station as authenticated if it already had an entry. This case should occur only when the station uses explicit deauthentication and then returns to the same AP before the entry has timed out. I haven't seen deauthentication frames used very often so this has not happened in my test setup. Anyway, here's a patch that should fix this case. I have not tested it and there may well be other issues with stations going out of range. Please let me know, if this fixes the problems.
-- Jouni Malinen SSH Communications Security Corp jouni.malinen_at_ssh.com