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 11 (modified by phycho <>, 14 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 intermittant 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 meaures to report here will be refined over time. Please read on for more hints.

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 AP's, 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 SBP's 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 folowing 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 mis-installation or mis-configuration. 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 equiv 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 stuckbeacon by changing channel while interface was up, to fix this change channel on startup before interface is up and it appears to be fine.

screenshot below