Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #1004 (new defect)

Opened 15 years ago

Last modified 12 years ago

Client kicked out by AP after random time intervals

Reported by: Marek Assigned to:
Priority: major Milestone:
Component: madwifi: driver Version:
Keywords: Cc:
Patch is attached: 0 Pending:

Description

I posted this info as a follow up to #942, but i guess that one was considered closed and thats why no response there. I'f i'm wrong please forgive me. I have problems with simple setup - both AP and client are using madwifi-ng recent version (a few days old). The client is using wpa_supplicant and connects without problems to various networks, so i expect the fault is on the AP side.

I have set up an open access AP with no daemon running:

iface ath0 inet static
        pre-up          wlanconfig ath0 create wlandev wifi0 wlanmode ap
        post-down       wlanconfig ath0 destroy
        address         10.0.1.1
        netmask         255.255.255.0
        wireless-mode   master
        wireless-channel 7
        wireless-essid  myssid

yet, when i try to connect to this AP with the client i receive:

...
Wireless event: cmd=0x8b1a len=17
Wireless event: cmd=0x8b15 len=20
Wireless event: new AP: 00:0e:2e:90:50:34
State: ASSOCIATING -> ASSOCIATED
Associated to a new BSS: BSSID=00:0e:2e:90:50:34
Associated with 00:0e:2e:90:50:34
WPA: Association event - clear replay counter
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
EAPOL: External notification - portEnabled=1
EAPOL: SUPP_PAE entering state S_FORCE_AUTH
EAPOL: SUPP_BE entering state IDLE
Cancelling authentication timeout
Removed BSSID 00:0e:2e:90:50:34 from blacklist
State: ASSOCIATED -> COMPLETED
CTRL-EVENT-CONNECTED - Connection to 00:0e:2e:90:50:34 completed (reauth)
RTM_NEWLINK, IFLA_IFNAME: Interface 'ath0' added

<<< and then after some time... >>>

Wireless event: cmd=0x8b15 len=20
Wireless event: new AP: 00:00:00:00:00:00
Setting scan request: 0 sec 100000 usec
Added BSSID 00:0e:2e:90:50:34 into blacklist
State: COMPLETED -> DISCONNECTED
EAPOL: External notification - portEnabled=0
EAPOL: SUPP_PAE entering state DISCONNECTED
EAPOL: SUPP_BE entering state INITIALIZE
EAPOL: External notification - portValid=0
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
RTM_NEWLINK, IFLA_IFNAME: Interface 'ath0' added
State: DISCONNECTED -> SCANNING

apparently the client receives the new AP event with zeroed MAC (disconnection) but this must come from the madwifi driver, as like i said there is no daemon (like hostapd) running on the AP. i have tried various snapshots of madwifi-ng on the AP, but with no luck. any thoughts about how to find out the core of the problem?

any help will be really aprreciated

Marek Zachara

Change History

02/27/07 22:23:13 changed by patrick_b@patrickbueker.de

I've got the same problem with MadWifi in debian (etch).

Is it a Madwifi or wpa_supplicant problem?

03/20/07 10:32:58 changed by Žilvinas Valinskas <valins@soften.ktu.lt>

I think there is a problem in madwifi-ng driver and not in wpa_supplicant. Consider this other drivers then madwifi, does not show this problem yet wpa_supplicant binary is used the same! For example ipw3945 or ipw2200 driver doesn't exhibit such problem at all.

03/20/07 10:48:07 changed by Žilvinas Valinskas <valins@soften.ktu.lt>

Doh, i will try to explain better.

Madwifi-NG driver sends disassoc event regardless if STA was associated already or not. When wpasupplicant is started first time it scans, then issues assoc and attempts to authenticate. By the time authentication has finished wpasupplicant will receive 'disassoc' event (although it just had connected for first time! how come we are getting disconnect ?). Problem with disconnect event that it is useless, mac address in event is '00:00:00:00:00:00'. so wpasupplicant assume that AP (we have just associated) kicked out us for some reason ... Which is unlikely, wpasupplicant had just associated ! There is not previous AP at all.

Then wpasupplicant blacklist AP for some time, scans -> assoc -> auth ... 2nd time authentication goes through !

03/21/07 12:33:56 changed by Žilvinas Valinskas <valins@soften.ktu.lt>

Correct me if I am wrong - in your case you are using wpasupplicant to associate to an AP (that is not encryption was used, "open" mode). Yet you see that STA (client computer) is loosing connection with an AP.

If so it can be related to transmit power (perhaps too low ?) on AP. iwlist ath0 txpower on STA or AP ? :\ Perhaps client is loosing connection due to idling ? (5min no data from STA <-> AP ?) Or so.

