# Atheros wireless card will randomly disconnect

## sheriff-jms

I have a desktop machine with a Netgear wireless card in it (Atheros AR5001X+ chipset).  Prior to a recent kernel upgrade (2.6.36-r5), my connectivity over the wireless link was rock-solid.  Builds on earlier kernels used the wireless-ng Atheros drivers, but in the new kernel, I'm using the in-kernel Atheros drivers.  Now, seemingly at random, the kernel will report that it can't reach my AP, and disconnect the wlan0 interface.  This does not appear to be an idle/timeout issue, as it has happened when I've been ssh'd into the machine, generating steady traffic over the wireless interface.

```
Mar  1 10:14:14 whammy kernel: No probe response from AP xx:xx:xx:xx:xx:xx after 500ms, disconnecting

Mar  1 10:14:14 whammy kernel: cfg80211: calling CRDA to update world regulatory domain

```

I also see these messages periodically in the message log, however they appear to be just informational.

```
Mar  1 10:03:01 whammy kernel: ath5k: phy0: calibration of channel 6 failed

```

Manually re-adding the SSID to the wlan0 interface will bring the link back up.

Neither the computer nor the AP have been re-positioned, and when I bring the wlan interface back up, the reported signal strength and link quality are OK.

So, at this point I'm trying to get to the bottom of why the disconnects are happening, and if there's anything I can tweak on the machine to resolve it, or at least prevent it from disconnecting when the probe response fails.  

If I absolutely had to, I could write a script to either watch the message log for the probe failure message or do an iwconfig every few minutes to look for 'Not-Associated' and try to bring the wlan interface back up, but that seems like a kludgey hack that doesn't solve the problem.

Any ideas?

----------

## richard.scott

Are you using WPA_Supplicant?

I've found that I need to increase the niceness of that process to stay connected... for some reason if you don't it doesn't get enough cpu time and hangs or delays my ssh sessions.

----------

## greyspoke

Mine (a TP-link wireless-n card using the ath9k drivers in the 3.0.6 kernel and wpa_supplicant) disconnects and then reconnects regularly, though it seems to do this in phases.  Not a problem, big downloads go fine, just sometimes clicking on a link in a browser there is a "cannot find server" message if it coincides with one of the down-up periods, then it behaves itself again.

 *richard.scott wrote:*   

> Are you using WPA_Supplicant?
> 
> I've found that I need to increase the niceness of that process to stay connected... for some reason if you don't it doesn't get enough cpu time and hangs or delays my ssh sessions.

 

That sounds great, more niceness  :Very Happy: 

Um, how does one achieve that?

----------

## richard.scott

Run this after booting:

```
#!/bin/bash

for P in $(pgrep wpa) ; do

  renice -n -5 ${P}

done
```

It will change the niceness of anything with WPA in its process name to '-5'

Use htop to check whats going on (emerge htop).

Rich.

----------

## sheriff-jms

I ended up working around this by pulling a cable to the machine, so I'm no longer using the wireless card.  It was unstable enough that it was unusable, particularly remotely, and reliability was pretty critical at that point for a time-sensitive project I was working on.  I didn't have the free time to track down wireless driver problems, so pulling a cable was the quickest fix.

I guess, technically, I can't mark this one as [SOLVED], since my solution is not universally applicable  :Wink: 

jms

----------

## salahx

Actually I have a router, A d-link 615 with a simialr problem and uses a similar chipset (AR7240) which has the same problem. It has theis problem with both the OEM firmware and dd-wrt (both of which run Linux). After many, many attempts to remedy the problem of daily loss of wireless, I think I found the answer. It seems the problem is AES: Using WPA-TKIP it no longer drops (still evaluating, I made the change only 3 days ago).

----------

## richard.scott

I found that my issue was mostly due to either:

1) aerial on the client pointing the wrong way

2) Anything pre 3.1.4 kernels

I've changed the direction my aerial points to get the best "Link Quality" numbers in iwconfig i.e.

Link Quality=55/70

It seems much more stable now... oh and adding this to /etc/conf.d/modules

```
module_ath5k_args="nohwcrypt=1"
```

I'm not sure which one fixed it, but I think its the nohwcrypt thing.

Rich

----------

## greyspoke

The niceness didn't work but was nice (obviously).  I will try the other methods richard_scott - I think it is a driver (or driver setup) issue and there are general gripes about it on the internet.  Look there, it's doing it again as I type, but re-connected by the time I get to hit the "submit" button.  I've got 3.0.6 kernel and am using the ath9k driver, but I will have a go with those things.

----------

