[ath9k-devel] Unreliable connection with AR5008 (AR5416/AR2122)

[ath9k-devel] Unreliable connection with AR5008 (AR5416/AR2122)

[Andrej Podzimek]

Hello,

my Zyxel PCMCIA card is almost unusable. The card keeps disconnecting all the time. When the connection gets stuck, the only thing that helps is

	ping6 -q -i 0 <my-server's address>

This ping flood unblocks the connection in about ten seconds to one minute. When the broken connection is just left alone, it may recover after half an hour and sometimes it doesn't recover at all. Some important notes:

	1) Other laptops and WiFi IP phones work with the same AP just fine.
	2) The same laptop has another WiFi card (using the ipw2200 driver) in MiniPCI. It works as well.
	3) The Zyxel card worked till kernel 2.6.29.x. It became unusable since 2.6.30.

A note concerning remark 3: Those freezes could have been less frequent or harder to notice. However, log messages (see below) clearly showed something was wrong even in 2.6.29.x.

What I tried:
	* Tested compat-wireless about once a week for the last two months. That didn't help.
	* Unloaded modules for most network, IRDA and USB devices to find out if ath9k would become more reliable. (No.)
	* Tested the same card with three other access points. (Still the same problem.)
	* Switched the debugfs stuff on. Doesn't work, the card never associates when debugging and debugfs are on.

Details:
	Laptop: Asus M2N
	WiFi Cards: Zyxel NWD-170N on PCMCIA (fails), Intel 2915ABG on MiniPCI (works)
	Kernel: 2.6.31.5 vanilla, tested both with and without compat-wireless

Zyxel card's line from lspci:

	02:00.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01)

Zyxel card's lines from dmesg:

	pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0                                            
	pci 0000:02:00.0: reg 10 32bit mmio: [0x000000-0x00ffff]                                                           
	cfg80211: Calling CRDA to update world regulatory domain                                                           
	cfg80211: Calling CRDA for country: CZ                                                                             
	ath9k 0000:02:00.0: enabling device (0000 -> 0002)                                                                 
	ath9k 0000:02:00.0: PCI INT A -> Link[LNKB] -> GSI 5 (level, low) -> IRQ 5                                         
	cfg80211: Regulatory domain changed to country: CZ                                                                 
	        (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)                                          
	        (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)                                                   
	        (5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2301 mBm)                                                   
	        (5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2301 mBm)                                                   
	        (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 3000 mBm)                                                   
	ath: EEPROM regdomain: 0x30                                                                                        
	ath: EEPROM indicates we should expect a direct regpair map                                                        
	ath: Country alpha2 being used: AM                                                                                 
	ath: Regpair used: 0x30                                                                                            
	phy0: Selected rate control algorithm 'ath9k_rate_control'                                                         
	Registered led device: ath9k-phy0::radio                                                                           
	Registered led device: ath9k-phy0::assoc                                                                           
	Registered led device: ath9k-phy0::tx                                                                              
	Registered led device: ath9k-phy0::rx                                                                              
	phy0: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81: mem=0xf0680000, irq=5                                          
	cfg80211: Calling CRDA for country: AM                                                                             
	cfg80211: Current regulatory domain intersected:                                                                   
	        (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)                                          
	        (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)                                                   
	        (5170000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 1800 mBm)                                                   
	        (5250000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 1800 mBm)                                                   

The logs show this over and over:

	wlan0: deauthenticating from 00:23:f8:22:aa:a6 by local choice (reason=3)
	wlan0: direct probe to AP 00:23:f8:22:aa:a6 (try 1)
	wlan0: deauthenticating from 00:23:f8:22:aa:a6 by local choice (reason=3)
	wlan0: deauthenticating from 00:23:f8:22:aa:a6 by local choice (reason=3)
	wlan0: direct probe to AP 00:23:f8:22:aa:a6 (try 1)
	wlan0: direct probe responded
	wlan0: authenticate with AP 00:23:f8:22:aa:a6 (try 1)
	wlan0: authenticated
	wlan0: associate with AP 00:23:f8:22:aa:a6 (try 1)
	wlan0: RX AssocResp from 00:23:f8:22:aa:a6 (capab=0x431 status=0 aid=2)
	wlan0: associated