Other thing you can do on AP and STA, so that you get a better picture who is doing what (for example either AP is kicking client or STA is leaving BSSID) and etc. Beacon misses can be a problem too - that is most likely the cause in your case.

# echo 0xc80000 > /proc/sys/net/ath0/debug
# dmesg -n8

For example:

wpasuplicant was terminated by C, on AP there should such message:

[   65.124000] ath0: [00:90:4b:00:01:29] recv disassociate (reason 8)
                      ^^^^^^^^^^^^^^^^^ my STA is telling AP that it is leaving BSSID 

and etc.

03/21/07 12:36:00 changed by Žilvinas Valinskas <valins@soften.ktu.lt>

wpasuplicant was terminated by hitting ^C as a result on AP there should such message:

[   65.124000] ath0: [00:90:4b:00:01:29] recv disassociate (reason 8)

05/04/07 18:16:00 changed by anonymous

I have this problem. It drives me insane. No idea what causes the disconnect event - other wireless systems stay connected to the same AP fine. Anything that can be done?

05/12/07 21:22:23 changed by anonymous

I have this problem using ndiswrapper on the client (Fedora Core 5 with kernal built for 16k stack), AP is an Apple Airport Extreme Base station with WPA-PSK TKIP. Using an SMC AP at the same location I don't see the problem.

I don't think it is a weak signal issue as the signal strength for the 2 AP's is similar.

iwconfig always shows 'Missed beacon:0'

06/14/07 14:20:32 changed by Marek Zachara

I had not seen any response to my post for a few weeks so i abandoned checking it up. I have solved my problem but in a way that will not shed much light on it - i have replaced the wifi card in my AP with a prism-based one and right now everything works fine (i get disconnection like once a few hours but that is acceptable). I'm sorry i couldnt help you track down the problem but i just had to find some solution asap - and in this case changing the AP helped.

06/19/07 20:03:23 changed by gonzhauser@yahoo.de

I have the same problem with madwifi from svn. The drivers included in Ubuntu work fine. If there is any help in the form of data I can provide I would be happy to do so.

06/20/07 04:37:13 changed by giovannibajo@gmail.com

I have a very similar problem with wpa_supplicant but without the madwifi drivers (using wext). I reckon this is a wpa_supplicant bug, not a madwifi one...

(follow-up: ↓ 12 ) 12/09/07 03:46:03 changed by kevmitch@gmail.com

I am also experiencing this problem on an AR1518 chip with the latest svn (3012) as well all svns I have downloaded dating back at least as far as 2708. After a few minutes of connectivity, I am summarily disconnected from the AP. There is a possibility that this is loosely correlated with how busy the AP is. It happens frequently in coffee shops where there are many people using the wireless and less frequently on the same AP's in the wee hours of the morning when fewer people are around. It never happens on my home AP where I am the sole client.

It is not a wpa_supplicant problem as it is not observed while using ndiswrapper. Below is the temporally relevant output from running wpa_supplicant -D madwifi -dd -i wlan0 -c /etc/network/wpa_supplicant.conf:

.
.
.
RX ctrl_iface - hexdump_ascii(len=6):
     53 54 41 54 55 53                                 STATUS          
RX ctrl_iface - hexdump_ascii(len=4):
     50 49 4e 47                                       PING            
RX ctrl_iface - hexdump_ascii(len=4):
     50 49 4e 47                                       PING            
RX ctrl_iface - hexdump_ascii(len=4):
     50 49 4e 47                                       PING            
RX ctrl_iface - hexdump_ascii(len=4):
     50 49 4e 47                                       PING            
RX ctrl_iface - hexdump_ascii(len=4):
     50 49 4e 47                                       PING            
RX ctrl_iface - hexdump_ascii(len=4):
     50 49 4e 47                                       PING            
RX ctrl_iface - hexdump_ascii(len=4):
     50 49 4e 47                                       PING            
RX ctrl_iface - hexdump_ascii(len=4):
     50 49 4e 47                                       PING            
RX ctrl_iface - hexdump_ascii(len=4):
     50 49 4e 47                                       PING            
RX ctrl_iface - hexdump_ascii(len=4):
     50 49 4e 47                                       PING            
RX ctrl_iface - hexdump_ascii(len=6):
     53 54 41 54 55 53                                 STATUS          
