# wlan0 randomly disconnects

## mechtech

Hi,

First off let me say, I'm new to gentoo but im loving it  :Very Happy:  . But i seem to be having problems getting the wireless working on my old compaq presario 900 laptop. I'm using a PCMCIA Cardbus linksys wpc100 card because the laptop doesn't have built-in wireless. I've compiled ath9k into the kernel and installed wpa_supplicant and wireless-tools. 

It connects but the problem I'm having is that after a short period of time (3-5 min) it will disconnect from my AP. I then have to iwconfig wlan0 essid "TheMatrix" (i need to change that  :Razz:  ) to get it started again. It is continually doing this. I am using WPA2. Here is some info about it:

lspci -k output

```

00:00.0 Host bridge: Advanced Micro Devices [AMD] nee ATI RS100 AGP Bridge [IGP 320M] (rev 13)

   Kernel driver in use: agpgart-ati

00:01.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI PCI Bridge [IGP 320M] (rev 01)

00:02.0 USB controller: ULi Electronics Inc. USB 1.1 Controller (rev 03)

   Subsystem: ULi Electronics Inc. ASRock 939Dual-SATA2 Motherboard

   Kernel driver in use: ohci_hcd

00:07.0 ISA bridge: ULi Electronics Inc. M1533/M1535/M1543 PCI to ISA Bridge [Aladdin IV/V/V+]

   Subsystem: ULi Electronics Inc. ALi M1533 Aladdin IV/V ISA Bridge

00:08.0 Multimedia audio controller: ULi Electronics Inc. M5451 PCI AC-Link Controller Audio Device (rev 02)

   Subsystem: Compaq Computer Corporation Device 00b0

   Kernel driver in use: snd_ali5451

00:0a.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02)

   Subsystem: Compaq Computer Corporation Device 00b0

   Kernel driver in use: yenta_cardbus

00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 20)

   Subsystem: Compaq Computer Corporation Device 00b0

   Kernel driver in use: 8139cp

00:0c.0 Communication controller: Conexant Systems, Inc. HSF 56k HSFi Modem (rev 01)

   Subsystem: Compaq Computer Corporation Device 8d88

00:0f.0 USB controller: ULi Electronics Inc. USB 1.1 Controller (rev 03)

   Subsystem: ULi Electronics Inc. ASRock 939Dual-SATA2 Motherboard

   Kernel driver in use: ohci_hcd

00:10.0 IDE interface: ULi Electronics Inc. M5229 IDE (rev c4)

   Subsystem: ULi Electronics Inc. M5229 IDE

   Kernel driver in use: pata_ali

00:11.0 Bridge: ULi Electronics Inc. M7101 Power Management Controller [PMU]

   Subsystem: ULi Electronics Inc. M7101 Power Management Controller [PMU]

01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS100 [Radeon IGP320M]

   Subsystem: Compaq Computer Corporation Device 00b0

   Kernel driver in use: radeonfb

02:00.0 Network controller: Atheros Communications Inc. AR5416 Wireless Network Adapter [AR5008 802.11(a)bgn] (rev 01)

   Subsystem: Linksys WPC100 v1 802.11n RangePlus Wireless Notebook Adapter

   Kernel driver in use: ath9k

```

Here is some dmesg output:

dmesg | grep ath9k

```

[    3.928323] ath9k 0000:02:00.0: enabling device (0000 -> 0002)

[    4.365316] ieee80211 phy0: Selected rate control algorithm 'ath9k_rate_control'

[    4.366597] Registered led device: ath9k-phy0

```

dmesg | grep wlan0

```

[  417.104817] ADDRCONF(NETDEV_UP): wlan0: link is not ready

[ 1138.086960] wlan0: authenticate with 0c:d5:02:6f:c7:b6 (try 1)

[ 1138.110818] wlan0: authenticated

[ 1138.110908] wlan0: associate with 0c:d5:02:6f:c7:b6 (try 1)

[ 1138.113316] wlan0: RX AssocResp from 0c:d5:02:6f:c7:b6 (capab=0x401 status=0 aid=5)

[ 1138.113323] wlan0: associated

[ 1138.113332] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[ 1138.113336] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[ 1138.113340] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 3

[ 1138.113568] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

[ 1148.578035] wlan0: no IPv6 routers present

[ 1633.556162] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[ 1633.556170] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[ 1633.556174] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 0

[ 2746.943432] wlan0: authenticate with 0c:d5:02:6f:c7:b6 (try 1)

[ 2746.965883] wlan0: authenticated

[ 2746.965991] wlan0: associate with 0c:d5:02:6f:c7:b6 (try 1)

[ 2746.968388] wlan0: RX AssocResp from 0c:d5:02:6f:c7:b6 (capab=0x401 status=0 aid=5)

[ 2746.968395] wlan0: associated

[ 2746.968405] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[ 2746.968408] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[ 2746.968413] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 3

[ 3143.509533] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[ 3143.509540] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[ 3143.509545] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 0

[ 4784.925410] wlan0: authenticate with 0c:d5:02:6f:c7:b6 (try 1)

[ 4784.948497] wlan0: authenticated

[ 4784.948580] wlan0: associate with 0c:d5:02:6f:c7:b6 (try 1)

[ 4784.952020] wlan0: RX AssocResp from 0c:d5:02:6f:c7:b6 (capab=0x401 status=0 aid=5)

[ 4784.952052] wlan0: associated

[ 4784.952249] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[ 4784.952254] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[ 4784.952259] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 3

[ 5178.581608] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[ 5178.581616] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[ 5178.581620] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 0

```

