# [SOLVED] ath9k/hostapd stops working after a while

## GD

Hello,

I've been able to set up an access point using ath9k and hostapd (using WPA2 encryption) but for some reason the client (a windows vista machine) will only have connectivity for a few minutes. After that period I have to restart hostapd for the client to be able to connect again. I'm using hostapd 0.6.9 and ath9k from the 2.6.31-rc6 kernel. The wlan0 and eth0 interfaces are bridged together in br0 (i have set the corresponding option in hostapd.conf for bridge operation).

Here's some output from hostapd -dd. During this output the client lost networking.

```
STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID

STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID

STA 00:19:d2:5c:66:c9 sent probe request for broadcast SSID

STA 00:19:d2:5c:66:c9 sent probe request for broadcast SSID

STA 00:22:fc:8f:ac:41 sent probe request for broadcast SSID

STA 00:22:fc:8f:ac:41 sent probe request for broadcast SSID

STA 00:22:fc:8f:ac:41 sent probe request for broadcast SSID

STA 00:22:fc:8f:ac:41 sent probe request for broadcast SSID

STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID

STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID

STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID

STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID

STA 00:19:d2:5c:66:c9 sent probe request for broadcast SSID

wlan0: WPA rekeying GTK

WPA: group state machine entering state SETKEYS (VLAN-ID 0)

GMK - hexdump(len=32): [REMOVED]

GTK - hexdump(len=16): [REMOVED]

WPA: 00:19:7e:0d:bb:8a WPA_PTK_GROUP entering state REKEYNEGOTIATING

wlan0: STA 00:19:7e:0d:bb:8a WPA: sending 1/2 msg of Group Key Handshake

WPA: Send EAPOL(version=2 secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=24 keyidx=2 encr=1)

Plaintext EAPOL-Key Key Data - hexdump(len=32): [REMOVED]

wpa_group_setkeys: GKeyDoneStations=1

wlan0: STA 00:19:7e:0d:bb:8a WPA: EAPOL-Key timeout

WPA: 00:19:7e:0d:bb:8a WPA_PTK_GROUP entering state REKEYNEGOTIATING

wlan0: STA 00:19:7e:0d:bb:8a WPA: sending 1/2 msg of Group Key Handshake

WPA: Send EAPOL(version=2 secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=24 keyidx=2 encr=1)

Plaintext EAPOL-Key Key Data - hexdump(len=32): [REMOVED]

wlan0: STA 00:19:7e:0d:bb:8a WPA: EAPOL-Key timeout

WPA: 00:19:7e:0d:bb:8a WPA_PTK_GROUP entering state REKEYNEGOTIATING

wlan0: STA 00:19:7e:0d:bb:8a WPA: sending 1/2 msg of Group Key Handshake

WPA: Send EAPOL(version=2 secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=24 keyidx=2 encr=1)

Plaintext EAPOL-Key Key Data - hexdump(len=32): [REMOVED]

wlan0: STA 00:19:7e:0d:bb:8a WPA: EAPOL-Key timeout

WPA: 00:19:7e:0d:bb:8a WPA_PTK_GROUP entering state REKEYNEGOTIATING

wlan0: STA 00:19:7e:0d:bb:8a WPA: sending 1/2 msg of Group Key Handshake

WPA: Send EAPOL(version=2 secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=24 keyidx=2 encr=1)

Plaintext EAPOL-Key Key Data - hexdump(len=32): [REMOVED]

wlan0: STA 00:19:7e:0d:bb:8a WPA: EAPOL-Key timeout

WPA: 00:19:7e:0d:bb:8a WPA_PTK_GROUP entering state REKEYNEGOTIATING

WPA: 00:19:7e:0d:bb:8a WPA_PTK_GROUP entering state KEYERROR

WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0)

WPA: 00:19:7e:0d:bb:8a WPA_PTK entering state DISCONNECT

hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA 00:19:7e:0d:bb:8a reason 2

WPA: 00:19:7e:0d:bb:8a WPA_PTK_GROUP entering state IDLE

WPA: 00:19:7e:0d:bb:8a WPA_PTK entering state DISCONNECTED

WPA: 00:19:7e:0d:bb:8a WPA_PTK entering state INITIALIZE

wlan0: STA 00:19:7e:0d:bb:8a IEEE 802.1X: unauthorizing port

wlan0: STA 00:19:7e:0d:bb:8a IEEE 802.11: deauthenticated due to local deauth request

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID

STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID

STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

STA 00:22:fc:8f:ac:41 sent probe request for broadcast SSID

STA 00:22:fc:8f:ac:41 sent probe request for broadcast SSID

STA 00:22:fc:8f:ac:41 sent probe request for broadcast SSID

STA 00:22:fc:8f:ac:41 sent probe request for broadcast SSID

STA 00:19:d2:5c:66:c9 sent probe request for broadcast SSID

STA 00:19:d2:5c:66:c9 sent probe request for broadcast SSID

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID

STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID

STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

Data/PS-poll frame from not associated STA 00:19:7e:0d:bb:8a

STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID

STA 00:19:7e:0d:bb:8a sent probe request for broadcast SSID
```

