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 .

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:

Page contents degenerate to first person comments in paragraph form from 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.

I stopped getting those "stuck beacon" messages after setting the following commands:

iwpriv ath0 bgscan 0
iwpriv ath0 protmode 0
iwpriv ath0 rssi11a 11
iwpriv ath0 rssi11b 11
iwpriv ath0 rssi11g 11
iwpriv ath0 bintval 500
sysctl -w dev.wifi0.diversity=0
sysctl -w dev.wifi0.txantenna=1
sysctl -w dev.wifi0.rxantenna=1

Changing the channel to 8 increased the speed. I've set mode to auto (iwpriv ath0 mode 0). HostAP is running in "G" mode. Turbo mode is enabled.

None of the above solutions works in my case. The most important fact that hasn't been mentioned here at all: Stuck beacons have hardly any influence on IPv4 traffic, but as far as IPv6 is concerned, they are a terrible nuisance. Each stuck beacon means that all router advertisement (and router solicitation) messages on the interface are blocked either for a very long period of time (usually more than one hour), or permanently. However, no errors are reported by radvd. For the IPv6-only LAN I am running, this is a total disaster. Presumably, tricks with background scans and antennas did not help at all.

I had the same trouble with my D-Link Card (AR5112) and a MSI OEM board. I changed the pci slot and at this time my fcpci card did not work any longer. Now, I exchanged the motherboard against an older, but better one and everything works fine. I think, it is an issue with IRQs, DMA and the really buggy BIOS on the MSI board.

Hey, I've got this problem appearing when I use win xp with wireless card on my VAP. Network has IPv6 enabled. Furthermore- I've got this AP on MSI motherboard! Well... simply turning off IPv6 on win_xp machine doesnt solve 'beacon' problem.