Any help would be awsome, 

Thanks

----------

## khayyam

mechtech ...

I don't see any disconnection, or any of the usual signs that the signal between the client and AP is lost, so at a guess it may be an issue is with the card going into powersave. Please try disabling power saving and see if the problem persists.

```
iwconfig wlan0 power off
```

If the issue continues, enable the 'debug' useflag on wpa_supplicant and add '-dd -f /var/log/wpa_supplicant.log' to  wpa_supplicant_wlan0= in /etc/conf.d/net and pastebin the log, and also provide the output of 'iwconfig wlan0'.

best ... khay

----------

## mechtech

Hey thanks for your help.

ok I feel like an idiot. I forgot that I turned off my WPA2 awhile back so im not using any encryption at the moment  :Embarassed:  . I followed your post and and disabled power management but it only made it worse. 

I have done some more testing. If i have power management on, i can keep the connection going using ping and just letting it run (it does drop some packets tho). I guess its acting as a "keep alive". If i have power management off and use ping again, it fails in a matter of seconds. Even if i don't use ping it still fails in the same amount of time. So far it has done this consistently. I've tried using some of the other power management options in iwconfig but they all give me weird errors. Only "off" and "on" work.

here is my full dmesg

http://pastebin.com/cjS0ahx8

and my iwconfig

```

wlan0     IEEE 802.11bgn  ESSID:"TheMatrix"  

          Mode:Managed  Frequency:2.437 GHz  Access Point: 0C:D5:02:6F:C7:B6   

          Bit Rate=54 Mb/s   Tx-Power=19 dBm   

          Retry  long limit:7   RTS thr:off   Fragment thr:off

          Encryption key:off

          Power Management:off

          Link Quality=70/70  Signal level=-40 dBm  

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:6   Missed beacon:0

```

a few seconds later...(barely got the first one)

```

wlan0     IEEE 802.11bgn  ESSID:off/any  

          Mode:Managed  Access Point: Not-Associated   Tx-Power=19 dBm   

          Retry  long limit:7   RTS thr:off   Fragment thr:off

          Encryption key:off

          Power Management:off

          

```

Thanks again   :Smile: 

----------

## khayyam

mechtech ...

Is CONFIG_PM_RUNTIME enabled in the kernel?

The effect of ping is what you'd expect, the driver is kept from going into powersave. Explicitly disabling powersave may infact cause the driver to balk as the cards power management features are software driven. I'm somewhat speculating but I'm inclined to think PM is at issue.

best ... khay

----------

## mechtech

No, as far as i can tell CONFIG_PM_RUNTIME is not set. I ran the commands...

```
mobilemech ~ # cd /usr/src/linux

mobilemech linux # cat .config | grep CONFIG_PM_RUNTIME

# CONFIG_PM_RUNTIME is not set

```

Do i need to add it? If so where is it in makeconfig?

Thanks again.

----------

## khayyam

 *mechtech wrote:*   

> 
> 
> ```
> # cat .config | grep CONFIG_PM_RUNTIME
> ```
> ...

 

mechtech ... avoid the useless use of cat

```
# grep CONFIG_PM_RUNTIME .config
```

 *mechtech wrote:*   

> Do i need to add it? If so where is it in makeconfig?

 

Yes, if you read the doc/help you will see that it enables power management features for I/O devices. It's under "Power management and ACPI options" as "Run-time PM core functionality". Note that when in menuconfig a "/" and search term (such as "PM_RUNTIME") will show you where in the kernel this item is located.

best ... khay

----------

## mechtech

It WORKS!  :Very Happy:   Thank you so much! I have power management turned on on the card and in the kernel now and it is working on my wpa2 network at work. I want to make sure it will work at home but its looking good so far. 

I will try not to uselessly use cat anymore   :Razz:  (I see now how it was redundant)

Thanks again!

Mechtech

----------

## mechtech