I am convinced that most of these problems are caused by the Minstrel algorithm. The algorithm chooses transfer rates too aggressively, so the card exceeds its retry limit too often. Unfortunately, I can't choose other algorithms, such as PID, in the kernel configuration. They have been removed and only Minstrel stayed there. :-( The mac80211 module doesn't care about the ieee80211_default_rc_algo option. You can easily set it to 'nonsense' and the module will load happily, probably still using Minstrel.

One more *important* note. The access point is situated on the other side of a corridor, opposite to my room. Signal level is usually around -50 dBm. Reliability of the connection depends on how many people walk through the corridor. (!) It fails about once in two hours at night when nobody walks around. However, failures may occur every minute or even more often when there is more movement around the access point during the day. Most failures are *clearly* related to people passing between the access point and the Zyxel WiFi card.

I think the rate control algorithm should handle all these situations gracefully, temporarily dropping the transfer rate to eliminate frame loss. Minstrel is probably too aggressive, which causes packets to be lost on the IP layer. Anyway, that's just a wild guess, a desperate shot in the dark. :-)

It would be great if I could use other rate control algorithms (PID in the first place) to prove this theory. Is this still possible? Is there a patch for that?

Please let me know what I could try or test.

Andrej

[ath9k-devel] Unreliable connection with AR5008 (AR5416/AR2122)

[Luis R. Rodriguez]