* I have recently emerged from a lengthy fight with this issue myself; I was experiencing the SBP very frequently using an AR2413 in a HostAP setup under Linux 2.6.26 with MadWifi 0.9.4 (Debian Lenny stable, March 2009). It seems that ath5k has yet to support AP (I'll keep my eye on that one) and HostAP obviously won't work with ndiswrapper nicely. I wound up just rolling back to my 2.6.18 kernel with MadWifi 0.9.3, which doesn't seem to have the stuck beacon problem at all.

Solution for Debian Lenny (linux-image-2.6.26-1)

After updating to Debian Lenny with kernel-2.6.26 SBP started to occur with madwifi trunk (r3952). No problems before on Debian Etch using kernel-2.6.18. After switching back to madwifi-0.9.4 SBPs disappeared. The madwifi-0.9.4 branch has been updated for compatibility to kernel 2.6.26:

# svn co
# make

Disable "Enhancements"

As per , I've set that to 0 (was 128) seems to help the problem a bit.

Debian (and probably ubuntu users as well) can place all this in a script called /etc/rc.madwifi - and then reference the script with post-up in /etc/network/interfaces some of the options have been taken from above. FIXME, some of the options below are redundant

For your interfaces file

auto ath0
iface ath0 inet manual
        pre-up /sbin/iwconfig ath0 channel 6
        post-up /etc/rc.madwifi

for /etc/rc.madwifi (don't forget to make it executable)

/sbin/iwpriv ath0 bgscan        0 && \
/sbin/iwpriv ath0 protmode      0 && \
/sbin/iwpriv ath0 rssi11a       11 && \
/sbin/iwpriv ath0 rssi11b       11 && \
/sbin/iwpriv ath0 rssi11g       11 && \
/sbin/iwpriv ath0 bintval       500 && \
/sbin/iwpriv ath0 ff            0 && \
/sbin/iwpriv ath0 burst         0 && \
/sbin/iwpriv ath0 abolt         0 && \
/sbin/sysctl -w dev.wifi0.diversity=0 && \
/sbin/sysctl -w dev.wifi0.txantenna=1 && \
/sbin/sysctl -w dev.wifi0.rxantenna=1

Tested it with an ipw2200, acx, and ralink clients, works fine. Crashes with my sony phone though (don't know what chip it uses) :(.

Detailed explanation of the cause, two possible solutions and some feedback

The following quoted email is currently available at, but I am pasting it in here as well to insure that it does not disappear.

Madwifi 'stuck beacon' problem

    * From: Rainer Weikusat <rweikusat@xxxxxxxxxxx>
    * Date: Sun, 21 Sep 2008 20:23:04 +0200

'Madwifi' is a partially open source driver for various 802.11
chipsets produced by Atheros. There are actually three drivers for
these chips, with Madwifi being the oldest and most
feature-complete. Specifically, it is the only one which supports
using such a card as wireless access point. The hardware itself is
fairly 'simplistic', with most of the AP-functionality provided by the
device driver, periodic transmission of beacon frames being among
this. The way this is (presumably) supposed to work is that the card
provides three different timers, the TBTT-timer (target beacon
transmission time), the DBA-timer (DMA beacon alert) and the
SWBA-timer (software beacon alert). All of these are programmed to
fire once every beacon period, with the DBA-timer starting a little
before the TBTT-timer (2us) and the SWBA-timer a little more (10us).
When the SWBA-timer fires, the card generates an interrupt, upon
reception of which the driver prepares the next beacon frame for
transmission. When the DBA-timer expires, the card (presumably) starts
to DMA the beacon data from RAM to the TX-FIFO of the NIC (I have no
real idea what the TBTT-timer is used for, except that it must be
active). The driver uses a specific hardware transmission queue for
beacons (9 for 'my' card). The beacon send routine contains some logic
to detect if the last beacon was actually sent before queueing the
next one, being comprised of checking that the pending frames count
for the beacon queue is zero and that the 'DMA enable' flag associated
with it is clear. When either of both tests fails, a 'stuck beacon' is
reported and the current beacon period skipped. After eleven 'stuck
beacons' in sequence, a reset of the card is done in order to get
things going again. A well-known issue with these chipsets and the
driver is that the 'stuck beacon' condition will persist indefinitely,
which causes the card to effectively cease to function as an AP (cf [sic]).

Judging from

* Is it possible that this could fix the terrible stuck beacon nightmare?

answer: in our own integration madwifi version we dont have
this stuck beacon nightmare anymore, patches for madwifi are
commited by nbd as far as i know [sic]

the only people (I know of) having access to the source code of the
Atheros hardware abstraction layer believe the issue to be fictious.
One of the Atheros chipsets supported by the driver (AR5416) is
supposed to provide 802.11n support for the 'next generation' hardware
of my employer (which I believe to be fictious :->>). The persistent
'stuck beacon' condition can reliably be triggered by trying to use
the wlan interface of an IPhone with this AR5416-based AP, decreasing
'commercial viability' of this approach somewhat.

It is possible (for the card I have here, the two IPhones used for
testing and a random laptop with an integrated Atheros 802.11 NIC
causing the same issue to occur) to work around the problem by not
using the DBA-timer (which only adds an unspecified delay to the
beacon transmission for a reason I cannot presently imagine), ie not
configuring it during 'beaconinit' (name of the routine programming
the timers) and clearing the AR_Q_MISC_FSP_DBA_GATED flag of the
beacon transmission queue after the the ath_beaconq_config-routine
(if_ath.c) has finished configuring it (after the call to
ath_hal_resettxqueue near its end has returned). This causes beacon
transmissions to start immediatly after the ath_beacon_send routine has
enabled DMA for the beacon queue in response to a SWBA-interrupt. The
modified driver has survived having two IPhones associated with it
(and actually being used) for five to six hours.

NB: This information has been determined by perusing the publically
available 'hardware abstraction code' in the open source ath9k-linux
driver and experiments with the card. The modified driver has had very
little testing and if someone manages to, eg, fry his NIC by trying to
use my suggestion above, 'let his blood be on his own hands'. The
necessary register addresses and constants to do so can be found in
the ath9k source code being part of the 'wireless testing' Linux
kernel tree.

While this may be somewhat difficult to follow, it essentially means one might resolve one's SBP by using the madwifi-hal-testing branch or implementing the suggested work around in the standard madwifi branch. I'll try the former first (since it will be easier) and report my results shortly.

And, as feedback, the "Solution for Debian Lenny (linux-image-2.6.26-1)" suggestion above did not resolve my SBP with Voyage Linux 0.6.1 (based on Debian Lenny) with a Ubiquiti SuperRange?2 (SR2) Wi-Fi card on a RouterBOARD 14, four port miniPCI to PCI card, connected to a RouterBOARD 71, PCI riser card, on a revision 2 RouterBOARD 230 (RB230) embedded system mainboard (full hardware details given in case they end up mattering). And none of the configuration tweaks suggested above helped either. :-(

Comment from tsharples

May 7, 2009

For what it's worth:

In the last 3+ years we've used various versions of madwifi (currently 9.3.3) in dozens of 5.8 Ghz multi-node installations. We've never come across the SB problem until our most recent installation which is running on 900Mhz using Ubiquiti SR9's in what turns out to be a very high-noise environment (indicated noise floor around -75). We were able to eliminate it there, by increasing the beacon interval to 1000 msec from the default of 100 msecs (iwpriv wlan0 bintval 1000). However with the high noise floor, and packet loss approaching 95%, we still don't have an operating system, but that's another story. We will try to address that problem by upgrading to XR9's. Update: Replacing the SR9's with XR9s and horizontal polarity on the antennas took care of the interference problems for the most part. However it was still necessary to set the bintval to 1000 to have a stable system.

End of tsharples comment

Comment from Bruno Condez (11/08/2009):

I always the infamous had StuckBeacon issue with my wireless card Atheros 5001 PCI-E.

Today i tried "madwifi-hal-testing" and i have no StuckBeacons?, but the speed is extremely slow, an average off 15KBps (on local lan via wireless link).

I would be ok with trying the work around posted above by Rainer Weikusat, but unfortunately i didn't understood what the work around is nor what to i need to do.

Can anyone provide a more detailed explanation?


Upgrade Solution

After much frustration, my upgrade to OpenBSD, which has an atheros driver that works RELIABLY in AP mode, resolved this problem. AP mode support for Linux is pathetic. It's 2009! After years of painfully controlled madwifi trouble in this area with every upgrade, I bought a Full MAC prism54 card (the ONLY other Linux option for running an 802.11g AP with better than WEP security!!!), and it has a different problem that randomly knocks the card out of commission!!! And, of course, the prism54 driver is deprecated in favor of the p54 driver which doesn't properly support AP mode because the old 80211 stack for Linux was deprecated in favor of the new UNFINISHED 80211 Linux stack that p54 depends on for that!!! And since madwifi (which is actually a specific conglomeration of HAL and madwifi-NG) is deprecated in favor of ath5k which does not yet support AP mode because of the afore mentioned Linux 80211 stack clusterfu*k, I decided to use OpenBSD which I knew was sane and reliable. I mean, really. What a pile of crap Linux has become in this regard. 2009 and there is NO RELIABLE chipset/driver combo for running an 802.11g AP with WPA (much less WPA2) security! It's pathetic. The corporate vultures and windows "programmers" came in and ruined a perfectly good operating system that I had used since 1992. Sorry for the rant, but OpenBSD is a solution to this BS.