Ok it doesnt work on my home network. It stopped shortly after I started it (2.5 min). Now im really confused  :Confused:  . Im using wpa2 at work so maybe thats something. idk.

Thanks

Mechtech

----------

## mechtech

im not sure if its because im dumb and not seeing something or if its because there really is something wrong.

I made a wpa_supplicant config file with my home network in it and used it to start the connection. It seems to be working now.

maybe ive configured something wrong but im not sure

Thanks again

mechtech

----------

## mechtech

Another look at dmesg tho and its telling me that its reauthing every min or so. So wpa_supplicant is keeping it alive? Is that hows its supposed to work?

----------

## BillWho

mechtech,

This is all you should get from dmesg:

```
laptop linux # dmesg -T|grep wlan0

[Wed Oct  3 18:32:13 2012] ADDRCONF(NETDEV_UP): wlan0: link is not ready

[Wed Oct  3 18:32:15 2012] wlan0: authenticate with 58:6d:8f:88:43:45

[Wed Oct  3 18:32:15 2012] wlan0: send auth to 58:6d:8f:88:43:45 (try 1/3)

[Wed Oct  3 18:32:15 2012] wlan0: authenticated

[Wed Oct  3 18:32:15 2012] wlan0: associate with 58:6d:8f:88:43:45 (try 1/3)

[Wed Oct  3 18:32:15 2012] wlan0: RX AssocResp from 58:6d:8f:88:43:45 (capab=0x431 status=0 aid=1)

[Wed Oct  3 18:32:15 2012] wlan0: associated

[Wed Oct  3 18:32:15 2012] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

[Wed Oct  3 18:32:25 2012] wlan0: no IPv6 routers present

```

It's been running for about six hours   :Wink: 

----------

## mechtech

well mine defiantly isnt that...