On Sat, Oct 31, 2009 at 8:32 AM, Andrej Podzimek <andrej@podzimek.org> wrote:
> Hello,
>
> my Zyxel PCMCIA card is almost unusable. The card keeps disconnecting all the time. When the connection gets stuck, the only thing that helps is
>
> ? ? ? ?ping6 -q -i 0 <my-server's address>
>
> This ping flood unblocks the connection in about ten seconds to one minute. When the broken connection is just left alone, it may recover after half an hour and sometimes it doesn't recover at all. Some important notes:
>
> ? ? ? ?1) Other laptops and WiFi IP phones work with the same AP just fine.
> ? ? ? ?2) The same laptop has another WiFi card (using the ipw2200 driver) in MiniPCI. It works as well.
> ? ? ? ?3) The Zyxel card worked till kernel 2.6.29.x. It became unusable since 2.6.30.
>
> A note concerning remark 3: Those freezes could have been less frequent or harder to notice. However, log messages (see below) clearly showed something was wrong even in 2.6.29.x.
>
> What I tried:
> ? ? ? ?* Tested compat-wireless about once a week for the last two months. That didn't help.
> ? ? ? ?* Unloaded modules for most network, IRDA and USB devices to find out if ath9k would become more reliable. (No.)
> ? ? ? ?* Tested the same card with three other access points. (Still the same problem.)
> ? ? ? ?* Switched the debugfs stuff on. Doesn't work, the card never associates when debugging and debugfs are on.
>
> Details:
> ? ? ? ?Laptop: Asus M2N
> ? ? ? ?WiFi Cards: Zyxel NWD-170N on PCMCIA (fails), Intel 2915ABG on MiniPCI (works)
> ? ? ? ?Kernel: 2.6.31.5 vanilla, tested both with and without compat-wireless
>
> Zyxel card's line from lspci:
>
> ? ? ? ?02:00.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01)
>
> Zyxel card's lines from dmesg:
>
> ? ? ? ?pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0
> ? ? ? ?pci 0000:02:00.0: reg 10 32bit mmio: [0x000000-0x00ffff]
> ? ? ? ?cfg80211: Calling CRDA to update world regulatory domain
> ? ? ? ?cfg80211: Calling CRDA for country: CZ
> ? ? ? ?ath9k 0000:02:00.0: enabling device (0000 -> 0002)
> ? ? ? ?ath9k 0000:02:00.0: PCI INT A -> Link[LNKB] -> GSI 5 (level, low) -> IRQ 5
> ? ? ? ?cfg80211: Regulatory domain changed to country: CZ
> ? ? ? ? ? ? ? ?(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> ? ? ? ? ? ? ? ?(2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
> ? ? ? ? ? ? ? ?(5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2301 mBm)
> ? ? ? ? ? ? ? ?(5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2301 mBm)
> ? ? ? ? ? ? ? ?(5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 3000 mBm)
> ? ? ? ?ath: EEPROM regdomain: 0x30
> ? ? ? ?ath: EEPROM indicates we should expect a direct regpair map
> ? ? ? ?ath: Country alpha2 being used: AM
> ? ? ? ?ath: Regpair used: 0x30
> ? ? ? ?phy0: Selected rate control algorithm 'ath9k_rate_control'
> ? ? ? ?Registered led device: ath9k-phy0::radio
> ? ? ? ?Registered led device: ath9k-phy0::assoc
> ? ? ? ?Registered led device: ath9k-phy0::tx
> ? ? ? ?Registered led device: ath9k-phy0::rx
> ? ? ? ?phy0: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81: mem=0xf0680000, irq=5
> ? ? ? ?cfg80211: Calling CRDA for country: AM
> ? ? ? ?cfg80211: Current regulatory domain intersected:
> ? ? ? ? ? ? ? ?(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> ? ? ? ? ? ? ? ?(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> ? ? ? ? ? ? ? ?(5170000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 1800 mBm)
> ? ? ? ? ? ? ? ?(5250000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 1800 mBm)
>
> The logs show this over and over:
>
> ? ? ? ?wlan0: deauthenticating from 00:23:f8:22:aa:a6 by local choice (reason=3)
> ? ? ? ?wlan0: direct probe to AP 00:23:f8:22:aa:a6 (try 1)
> ? ? ? ?wlan0: deauthenticating from 00:23:f8:22:aa:a6 by local choice (reason=3)
> ? ? ? ?wlan0: deauthenticating from 00:23:f8:22:aa:a6 by local choice (reason=3)
> ? ? ? ?wlan0: direct probe to AP 00:23:f8:22:aa:a6 (try 1)
> ? ? ? ?wlan0: direct probe responded
> ? ? ? ?wlan0: authenticate with AP 00:23:f8:22:aa:a6 (try 1)
> ? ? ? ?wlan0: authenticated
> ? ? ? ?wlan0: associate with AP 00:23:f8:22:aa:a6 (try 1)
> ? ? ? ?wlan0: RX AssocResp from 00:23:f8:22:aa:a6 (capab=0x431 status=0 aid=2)
> ? ? ? ?wlan0: associated
>
> I am convinced that most of these problems are caused by the Minstrel algorithm.

That's a pretty wild conclusion given that minstrel is not used on
ath9k. ath9k uses its own rate control algorithm. Can you please try
bisecting between 2.6.29 and 2.6.30? It would be of much help.

What AP do you have? What AP setup settings do you have?

  Luis

[ath9k-devel] Unreliable connection with AR5008 (AR5416/AR2122)

[Andrej Podzimek]

> That's a pretty wild conclusion given that minstrel is not used on
> ath9k. ath9k uses its own rate control algorithm. Can you please try
> bisecting between 2.6.29 and 2.6.30? It would be of much help.

So the ieee80211_default_rc_algo option of mac80211 has no meaning at all?

Unfortunately, I can't find the commit that caused the problem. Don't have enough time for so many compilations and experiments. Anyway, there have been disassociation problems since I bought the card, so I'm not perfectly sure if the failures were absent or just hidden by the fact that there were few people walking thorugh the building during summmer holidays.

Anyway, a slightly modified version of my question: Are there any alternative rate control algorithms? Trying one of them might be a good thing to start with...

> What AP do you have? What AP setup settings do you have?

I tried three (or perhaps even more) APs. The problem was the same everywhere. I only know the type of one of them: Zyxel NBG-420N. It's set to WPA2 with EAP-TLS authentication. It does *not* provide any detailed WiFi configuration (DTIM period, RTS/fragmentation threshold, beacon interval and the like).

The Zyxel AP is a standard basic AP for home computing. The other three (or more) APs are enterprise-class devices that form a big network with roaming inside a university building. Zyxel NBG-420N supports 802.11n, whereas all the other APs only support 802.11g.

Andrej



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6087 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20091031/52eb0e39/attachment.bin 

[ath9k-devel] Unreliable connection with AR5008 (AR5416/AR2122)

[Andrej Podzimek]

>>> That's a pretty wild conclusion given that minstrel is not used on
>>> ath9k. ath9k uses its own rate control algorithm. Can you please try
>>> bisecting between 2.6.29 and 2.6.30? It would be of much help.
>> So the ieee80211_default_rc_algo option of mac80211 has no meaning at all?
>>
>> Unfortunately, I can't find the commit that caused the problem. Don't have
>> enough time for so many compilations and experiments. Anyway, there have
>> been disassociation problems since I bought the card, so I'm not perfectly
>> sure if the failures were absent or just hidden by the fact that there were
>> few people walking thorugh the building during summmer holidays.
>>
>> Anyway, a slightly modified version of my question: Are there any
>> alternative rate control algorithms? Trying one of them might be a good
>> thing to start with...
>>
>>> What AP do you have? What AP setup settings do you have?
>> I tried three (or perhaps even more) APs. The problem was the same
>> everywhere. I only know the type of one of them: Zyxel NBG-420N. It's set to
>> WPA2 with EAP-TLS authentication. It does *not* provide any detailed WiFi
>> configuration (DTIM period, RTS/fragmentation threshold, beacon interval and
>> the like).
>>
>> The Zyxel AP is a standard basic AP for home computing. The other three (or
>> more) APs are enterprise-class devices that form a big network with roaming
>> inside a university building. Zyxel NBG-420N supports 802.11n, whereas all
>> the other APs only support 802.11g.
> 
> This should not affect anything but.. can you try compiling and
> installin the latest git version of wpa_supplicant?

OK, compiled the current version from GIT.

I can still see deauthentications in the log. However, the network hasn't got stuck yet. It's too early to make a conclusion, I'll report back after two days or so.

There's a new line appearing in the logs before each deauthentication:

	ath9k: Two wiphys trying to scan at the same time

I haven't seen this one before.

Andrej

[ath9k-devel] Unreliable connection with AR5008 (AR5416/AR2122)

[Andrej Podzimek]

>>> That's a pretty wild conclusion given that minstrel is not used on
>>> ath9k. ath9k uses its own rate control algorithm. Can you please try
>>> bisecting between 2.6.29 and 2.6.30? It would be of much help.
>> So the ieee80211_default_rc_algo option of mac80211 has no meaning at all?
>>
>> Unfortunately, I can't find the commit that caused the problem. Don't have
>> enough time for so many compilations and experiments. Anyway, there have
>> been disassociation problems since I bought the card, so I'm not perfectly
>> sure if the failures were absent or just hidden by the fact that there were
>> few people walking thorugh the building during summmer holidays.
>>
>> Anyway, a slightly modified version of my question: Are there any
>> alternative rate control algorithms? Trying one of them might be a good
>> thing to start with...
>>
>>> What AP do you have? What AP setup settings do you have?
>> I tried three (or perhaps even more) APs. The problem was the same
>> everywhere. I only know the type of one of them: Zyxel NBG-420N. It's set to
>> WPA2 with EAP-TLS authentication. It does *not* provide any detailed WiFi
>> configuration (DTIM period, RTS/fragmentation threshold, beacon interval and
>> the like).
>>
>> The Zyxel AP is a standard basic AP for home computing. The other three (or
>> more) APs are enterprise-class devices that form a big network with roaming
>> inside a university building. Zyxel NBG-420N supports 802.11n, whereas all
>> the other APs only support 802.11g.
> 
> This should not affect anything but.. can you try compiling and
> installin the latest git version of wpa_supplicant?

Hello,

after a couple of hours of uptime, I have to say that freezes are equally frequent with both the GIT version and the current release. They still strongly depend on the ?amount of movement? around the router. Most freezes occur in the moment when somebody walks by.

Andrej