It seems the problem lies somewhere in the rekeying procedure? Is there a way I can fix this?

ThanksLast edited by GD on Mon Oct 19, 2009 1:05 pm; edited 1 time in total

----------

## rufnut

I have a similar problem too, but mine seems to re-key after a while (say 5 minutes)?

(my signal levels aren't great but i thought they were adequate at 33/70)

My client is a linux machine. Wondering if you have tried a linux client ?

Details:

(1 x ath9k in hostapd to 1 x ath9k client. kernels are 2.6.30-r4 hostapd and wpa_supplicant are 0.6.9

and both are WPA2 at "N" speeds)

Another thing that really upsets the connection, is to scan on the remote client.

 :Question: 

----------

## GD

Unfortunately i have no linux boxes with a wireless adapter available at the moment... I tried connecting with my phone (a nokia e65). It failed, but it has always had problems with WiFi.

Let me know if you find out anything

Thanks

----------

## Jords

I'm having a similar problem - but not sure if it's actually the same.

I've got the same setup of eth0 and wlan0 bridged into br0 - but I've noticed from using tcpdump that when the client has lost connectivity the packets show up when i run tcpdump on the wlan0 interface, but not the br0 interface - so i think the bridge is stopping working but ath9k/hostapd are not actually the problem.

Not sure why a bridge would stop though...

----------

## risa2000

I bump this thread with some observations - though no solutions  :Sad: .

I am currently pulling my hair on the same: trying to run AR5416 card in AP mode using hostapd on b/g ranges with WPA2. I have been using vanilla kernels 2.6.30.x, 2.6.31 and 2.6.31.1. So far I have figured out:

1) system hangs when I try to modprobe ath9k 7 times out of 10 (i.e. very often). When it does not hang, and I start hostapd it fails with error "interface already in use", then when I start hostapd again it magically starts.

I did not know why until I figured out that modprobing triggers my 

```
/etc/init.d/net.wlan0
```

 script. I have only one line in 

```
/etc/init.d/net
```

 related to wlan0: 

```
config_wlan0=( "192.168.2.10/24" )
```

 Everything else should be set by hostapd. After some experiments I found out that the line which kills the system is: 

```
ip link set wlan0 up
```

 So I stopped using gentoo net configuration (by removing /etc/init.d/net.wlan0 link), but I still need to: 

```
ip addr add 192.168.2.10/24 dev wlan0
```

 I do not know, how to do it properly (automated), ie. set IP but avoid setting interface up.

2) after some time, usually few minutes to hour maybe, the interface stops to work completely. I currently use iPod as client, so I do not have much diagnostics available on client side, but there is nothing unusual in log and AP is simply mute. The only way to "restart" is remove and load ath9k and do complete reinitialization.

3) sometimes I start to observe high activity (~4-10%) on si and hi in top (which disappears once I modprobe -r ath9k), even though there is no communication.

I have been trying different kernel profiles (server scheduler, voluntary and full preemptive, and also tickless system), but it seems there is no (big) difference, only on server scheduler it seems to be dying sooner. I have relatively old machine Intel Tualatin @1.5GHz, but since I connect only one client (iPod) I believe the load should not be an issue.

----------

## GD

hello all...

