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 01:14:15.000000000 -0400
+++ compat-wireless-2008-03-28-new/net/mac80211/ieee80211_sta.c 2008-03-28 16:19:57.000000000 -0400
@@ -1809,6 +1809,15 @@
reason_code = le16_to_cpu(mgmt->u.disassoc.reason_code);
+/* ABU */
+ if( reason_code == 4 ) {
+ printk(KERN_DEBUG "%s: RX disassociation for reason=4 "
+ "received from %s - ignored\n",
+ dev->name, print_mac(mac, mgmt->sa));
+ return;
+ }
+/* ABU */
+
printk(KERN_DEBUG "%s: RX disassociation from %s"
" (reason=%d)\n",
dev->name, print_mac(mac, mgmt->sa), reason_code);
> 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
On Tue, Apr 01, 2008 at 02:03:54PM +0200, Johannes Berg wrote:
>
> > > > After browsing the internet, I found a lot of people with the same
> > > > problem and no solution. So, I dived into the code and found a simple
> > > > solution: ignore disassociation. When a new request arrives to the
> > > > wireless, a reconnection is done automatically.
> >
> > Ignoring the disassociation from the AP is suspect... wouldn't the AP
> > be releasing resources associated with the station, requiring a
> > reassociate/reauth from the station? Reason 4 seems to mean "Inactivity
> > timer expired and station was disassociated".
>
> Indeed.
>
> > A better solution would be to queue up a reassocation worker if the AP
> > kicked you off for reason 4, maybe?
>
> It would think so, yes.
But would that reassociation be any more likely to succeed than the
one that the current (unpatched) code is attempting?
It seems likely to me that the patch ignoring disassociation (thereby
provoking a deauth and new assoc) is effectively hacking the MLME
state machine. I'll take a look to see if I can figure it out --
suggestions welcome.
John
--
John W. Linville
[email protected]
On Mon, 2008-03-31 at 14:17 -0700, Chatre, Reinette wrote:
> Forwarding this to linux-wireless where there is more knowledge about
> association. The attached patch is also to the mac80211 stack, so we
> need to involve the mac80211 maintainer.
>
> Reinette
>
> On Friday, March 28, 2008 4:00 PM, Andres Bertens wrote:
>
> > Hi,
> >
> > Recently I moved from ipw3945 to iwl3945 and I was having an AP
> > association timeout after some inactivity.
> > Card is Intel 3945bg, router is DLink DI524, driver is
> > compat-wireless-2.6 (2008-03-28) or older and mode is (WEP, open) on
> > linux-2.6.24.4. It does not recover magically.
> >
> > The trace is:
> >
> > 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
> >
> > After browsing the internet, I found a lot of people with the same
> > problem and no solution. So, I dived into the code and found a simple
> > solution: ignore disassociation. When a new request arrives to the
> > wireless, a reconnection is done automatically.
Ignoring the disassociation from the AP is suspect... wouldn't the AP
be releasing resources associated with the station, requiring a
reassociate/reauth from the station? Reason 4 seems to mean "Inactivity
timer expired and station was disassociated".
A better solution would be to queue up a reassocation worker if the AP
kicked you off for reason 4, maybe?
Dan
> > I patched the code, modifying net/mac80211/ieee80211_sta.c, and trace
> > is as follow:
> >
> > wlan0: RX disassociation for reason=4 received from 00:17:9a:63:d2:21
> > - ignored
> > wlan0: RX deauthentication from 00:17:9a:63:d2:21 (reason=6)
> > wlan0: deauthenticated
> > 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=2) wlan0: associated
> >
> > and these entries repeats in time. As you can see, the disassociation
> > still ocurrs but a new request afterwards generates a deauthentication
> > (reason=6) and a reconnection takes place (transparent to the user).
> >
> > Attached is patch to compat-wireless-2.6 (2008-03-28). Please note
> > that this is for iwl3945+dlink+WEP combination (according to other
> > people, it seems to work for other combinations).
> >
> > Hope this help.
> >
> > Regards,
> > Andres Bertens
>
>
> plain text document attachment (compat-wireless-2.6-ap-timeout.patch),
> "compat-wireless-2.6-ap-timeout.patch"
> 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 01:14:15.000000000 -0400
> +++ compat-wireless-2008-03-28-new/net/mac80211/ieee80211_sta.c 2008-03-28 16:19:57.000000000 -0400
> @@ -1809,6 +1809,15 @@
>
> reason_code = le16_to_cpu(mgmt->u.disassoc.reason_code);
>
> +/* ABU */
> + if( reason_code == 4 ) {
> + printk(KERN_DEBUG "%s: RX disassociation for reason=4 "
> + "received from %s - ignored\n",
> + dev->name, print_mac(mac, mgmt->sa));
> + return;
> + }
> +/* ABU */
> +
> printk(KERN_DEBUG "%s: RX disassociation from %s"
> " (reason=%d)\n",
> dev->name, print_mac(mac, mgmt->sa), reason_code);
>
On Fri, Apr 4, 2008 at 1:03 AM, Andres Bertens <[email protected]> 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
>
>
>
>
>
>
>
Johannes Berg wrote:
>>>> After browsing the internet, I found a lot of people with the same
>>>> problem and no solution. So, I dived into the code and found a simple
>>>> solution: ignore disassociation. When a new request arrives to the
>>>> wireless, a reconnection is done automatically.
>> Ignoring the disassociation from the AP is suspect... wouldn't the AP
>> be releasing resources associated with the station, requiring a
>> reassociate/reauth from the station? Reason 4 seems to mean "Inactivity
>> timer expired and station was disassociated".
>
> Indeed.
>
>> A better solution would be to queue up a reassocation worker if the AP
>> kicked you off for reason 4, maybe?
>
> It would think so, yes.
>
> johannes
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 but my hw/sw
combination (intel3945/dlink/wep) fails with a status=17 (AP unable to
handle new status). 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.
Andres
> > > After browsing the internet, I found a lot of people with the same
> > > problem and no solution. So, I dived into the code and found a simple
> > > solution: ignore disassociation. When a new request arrives to the
> > > wireless, a reconnection is done automatically.
>
> Ignoring the disassociation from the AP is suspect... wouldn't the AP
> be releasing resources associated with the station, requiring a
> reassociate/reauth from the station? Reason 4 seems to mean "Inactivity
> timer expired and station was disassociated".
Indeed.
> A better solution would be to queue up a reassocation worker if the AP
> kicked you off for reason 4, maybe?
It would think so, yes.
johannes
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);
+ }
}
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
Sorry to hear my AP is broken.
It works ok with other 2 computers with different cards (intel2200bg and
dlink w/texas acx100) under Linux (ipw2200/acx100) or Windows. No
problem at all. It worked flawlessly with my notebook (intel3945) using
ipw3945 with any pre-2.6.24.x kernel.
A couple of months ago I tried kernel 2.6.24 with iwlwifi and moved back
due to this problem. A week ago, I tried again but this time getting
into the code and I'm still using kernel 2.6.24.4 with this fix which is
obviously wrong.
I guess you will hear more often about this problem when more people
moves to kernel 2.6.24.x.
Regards,
Andres