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 .
Version 16 (modified by mentor, 12 years ago)

The Infamous Stuck Beacon Problem

This page, more than most, is a work-in-progress. If you have any detailed experience with the Stuck Beacon, please suffix it here.

The Stuck Beacon Problem (SBP) is an intermittent but severe problem for some users. It has been around for a while, but has yet to be resolved. Please help collect and report data on this bug by suffixing your experience to this page. Since no one yet knows the basis for the problem, the measures to report here will be refined over time. Please read on for more hints.

Per Sam Leffler: "stuck beacon" means the TX DMA of the beacon frame failed to complete in a full beacon interval. Diagnosing such a problem requires understanding why DMA failed to complete. This usually involves checking the DMA descriptor for clues and/or looking at other HW-related state. If you have a "memory smash" then you will see it in the descriptor contents--but I doubt it. In my experience this problem is usually caused by feeding bogus data to the DMA engine that causes it to lock-up but the problem in general is very complicated...

To enable debug messages to help sort out the stuck beacon problem:

athdebug +beacon +beacon_proc +fatal

80211debug +assoc +elemid

The SBP is strictly an issue on APs, stations don't have the Problem. The SBP is generally associated with a reduction in performance. Data transfer rates drop. Data may stop moving all together. You may get a 'Stuck Beacon' message.

Anecdotal evidence suggests that the SBP occurs to varying degrees, and only the most severe are reported as 'Stuck Beacon'. Some SBPs yield an simple error, but panics have been reported.

One of the measures that can indicate the problem is an acceleration in the card's hardware interrupt rate. To watch the accumulation of interrupts on wifi0, key in the following line from a console. Substitute your interface name for wifi0: in the 'old' code, typically that is ath0, and in the 'NG' code, the name of the base device, typically wifi0. If the accumulation rate accelerates significantly, you may be heading towards a stuck beacon. NB: the count shown below will increase, and that is normal. Accelerated rates are the issue.

watch -n 1 'cat /proc/interrupts | grep wifi0'

Stuck Beacons can often be the result of a incorrect installation or misconfiguration. It's been reported that changing settings stopped the stuck beacon (which settings you ask: the reporter said "I don't remember which setting stopped that").

Another reporter using a D-link DWL-AG650 PCI card with drivers from CVS on 12/28/2005 encountered the SBP mostly when doing things that are network-intensive- RDesktop and VNC especially seem to trigger the problem. Watching a video recorded with MythTV induced the SBC and the video became choppy, though CPU idle was still over 90%. Downing the interface and rmmod ath_pci, sometimes helps, but not always, ie: got the SBP, downed the interface, removed the driver, re-inserted it, brought the interface back up, and that worked for another two hours. But after that, the SBP persisted through several down-remove-modprobe-up cycles.

It appears that stuck beacon can be caused by wireless cards that have some sort of power saving feature, namely Intel Centrino (2200BG) and equivalent cards. To fix this, turn the card out of power saving mode in the control panel, this may or may not fix the problem, but appeared to work for me. Uptime is around 10+ days with latest MadWiFi drivers. More information specific to Intel Centrino laptops can be found here:

Here is a little perl script giving you the differences. Usage: store the code in a file, e.g. "". Call it with "perl wifi0" and watch the number of interrupts every second. Replace "wifi0" with your interface. On my idle system a value between 10 and 50 seems to be normal.

# (setq perl-args (list "wifi0"))
# show information about the number of interrupts
($if) = @ARGV;
$if = "wifi0" unless $if;
print "Interface is $if\n";
$| = 1; # flush stdout;
while (true){
  open (IRQ,"/proc/interrupts");
  while($ifline = <IRQ>){
    if($ifline =~ /.*: *([0-9]+).*$if/){
      $count = $1;
  $diff = $count - $oldCount;
  print "\r $diff    ";
  $oldCount = $count;
  sleep 1;

I managed to cause a SBP by changing channel while interface was up. To fix it, change channel on start-up before interface is up and it appears to be fine.


After suffering repeat kernel panics on my SMC WPCIT-G, I have done the following:

1) reduced the beacon interval time: iwpriv ath0 bintval 500

2) locked to 802.11g: iwpriv ath0 mode 3

3) manually set channel: iwconfig ath0 channel 9

4) disabled turbo mode: iwpriv ath0 turbo 0

I now have no more kernel panics, but network throughput is poor. SBPs still occur, but very infrequently (sometimes none in a day, other times every few minutes - log reveals none in last five days). Certain wireless cards now have difficulty maintaining a connection (especially Intel Centrino-based devices). Clients with identical SMC cards have no problem and network uptime is over 30days. Thus, not an ideal solution, but a working system in the interim.

Turning off background scanning with an 'iwpriv ath0 bgscan' removed all stuck beacon messages from my server. My configuration is set-up with only one VAP in master mode running hostapd on a gentoo amd64 box. I was getting about 200 stuck beacon messages per minute before turning off background scanning while idle. I have not had a chance to test under load yet.