```
[Wed Oct  3 17:16:38 2012] ADDRCONF(NETDEV_UP): wlan0: link is not ready

[Wed Oct  3 17:16:38 2012] wlan0: authenticate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:16:39 2012] wlan0: authenticated

[Wed Oct  3 17:16:39 2012] wlan0: associate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:16:39 2012] wlan0: RX AssocResp from 0c:d5:02:6f:c7:b6 (capab=0x401 status=0 aid=8)

[Wed Oct  3 17:16:39 2012] wlan0: associated

[Wed Oct  3 17:16:39 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:16:39 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:16:39 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 3

[Wed Oct  3 17:16:39 2012] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

[Wed Oct  3 17:16:49 2012] wlan0: no IPv6 routers present

[Wed Oct  3 17:17:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:17:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:17:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 0

[Wed Oct  3 17:17:16 2012] wlan0: authenticate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:17:16 2012] wlan0: authenticated

[Wed Oct  3 17:17:16 2012] wlan0: associate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:17:16 2012] wlan0: RX AssocResp from 0c:d5:02:6f:c7:b6 (capab=0x401 status=0 aid=8)

[Wed Oct  3 17:17:16 2012] wlan0: associated

[Wed Oct  3 17:17:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:17:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:17:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 3

[Wed Oct  3 17:18:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:18:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:18:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 0

[Wed Oct  3 17:18:16 2012] wlan0: authenticate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:18:16 2012] wlan0: authenticated

[Wed Oct  3 17:18:16 2012] wlan0: associate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:18:16 2012] wlan0: RX AssocResp from 0c:d5:02:6f:c7:b6 (capab=0x401 status=0 aid=8)

[Wed Oct  3 17:18:16 2012] wlan0: associated

[Wed Oct  3 17:18:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:18:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:18:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 3

[Wed Oct  3 17:19:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:19:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:19:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 0

[Wed Oct  3 17:19:16 2012] wlan0: authenticate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:19:16 2012] wlan0: authenticated

[Wed Oct  3 17:19:16 2012] wlan0: associate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:19:16 2012] wlan0: RX AssocResp from 0c:d5:02:6f:c7:b6 (capab=0x401 status=0 aid=8)

[Wed Oct  3 17:19:16 2012] wlan0: associated

[Wed Oct  3 17:19:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:19:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:19:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 3

[Wed Oct  3 17:20:12 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:20:12 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:20:12 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 0

[Wed Oct  3 17:20:13 2012] wlan0: authenticate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:20:13 2012] wlan0: authenticated

[Wed Oct  3 17:20:13 2012] wlan0: associate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:20:13 2012] wlan0: RX AssocResp from 0c:d5:02:6f:c7:b6 (capab=0x401 status=0 aid=8)

[Wed Oct  3 17:20:13 2012] wlan0: associated

[Wed Oct  3 17:20:13 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:20:13 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:20:13 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 3

[Wed Oct  3 17:21:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:21:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:21:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 0

[Wed Oct  3 17:21:16 2012] wlan0: authenticate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:21:16 2012] wlan0: authenticated

[Wed Oct  3 17:21:16 2012] wlan0: associate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:21:16 2012] wlan0: RX AssocResp from 0c:d5:02:6f:c7:b6 (capab=0x401 status=0 aid=8)

[Wed Oct  3 17:21:16 2012] wlan0: associated

[Wed Oct  3 17:21:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:21:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:21:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 3

[Wed Oct  3 17:28:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:28:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:28:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 0

[Wed Oct  3 17:28:16 2012] wlan0: authenticate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:28:17 2012] wlan0: authenticate with 0c:d5:02:6f:c7:b6 (try 2)

[Wed Oct  3 17:28:17 2012] wlan0: authenticated

[Wed Oct  3 17:28:17 2012] wlan0: associate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:28:17 2012] wlan0: RX AssocResp from 0c:d5:02:6f:c7:b6 (capab=0x401 status=0 aid=8)

[Wed Oct  3 17:28:17 2012] wlan0: associated

[Wed Oct  3 17:28:17 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:28:17 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:28:17 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 3

[Wed Oct  3 17:31:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:31:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:31:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 0

[Wed Oct  3 17:31:16 2012] wlan0: authenticate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:31:16 2012] wlan0: authenticated

[Wed Oct  3 17:31:16 2012] wlan0: associate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:31:16 2012] wlan0: RX AssocResp from 0c:d5:02:6f:c7:b6 (capab=0x401 status=0 aid=8)

[Wed Oct  3 17:31:16 2012] wlan0: associated

[Wed Oct  3 17:31:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:31:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:31:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 3

[Wed Oct  3 17:36:31 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:36:31 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:36:31 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 0

[Wed Oct  3 17:36:32 2012] wlan0: authenticate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:36:32 2012] wlan0: authenticated

[Wed Oct  3 17:36:32 2012] wlan0: associate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:36:32 2012] wlan0: RX AssocResp from 0c:d5:02:6f:c7:b6 (capab=0x401 status=0 aid=8)

[Wed Oct  3 17:36:32 2012] wlan0: associated

[Wed Oct  3 17:36:32 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:36:32 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:36:32 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 3

[Wed Oct  3 17:38:35 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:38:35 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:38:35 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 0

[Wed Oct  3 17:38:36 2012] wlan0: authenticate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:38:36 2012] wlan0: authenticated

[Wed Oct  3 17:38:36 2012] wlan0: associate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:38:36 2012] wlan0: RX AssocResp from 0c:d5:02:6f:c7:b6 (capab=0x401 status=0 aid=8)

[Wed Oct  3 17:38:36 2012] wlan0: associated

[Wed Oct  3 17:38:36 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:38:36 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:38:36 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 3

[Wed Oct  3 17:46:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:46:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:46:15 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 0

[Wed Oct  3 17:46:16 2012] wlan0: authenticate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:46:16 2012] wlan0: authenticated

[Wed Oct  3 17:46:16 2012] wlan0: associate with 0c:d5:02:6f:c7:b6 (try 1)

[Wed Oct  3 17:46:16 2012] wlan0: RX AssocResp from 0c:d5:02:6f:c7:b6 (capab=0x401 status=0 aid=8)

[Wed Oct  3 17:46:16 2012] wlan0: associated

[Wed Oct  3 17:46:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 1

[Wed Oct  3 17:46:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 2

[Wed Oct  3 17:46:16 2012] wlan0: moving STA 0c:d5:02:6f:c7:b6 to state 3

```

----------

## BillWho

Try starting it in a term, maybe the debug messages will provide a clue

```
wpa_supplicant -iwlan0 -Dwext -d -c/etc/wpa_supplicant/wpa_supplicant.conf
```

----------

## khayyam

 *BillWho wrote:*   

> Try starting it in a term, maybe the debug messages will provide a clue

 

