FW: [ipw3945-devel] iwl3945: disassociation from AP (reason=4) andtimeout, a solution

FW: [ipw3945-devel] iwl3945: disassociation from AP (reason=4) andtimeout, a solution

[Chatre, Reinette]

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

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.
> 
> 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

	

[-- Attachment #2: compat-wireless-2.6-ap-timeout.patch --]
[-- Type: text/plain, Size: 772 bytes --]

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);


[-- Attachment #3: ATT3729987.txt --]
[-- Type: text/plain, Size: 282 bytes --]

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

[-- Attachment #4: ATT3729988.txt --]
[-- Type: text/plain, Size: 174 bytes --]

_______________________________________________
Ipw3945-devel mailing list
Ipw3945-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipw3945-devel

Re: FW: [ipw3945-devel] iwl3945: disassociation from AP (reason=4) andtimeout, a solution

[Dan Williams]

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);
> 

Re: FW: [ipw3945-devel] iwl3945: disassociation from AP (reason=4) andtimeout, a solution

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]


> > > 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: FW: [ipw3945-devel] iwl3945: disassociation from AP (reason=4) andtimeout, a solution

[Andres Bertens]

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

Re: FW: [ipw3945-devel] iwl3945: disassociation from AP (reason=4) andtimeout, a solution

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]


> 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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: FW: [ipw3945-devel] iwl3945: disassociation from AP (reason=4) andtimeout, a solution

[Andres Bertens]

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

Re: FW: [ipw3945-devel] iwl3945: disassociation from AP (reason=4) andtimeout, a solution

[Andres Bertens]

[-- Attachment #1: Type: text/plain, Size: 3604 bytes --]



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


[-- Attachment #2: compat-wireless-2.6-ap-timeout-2.patch --]
[-- Type: text/plain, Size: 735 bytes --]

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);
+	}
 }
 
 

Re: FW: [ipw3945-devel] iwl3945: disassociation from AP (reason=4) andtimeout, a solution

[Tomas Winkler]

On Fri, Apr 4, 2008 at 1:03 AM, Andres Bertens <abertensu@yahoo.com> 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
>
>
>
>
>
>
>

Re: [ipw3945-devel] FW: iwl3945: disassociation from AP (reason=4) andtimeout, a solution

[John W. Linville]

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
linville@tuxdriver.com