It seems the problem has been solved for me... I git pulled the latest zen-sources today (the unstable branch) and built the kernel image. I rebooted and hostapd would not start due to a number of errors. After a little bit of guesswork I commented out some options in hostapd.conf (namely beacon interval, rts and fragmentation threshold) to make hostapd start again (well it still complains but it starts nonetheless).

I had been browsing on my iphone for about 20 minutes before I saw this in the logs:

"Oct 11 05:46:35 om hostapd: wlan0: STA 00:26:b0:b2:c0:31 WPA: group key handshake completed (RSN)",

which is something i hadn't seen ever since i upgraded to an abgn atheros card and ath9k... I hope I won't run into any other problems with wifi soon..

I imagine the problem was within ath9k since I don't remember making any other changes to the server/ap apart from the usual emerge -uvDN stuff... There hasn't been a hostapd version bump during that period either. Maybe you guys could try with an unstable kernel as well (?2.6.32-rc3) to confirm?

----------

## rufnut

 *GD wrote:*   

> I commented out some options in hostapd.conf (namely beacon interval, rts and fragmentation threshold) to make hostapd start again (well it still complains but it starts nonetheless).
> 
> 

 

Thanks for the above tip I am trying a "wireless git" kernel now and had to do the same to get hostapd to start.

https://lists.ath9k.org/pipermail/ath9k-devel/2009-September/002474.html

Seems we are not the only ones happy now if you read that guys first line.

Looks good so far but I will have to update the client too in my case.

 :Smile: 

----------

## trikolon

I have the same strange porblems with my 5008 chip and the ath9k driver in master mode. 

what do u think about reactivation compat-wireless ebuild?

greets ben

----------

## trikolon

next try:

emerged layman

added pentoo overlay

emerged compat-wireless-2.6.32-rc1

i will report whether this fixed the connection lose error.

edit: the AP is now working stable for some hours.

----------

## rufnut

 *trikolon wrote:*   

> added pentoo overlay
> 
> 

 

Handy to know 

Mine has been running well since above 2.6.32

Thanks   :Smile: 

----------

## trikolon

next edit:

running kernel: gentoo-sources 2.6.31-r2

the AP is working for ~18h now without any problems.

i tested it with my iphone and my macbook.

greets

----------

## turtles

I am having problems with ath9k associating with a new access point. ( It is a Sprint MIFI ) Other computers can associate with it just fine eeepc running xandros and mac OSX.  I have turned all encryption / security off etc.

I keep getting DHCP time outs.

Is this what you all were experiencing?

I have set 

```
modprobe ath9k debug=0xffffffff
```

now I can see some output in dmesg

```
   37050.336924] ath9k: AR_IMR 0x918414b4 IER 0x1

[37050.439213] ath9k: 0xf4041071 => 0x0

[37050.439221] ath9k: disable IER

[37050.439231] ath9k: new IMR 0x0

[37050.439287] ath9k: 0x0 => 0xf4041071

[37050.439292] ath9k: new IMR 0x918414b4

[37050.439300] ath9k: enable IER

[37050.439308] ath9k: AR_IMR 0x918414b4 IER 0x1

```

if I 

```
mount -t debugfs debugfs /sys/kernel/debug/
```

I get these files in /sys/kernel/debug/ath9k/phy4 :

 dma  interrupt  rcstat  wiphy

I dont know what to look for.

pertanant lines from /etc/conf.d/net are:

```
config_wlan1="dhcp"

aps_wlan1=( "any" "Turtlevan" "Westphilly" )

preferred_aps_wlan1=( "Turtlevan" )

modules_wlan1=( "!ppp" )

```

EDIT I am running:

```
 2.6.30-gentoo-r6 #2 SMP Mon Oct 5 10:50:29 PDT 2009 i686 Intel(R) Celeron(R) CPU 2.60GHz GenuineIntel GNU/Linux
```

And ath9k is working my regular accesspoint.

----------

## overkll

For me, the only kernel versions that work consistently for the ath9k chip are 2.6.29 and 2.6.32.  All other versions of the driver are inconsistent or just total crap.  I'm sticking with 2.6.29 until 2.6.32 is deemed stable by kernel.org.

My two cents worth. (steps off soapbox)

----------