BillWho ... you only get debug info if the debug useflag is set (which it isn't by default).

 *machtech wrote:*   

> Another look at dmesg tho and its telling me that its reauthing every min or so. So wpa_supplicant is keeping it alive? Is that hows its supposed to work?

 

mechtech ... no, it should only re-authenticate if the signal is lost.

Can you post the wpa_supplicant.conf entry for this network, and the output of the following command (obviously subsitituting 'ESSID' for the broadcast name of your access point.)

```
# awk '{RS="Cell"}/ESSID/' <(iwlist wlan0 scan)
```

best ... khay

----------

## mechtech

Thanks both of you. 

Here is my wpa_supplicant.conf

```
ctrl_interface=/var/run/wpa_supplicant

ctrl_interface_group=0

ap_scan=1

country=US

network={

   ssid="TheMatrix"

#   psk="****"

   key_mgmt=NONE

   priority=1

}

network={

   ssid="7706 2650"

   psk="****"

   priority=2

}

```

I just looked to see if i had a wpa_supplicant in /var/run and i do not.

first network is my home

second is work

here is the output of awk '{RS="Cell"}/ESSID/' <(iwlist wlan0 scan)

```
01 - Address: 0C:D5:02:6F:C7:B6

                    Channel:6

                    Frequency:2.437 GHz (Channel 6)

                    Quality=60/70  Signal level=-50 dBm  

                    Encryption key:off

                    ESSID:"TheMatrix"

                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s

                              24 Mb/s; 36 Mb/s; 54 Mb/s

                    Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 48 Mb/s

                    Mode:Master

                    Extra:tsf=0000034c4b7227f7

                    Extra: Last beacon: 356ms ago

                    IE: Unknown: 00095468654D6174726978

                    IE: Unknown: 010882848B962430486C

                    IE: Unknown: 030106

                    IE: Unknown: 2A0100

                    IE: Unknown: 2F0100

                    IE: Unknown: 32040C121860

                    IE: Unknown: 

                    IE: Unknown: DD090010180209F0000000

```

I tried starting wpa_supplicant with debuging but it wouldnt let me use the -f/var/log/wpa_supplicant. I used...

```
wpa_supplicant -dd -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf -Dwext -f/var/log/wpa_supplicant.txt
```

Thanks again

mechtechLast edited by mechtech on Thu Oct 04, 2012 6:10 am; edited 1 time in total

----------

## khayyam

mechtech ...

firstly, encryption is disabled on the AP, this is inadvisable, with such a setup it is trivial to sniff the psk and any other network traffic passing between the client and the AP. I'd suggest you enable WPA and configure the client to use it.

```
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel

network={

    ssid="TheMatrix"

    bssid=0C:D5:02:6F:C7:B6

    scan_ssid=0

    proto=WPA2

    key_mgmt=WPA-PSK

    group=CCMP TKIP

    pairwise=CCMP TKIP

    psk=63_char_random_string

}
```

I'd hoped that the above output might provide some misconfiguration, but nothing there to suggest it should randomly disconnect. However, re powersave is CONFIG_CFG80211_DEFAULT_PS also enabled?

Also, the AP (Westell) seems to be a 802.11g am I correct?

best ... khay

ps. can you edit the above post and remove/break the long "IE: Unknown:" line as its causing the page to break format

----------

## mechtech

I was planing on setting up WPA2 again but just never got around to it. I might as well fix that tomorrow (have alot of devices using it atm) 

```
mobilemech linux # grep CONFIG_CFG80211_DEFAULT_PS .config

grep: CONFIG_CFG80211_DEFAULT_PS=y
```

Yes it is a 802.11g modem/router.

Should i use something similar to the code you linked in my wpa_supplicant.conf? wpa_supplicant doesn't start automatically.

----------

## khayyam

 *mechtech wrote:*   

> Yes it is a 802.11g modem/router.

 

mechtech ... the reason I asked is that your PCI card is 802.11n and I have in the past seen issues with mixed g/n networks (but this is not the most likely issue).

 *mechtech wrote:*   

> Should i use something similar to the code you linked in my wpa_supplicant.conf? wpa_supplicant doesn't start automatically.

 

Yes, I provided the above as an example WPA2 network configuration. Rather than start wpa_supplicant from init you should simply define wpa_supplicant as the 'module' handling the interface (in /etc/conf.d/net) eg:

```
modules_wlan0="!plug wpa_supplicant dhcpcd"

wpa_supplicant_wlan0="-Dnl80211"

wpa_timeout_wlan0="15"

config_wlan0="dhcp"

dhcpcd_wlan0="-t 10"
```

You would then link /etc/init.d/net.lo to /etc/init.d/net.wlan0 and use that to start the service (which will then start wpa_supplicant, dhcpcd, etc).

As CFG80211_DEFAULT_PS is currently enabled please try disabling it, the symptoms currently suggest powersave as the most likely issue.

Also, previously I showed how to enable debugging with wpa_supplicant, if the issue persists after disabling CFG80211_DEFAULT_PS then please enable the debug useflags, re-merge, connect, and post the log.

best ... khay

----------

## mechtech

I've recompiled with that option off and it does the same thing. I recompiled again with CONFIG_PM_RUNTIME=n as well just to see but no change. It is almost always reconnecting every 60 seconds UNLESS I turn on power management on the card with

```
iwconfig wlan0 power on
```

If i use that it will reconnect less often and never (so far) while in use. I haven't yet tested it with a streaming application. 

I resetup my /etc/conf.d/net like you said and use 

```
net.wlan0 start
```

to start it now

here is my wpa_supplicant.log. Hopfully it helps.

http://pastebin.com/cn31pqWB

Thanks

mechtech

----------

## khayyam

mechtech ...

When you say "UNLESS I turn on power management" you mean with PS enabled the issue is decreased, and if so how often do the disconnects occur with PS enabled?

```
CTRL-EVENT-DISCONNECTED bssid=0c:d5:02:6f:c7:b6 reason=4
```

This "reason=4" means disassociated due to inactivity, but there is no clue given as to why, but my guess is a beacon miss. It would be good to know if the STA (client) or AP is the cause, but getting this requires that CONFIG_ATH_DEBUG is enabled (well, with ath5k it would be CONFIG_ATH5K_DEBUG, and as I don't see similar for ath9k I assume the above will suffice). With debug enabled you should be able to do the following:

```
# echo 0xc80000 > /proc/sys/net/wlan0/debug
```

... and read the debug in dmesg or /var/log/messages. If its a beacon miss you would see it there, and which end of the connection is the cause.

However, before trying the above we might try increasing beacon misses ... this is not a fix, as I really can't say what the exact cause is, but it should make the connection less inclined to drop due to beacon misses. Doing this however is not really a good idea as the reason for such a setting is to detect when a signal is unavailable (and so close the connection), still, if this fixes it we know that beacon misses are the reason the disassoc happens.

I see from the above dmesg that your using 3.3.8-gentoo, so before doing any of the above it might be an idea to build 3.5.4 as the problem may be fixed in a more recent kernel.

So, to change beacon misses edit /usr/src/linux-{version}/drivers/net/wireless/ath/ath9k and change the value of #define ATH_DEFAULT_BMISS_LIMIT ... its probably set to 10, change it to 20.

Again, it may be that this issue is fixed so before trying to work out the exact cause it is probably a good idea to try a more recent kernel, as what I'm suggesting above is really more of an attempt at getting at the cause than a possible fix.

best ... khay

----------

## mechtech

Ive just compiled 3.6.0 now and am running it.

 *Quote:*   

> When you say "UNLESS I turn on power management" you mean with PS enabled the issue is decreased, and if so how often do the disconnects occur with PS enabled? 

 

If i keep power management on with iwconfig, the time between disconnects goes from every 30-120sec to around 10-15min. And from what i can see it wont disconnect if its in use (e.g. emerge, ping). That almost makes it a non issue from what i can see. When i was running 3.3.8 with power managment on it was around 3-5 min between drops so something changed in the new kernel or in how i configured it.

I tried to use

```
echo 0xc80000 > /proc/sys/net/wlan0/debug
```

but I dont have a wlan0 in /proc/sys/net folder. I therefor haven't tried messing with the becon miss limit.

Im going to let it run overnight and I'll post the logs for it tomorrow

Thanks

EDIT:

LOGS

https://gist.github.com/3844391 dmesg

https://gist.github.com/3844390 wpa_supplicant

----------

## khayyam

mechtech ...

Its getting difficult for me to follow what your doing, and though I can't say for certain that powersave is the problem it seems like the most likely cause given the symptoms.

Please try booting with pci=noacpi as a boot parameter and see if the problem persists.

best ... khay

----------

## mechtech

Sorry for the confusion. 

I tried pci=noacpi but it gave me a kernel panic.

I'm noticing that it is very inconsistent between re-associations. Sometimes 3 min, other times 20 min. 

Thanks

mechtech

----------

## khayyam

 *mechtech wrote:*   

> Sorry for the confusion.

 

mechtech ... I mean't for example in the above, does the /proc/sys/net/ exist when CONFIG_ATH_DEBUG is enabled ... or not, I can't tell from your reply.

 *mechtech wrote:*   

> I tried pci=noacpi but it gave me a kernel panic.

 

OK, I'd hoped it'd at least boot, though running without ACPI is not really any kind of fix. Anyhow, with regard to CFG80211_DEFAULT_PS and CONFIG_PM_RUNTIME I can't tell from the above what was tried, only that one or other doesn't work. I'd suggest having both enabled, and then enabling/disabling powersave, via i'wconfig wlan0 power (on|off)', test, and then disable one or other, test, disable both, test .. etc.

Also, I just noticed in the above your passing '-Dwext' to wpa_supplicant, your should try with '-Dnl80211'.

 *mechtech wrote:*   

> I'm noticing that it is very inconsistent between re-associations. Sometimes 3 min, other times 20 min.

 

This doesn't tell us anything ... 

best ... khay

----------

## mechtech

Ok ive been working on this over the past couple weeks and still have nothing. I've tried different variations of the power management options in the kernel like you suggested, but it still does the same thing. Dmesg is reporting a new error though:

```
...

phy0: Failed to stop TX DMA, queues=0x001!

...

```

But it looks like they fixed the issue Here.

I've since installed xfce and a new network manager so iwconfig and wpa_supplicant are not in use anymore but the issue still persists. 

/proc/sys/net/ does not exist when CONFIG_ATH_DEBUG is enabled from what i can remember but i will double check that.

----------

## khayyam

 *mechtech wrote:*   

> Ok ive been working on this over the past couple weeks and still have nothing. I've tried different variations of the power management options in the kernel like you suggested, but it still does the same thing.

 

mechtech ... I'm simply going by the information you provide, the better the information the better equiped I am to debug it.

 *mechtech wrote:*   

> Dmesg is reporting a new error though:
> 
> ```
> phy0: Failed to stop TX DMA, queues=0x001!
> ```
> ...

 

... which *may* be the result of PS/PM having been disabled, however I can't tell as I have no idea of what kernel options were enabled/disabled, or if NetworkMunger was running, etc, etc, when this error occured.

 *mechtech wrote:*   

> I've since installed xfce and a new network manager so iwconfig and wpa_supplicant are not in use anymore but the issue still persists.

 

... and your assumption would be wrong, NetworkManager is just a frontend, it still uses wpa_supplicant for authentication.

 *mechtech wrote:*   

> /proc/sys/net/ does not exist when CONFIG_ATH_DEBUG is enabled from what i can remember but i will double check that.

 

As I said previously, I'm not sure if this option works with ath9k (I have an ath5k), but you will have a /proc/sys/net/ none the less. Anyhow, as you previously stated that "It WORKS!", but not with your home network, we can assume that its not powersave that is at issue, but something related to this network alone. So, again, you need to provide better information, like the specifics of the network (A,G,N ... G,N ... N only), if the AP is 'hidden', using WDS, QoS/WMM, etc, etc.

Also, does 'iwconfig wlan0' show high bitrates (ie > 54 Mb/s)

best ... khay

----------

## Logicien

Hello,

I try to use more effeciently the Linux kernel built-in keepalive fonctionnality. It have reduce the latency when I connect to a web site with my browser after an idle period. The three keys concerned are

```
net.ipv4.tcp_keepalive_intvl = 15

net.ipv4.tcp_keepalive_probes = 5

net.ipv4.tcp_keepalive_time = 5
```

A keepalive message is send after only 5 seconds of idle time and resend every 5 seconds. The kernel try 5 times to receice an answer before it consider the other point of the link disconnected. These values are only for test, has I could probably wait longer before the kernel send a keepalive message.

I have Internet on a cellular network and my local network is wireless with WPA2 version 1. So, if it help me in this network configuration, it could possibly help to keep a WPA connexion alive and advoid to use the ping command has I did before to reduce respond time after idle.

The values of the keepalive kernel options must be checked.

----------

## khayyam

Logicien ...

I wouldn't suggest they adjust keepalive values as the problem is not wtih the transport layer but the link layer, it may (possibly) have some noticable effect but the underlying issue isn't addressed. In terms of wireless connectivity the radio transmission will determine the connection (assoc, disassoc) and so whatever the keepalive values the connection may still drop. So, really the question is why the link is dropping, and this is why I asked about the specific network, and what 'bitrate' the STA (client) was set to. This can then be lowered and so (hopefully) the connection stablised.

eg: /etc/conf.d/net

```
rate_wlan0="5.5M auto"
```

... values of 1 Mb/s, 2 Mb/s, 5.5 Mb/s, 11 Mb/s, 18 Mb/s, 24 Mb/s, 36 Mb/s, 54 Mb/s, 6 Mb/s, 9 Mb/s, 12 Mb/s, 48 Mb/s, etc can all be tried (dependent on what the AP and STA support). I've seen N cards with > 140 Mb/s which will mean tighter packed data and so the potencial for data loss (and subsequently disassoc).

besides setting the bitrate in /etc/conf.d/net it can be set manually via iwconfig (or iw)

```
# iwconfig eth0 rate 5.5M auto
```

So, I'd asked specifically about the network, and what bitrates iwconfig were reporting as that would be my next suggestion, but you've somewhat preempted me :)

best ... khay

ps. Logician's suggestions above are using /etc/sysctl.conf (which may not have been clear). See tcp keepalive HOWTO for further info.

----------

## Logicien

 *mechtech wrote:*   

> I have done some more testing. If i have power management on, i can keep the connection going using ping and just letting it run (it does drop some packets tho). I guess its acting as a "keep alive". 

 

That's the reason why I think calibrating keepalive in the kernel can help. It did for me about respond after idle time and to not have pppd die. I modified permently the keepalive variables yes, in /etc/sysctl.conf.

The disassociation can have others causes like data rate. I do not think keepalive can be useless, at least it should be more occurate then the ping.

Note that the two points of my WPA links are Linux, Hostapd/Dnsmasq for server and wpa_supplicant/dhclient/dhcpcd for clients.  I am never/rarely disconnected. The Bit Rate is 54 Mb/s on channel 2. Both links are bgn capables. Channel 2 is alone in the wireless neighberhood. So, on server side, the channel choose must be free if possible. 

This is my connexion client configuration

```
iwconfig wlan0

wlan0     IEEE 802.11bgn  ESSID:"Quebec"  

          Mode:Managed  Frequency:2.417 GHz  Access Point: C8:3A:35:C5:6B:D9   

          Bit Rate=54 Mb/s   Tx-Power=27 dBm   

          Retry  long limit:7   RTS thr:off   Fragment thr:off

          Power Management:off

          Link Quality=70/70  Signal level=-37 dBm  

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:13  Invalid misc:117   Missed beacon:0
```

----------

## khayyam

 *Logicien wrote:*   

>  *mechtech wrote:*   I have done some more testing. If i have power management on, i can keep the connection going using ping and just letting it run (it does drop some packets tho). I guess its acting as a "keep alive". 
> 
> That's the reason why I think calibrating keepalive in the kernel can help. It did for me about respond after idle time and to not have pppd die.

 

Logicien ... yes, but again its not the transport layer but the link layer that is the cause of the connection dropping. The ping/keepalive may add some level of stability because the traffic will cause an auto-negociation of bitrates to occur on the link, but if this can be fixed at the link level then the keepalive isn't needed.

 *Logicien wrote:*   

> The disassociation can have others causes like data rate. I do not think keepalive can be useless, at least it should be more occurate then the ping.

 

It is "useless" however if the issue can be fixed at the cause, and I'm fairly sure the cause is at the link layer.

 *Logicien wrote:*   

> Note that the two points of my WPA links are Linux, Hostapd/Dnsmasq for server and wpa_supplicant/dhclient/dhcpcd for clients.  I am never/rarely disconnected. The Bit Rate is 54 Mb/s on channel 2. Both links are bgn capables. Channel 2 is alone in the wireless neighberhood. So, on server side, the channel choose must be free if possible.

 

OK, but this setup may not reflect that of the OP, I have seen clients with N cards whos bitrate is (auto-configured) in excess of 140Mb/s and as I stated higher bitrates equate to data being more more tightly packed and so more prone to error. So, there are other factors to be considered, such as how the AP is configured, the specific driver (kernel version, firmware, etc), ambient factors (location, weather, adjacent networks, etc). 

 *Logicien wrote:*   

> This is my connexion client configuration
> 
> ```
> iwconfig wlan0
> 
> ...

 

... and your link quaility and signal level is good, I imagine bitrate auto-negociation rarely happens, or the STA never misses a beacon, but if you were to increase the bitrate to an inappropriately high value your client would no doubt be much more prone to disassoc, and that is my point.

best ... khay

----------

## Logicien

I agree with you khayyam. It would be better to fix the link level than artificially keep the connexion alive with data transferts at the transport level. 

In a public Access Point, with no encryption, key off, I only have to do a dhcp request to be connected to the Internet. No browser connexion is needed.The problem occur when I am disconnected from the AP. Even if I ping the AP, I am periodically disconnected. Next time I will try to reduce the bitrate and see if I stay connected longer.

Note that reduce the bitrate mean that the data transferts will take more time, everething equal, and will help to keep the connnexion alive by reducing the idle time. So it have to do with the transport level according to my understanding.

----------

## khayyam

 *Logicien wrote:*   

> In a public Access Point, with no encryption, key off, I only have to do a dhcp request to be connected to the Internet. No browser connexion is needed. The problem occur when I am disconnected from the AP. Even if I ping the AP, I am periodically disconnected. Next time I will try to reduce the bitrate and see if I stay connected longer.

 

Logicien ... its probably not a good idea to discuss this here as the thread really should focus on the OP's problem. However, a lot of changes to mac80211 seem to be in progress (from > 3.5.x) and I myself have noticed a slight increase in instability, and some minor oddities (like channel hopping being tempremental). Hopefully this will be improved in time.

 *Logicien wrote:*   

> Note that reduce the bitrate mean that the data transferts will take more time, everething equal, and will help to keep the connnexion alive by reducing the idle time. So it have to do with the transport level according to my understanding.

 

Bitrate is a trade-off between speed and stability ... but as no card is every sold on the premise of 'stability', the claims made, besides being misleading, are mostly about vendors making that trade-off so they can advertise stupid speeds on the box. If I understand you correctly I'd have to say your wrong, bitrate is operating at the link level, but of course what happens in the transport layer will have a knock on effect at the link layer (as we see with ping/keepalive causing the auto-negociation of bitrate to work harder and so keep the link active).

best ... khay

----------

