Ticket #848 (new defect)

Opened 2 years ago

Last modified 4 months ago

Beacon misses cause client to reassociate

Reported by: klima@thenet.ch Assigned to:
Priority: major Milestone: version 0.9.4
Component: madwifi: 802.11 stack Version:
Keywords: Cc:
Patch is attached: 1 Pending:

Description

Hi, I've got WRAP boards with Wistron CM9 miniPCI cards. Software - kernel 2.6.15, madwifi svn1705. Link is 3.2km long and signal level is reported to be around -65 dBm. The performance is satisfactory - the link can do 4-5Mb/s symmetrically (when it works). However I can see that client reports lots of beacon misses - today it's 230 within 6 hours. According to the source (net80211/ieee80211_proto.c) the client reassociates everytime it misses beacon. Is this behaviour mandatory? Does it REALLY have to reassociate every time? This behaviour makes the line almost unusable, because the client reassociates every 90 seconds. Or is there any way how to decrease the number of beacon misses?

It doesn't matter if I run encryption or not, it behaves like this everytime. I've tried changing ACK and other timeouts and no success (well, I didn't expect them to help anyway).

Only thing which can possibly be of any help is using ad-hoc mode however I doubt that this mode is stable enough - I got several WRAP reboots when operation in ad-hoc mode (sorry, no debug here). However I NEED encryption and I was unable to set neither WEP or WPA in ad-hoc mode.

Here's output of athstats: 

231 beacon miss interrupts
4322 tx management frames
954 tx failed due to too many retries
520497 long on-chip tx retries
3774 tx frames with no ack marked
92900 tx frames with an alternate rate
151706 rx failed due to bad CRC
8 rx failed due to decryption
26 PHY errors
    23 OFDM restart
    3 CCK restart
740 periodic calibrations
2 rfgain value change
rssi of last ack: 27
rssi of last rcv: 24
1 switched default/rx antenna
Antenna profile:
[1] tx        5 rx      946
[2] tx  1705494 rx  3399101

Attachments

madwifi-sta-discs.patch (3.6 kB) - added by espy@pepper.com on 06/21/07 20:07:06.
Add module paramters for beacon miss threshold and beacon sleep duration.

Change History

09/01/06 00:48:49 changed by espy@pepper.com

Beacon disconnects have been problematic for us ( Pepper ) too. We're currently running MADWiFi 0.9.1 on the Pepper Pad 3 with a bunch of patches.

We're using wpa_supplicant (v0.4.7) which puts the driver into manual roaming mode. When a beacon disconnect is processed in manual roaming mode, the driver is put into SCAN state, which causes a disconnect. We then have to direct wpa_supplicant to re-associate. In auto-roaming mode ( the default mode ), the driver re-associates directly. See ieee80211_beacon_miss() in ieee80211_proto.c.

There are two seemingly redundant sources of calls to ieee80211_beacon_miss(). The first is a software timer in the net80211 layer. Look for code that references vap->iv_swbmiss. The second source is the HAL itself. The ath_pci module configures the beacon miss interrupts based upon values received ( eg. beacon interval, dtim period ) in beacon frames. The code clamps the beacon miss threshold to a value between 1 and 10!!! Way too low in my opinion.

We're running with two patches to the beacon miss code:

1. I removed the code that initializes the software beacon miss timer.

2. I modified the ath_pci module to take two parameters, bmiss_thresh and beacon_sleep. These are used to override the similarly named fields passed to the HAL via the ath_hal_beacontimers() call. We're currently running with the beacon miss threashold set to 150. That seems to make us pretty immune to beacon disconnects, however it's still not perfect.

If there's interest, I can post our patch for (2).

Disabling beacon interrupts altogether isn't a good idea ( we tried it ) since signal quality is calculated from incoming beacons when there's no data traffic. Signal quality drops continually until the point at which no more beacons are being received, at this point it stays at the last/lowest calculated signal quality... ( ie. 4 or 5 ). Our system has a signal quality process that monitors signal strength and will cause a disconnect to happen if the signal quality drops to 0 and stays there for a certain time period. So, it's a catch-22. Disabling beacon miss interrupts gets rid of the disconnects/re-associations, however it prevents the signal strength from ever reaching 0.

One other thought... in conjunction with the bmiss_thresh patch, I may try to modify the beacon_miss() function to cause a reassociation just like when in auto-roaming mode.

09/01/06 15:31:59 changed by klima@thenet.ch

I would be grateful if you post the patch. Thanks in advance.

09/07/06 21:17:14 changed by dsd@gentoo.org

I experienced this problem. madwifi would send a wireless event out-of-the-blue saying that it has been disconnected, for no apparent reason. Using monitor mode on another system revealed that the AP wasn't actually disassociating the system at all.

Turns out that the AP stopped broadcasting beacons for 12 seconds at a time! This is ridiculous and that AP is now binned.

This is not to say that the current driver threshold values are OK, just a heads up to anyone seeing the effects of this, your AP might be broken.

10/18/06 18:28:42 changed by xmxwx@asn.pl

If the Beacon miss problem described here somehow depends on the Beacon Interval, this can be related to ticket #511. See the patches linked there (maybe they will help, maybe not).

01/05/07 21:55:29 changed by dsd@gentoo.org

Even with a good professional grade access point (Proxim AP-700) I am still seeing approximately 5 beacon misses per day. These are all from the hardware interrupt (the software timer does not appear to be running).

At the same time, I am running an ipw3945 in monitor mode directly next to the system with the atheros card (AR5005G). The ipw3945 system sees 9 or 10 beacons per second during the time when madwifi receives the bmiss interrupt.

The patches in #511 don't help a huge amount (beacon interval is 100) but they do improve the situation a little - I have seen it ignore one or two bmiss interrupts due to them occurring soon after the last beacon timer configuration.

I am finding that increasing beacon interval to 20 makes it slightly more reliable. I also tried increasing it to 50 and it *still* generated bmiss interrupts. That means the device went deaf for more than 5 seconds!

01/05/07 21:57:28 changed by anonymous

"I am finding that increasing beacon interval to 20 makes it slightly more reliable."

meant to say:

I am finding that increasing beacon miss threshold to 20 makes it slightly more reliable.

06/21/07 20:07:06 changed by espy@pepper.com

  • attachment madwifi-sta-discs.patch added.

Add module paramters for beacon miss threshold and beacon sleep duration.

06/21/07 20:19:31 changed by espy@pepper.com

The attached patch ( based on r2200 / rel 0.9.3 ) adds module parameters which allow the default beacon miss threshold and beacon sleep duration values to be overridden. For the Pepper Pad 3, we currently use a value of 150 for the beacon miss threshold which may be a bit high, but it made the behavior of the Pad 3 more consistent with the original Pepper Pad with respect to disconnects.

Signed-off-by: Tony Espy <espy@pepper.com>

06/21/07 20:23:40 changed by espy@pepper.com

One other note re: the sta-discs.patch I just attached... We found out shortly after shipping the Pepper Pad 3, that our diversity settings were incorrect, which most likely contributed to the number of beacon misses being seen. That said, I still think the patch is useful in making a client robust in un-friendly Wi-Fi environments.

06/27/07 12:12:31 changed by mrenzmann

  • patch_attached set to 1.
  • milestone set to version 0.9.4.

05/06/08 22:11:45 changed by anonymous

Same problem with svn trunk (changeset 3618). AP is an ALIX board (WRAP successor) running FreeBSD 7.

Only madwifi-clients are affected -- clients using ipw or FreeBSD-ath are working well.

Add/Change #848 (Beacon misses cause client to reassociate)