RTM_NEWLINK: operstate=1 ifi_flags=0x1043 ([UP][RUNNING])
Wireless event: cmd=0x8b15 len=20
Wireless event: new AP: 00:00:00:00:00:00
Setting scan request: 0 sec 100000 usec
Added BSSID 00:18:f8:34:89:b0 into blacklist
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL_IFACE monitor send - hexdump(len=23): 2f 74 6d 70 2f 77 70 61 5f 63 74 72 6c 5f 38 35 35 33 2d 35 34 34 00
State: COMPLETED -> DISCONNECTED
.
.
.

At the same time, I followed the above advice and did an echo 0xc80000 > /proc/sys/net/wlan0/debug with the resulting dmesg output occurring at the same time as the above (for some reason the -n8 argument to dmesg gave no output at all):

[21935.675000] wifi0/wlan0[00:19:7e:41:09:c1]: beacon miss
[21935.675000] wifi0/wlan0[00:19:7e:41:09:c1]: __ieee80211_newstate: RUN -> SCAN
[21935.980000] wifi0/wlan0[00:19:7e:41:09:c1]: stop running
[21935.980000] wifi0/wlan0[00:19:7e:41:09:c1]: __ieee80211_newstate: SCAN -> INIT
[21935.980000] wifi0/wlan0[00:19:7e:41:09:c1]: 00:19:7e:41:09:c1 station with aid 2 leaves (refcnt 6)
[21935.980000] wifi0/wlan0[00:19:7e:41:09:c1]: 00:19:7e:41:09:c1 non-ERP station leaves, count now 0
[21935.980000] wifi0/wlan0[00:19:7e:41:09:c1]: ieee80211_node_leave_11g: disable use of protection
[21935.980000] wifi0/wlan0[00:19:7e:41:09:c1]: ieee80211_node_leave_11g: re-enable use of short preamble
[21936.051000] wifi0/wlan0[00:19:7e:41:09:c1]: start running (state=0)
[21938.316000] wifi0/wlan0[00:19:7e:41:09:c1]: stop running
[21938.316000] wifi0/wlan0[00:19:7e:41:09:c1]: __ieee80211_newstate: INIT -> INIT
[21939.304000] wifi0/wlan0[00:19:7e:41:09:c1]: start running (state=0)
[21939.311000] wifi0/wlan0[00:19:7e:41:09:c1]: __ieee80211_newstate: INIT -> SCAN
[21939.311000] wifi0/wlan0[00:19:7e:41:09:c1]: __ieee80211_newstate: SCAN -> AUTH
[21939.317000] wifi0/wlan0[00:19:7e:41:09:c1]: 00:19:7e:41:09:c1 recv auth frame with algorithm 0 seq 2
[21939.317000] wifi0/wlan0[00:19:7e:41:09:c1]: __ieee80211_newstate: AUTH -> ASSOC
[21939.319000] wifi0/wlan0[00:19:7e:41:09:c1]: 00:19:7e:41:09:c1 assoc success: short preamble, short slot time
[21939.319000] wifi0/wlan0[00:19:7e:41:09:c1]: __ieee80211_newstate: ASSOC -> RUN

It would appear that there is indeed a beacon miss problem, which I reiterate, seems to be pinned on the madwifi driver as this does not occur using ndiswrapper with the corresponding windows driver for this card which can be found on the Lenovo website. Nor does it appear to occur for other wireless devices operating on the same AP.

I hope that offers some clarification for this tenacious intermittent bug. Please let me know if there are any other diagnostics I can do to give more information, as it seems that I frequently encounter situations in which I can reproduce the problem within minutes.

(in reply to: ↑ 11 ) 01/05/08 08:06:20 changed by Petros

Replying to kevmitch@gmail.com:

It would appear that there is indeed a beacon miss problem, which I reiterate, seems to be pinned on the madwifi driver as this does not occur using ndiswrapper with the corresponding windows driver for this card which can be found on the Lenovo website. Nor does it appear to occur for other wireless devices operating on the same AP.

I think it IS a wpa_supplicant bug. I am using ndiswrapper and I am having this problem.

07/30/09 19:36:39 changed by frade@gmx.com

I had this problem like all of you, the network hardware keeps generating an event of beacon miss (in my case its always 11 misses) for every HAL_INT_BMISS and an amount of sucessive beacon misses, it deassociates the station and resets the device. So the solution was to add more time to get beacon misses before trigering the reset. You will have to get the source, edit it, build it and install.

Edit the file if_ath.c and look the for variable intialization "ic->ic_bmiss_guard" and multiply is value by 2 (may be more depending on the number of beacon misses).

In my case it works but i dont consider this a permanent solution. I may be explaining things wrong because its only my conclusions after reading the source code and it may not apply to you if the problem isn't by the missing beacons.