On Fri, Apr 4, 2008 at 1:03 AM, Andres Bertens <abertensu@xxxxxxxxx> wrote:
>
>
>
> 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
>
>
> diff -Naur compat-wireless-2008-03-28/net/mac80211/ieee80211_sta.c
> compat-wireless-2008-03-28-new/net/mac80211/ieee80211_sta.c
> --- compat-wireless-2008-03-28/net/mac80211/ieee80211_sta.c 2008-03-28
> 02:14:15.000000000 -0300
> +++ compat-wireless-2008-03-28-new/net/mac80211/ieee80211_sta.c 2008-04-03
> 16:47:33.000000000 -0400
> @@ -1823,6 +1823,16 @@
> }
>
> ieee80211_set_disassoc(dev, ifsta, 0);
> +
> + /* Set state to un-authenticated when receive
> + a disassociation request from the AP by inactivity */
> + if( reason_code == 4 ) {
> + ifsta->auth_tries = 0;
> + ifsta->flags &= ~IEEE80211_STA_AUTHENTICATED;
> + ifsta->state = IEEE80211_AUTHENTICATE;
> + mod_timer(&ifsta->timer, jiffies +
> + IEEE80211_RETRY_AUTH_INTERVAL);
> + }
> }
This would be wrong to do there can be other issues this is happening.
Can you get a sniffer capture of this problem.
1. Is there any traffic activity happaning during.
2. What is the listen interval announced by AP (should be present in
association response)
4. What is the frequency mac8011 sends its probe request?
In general it is OK if AP dissociates inactive station the problem why
is happening with this driver.
Usually this is triggered if there are many station connected to the
AP or station doesn't ACK traffic.
The sniff capture will be really important here?
Tomas
>
>
>
>
>
>
>
--
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
