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 .

Changes between Version 32 and Version 33 of StuckBeacon

Author:
fleshenough@gmail.com (IP: 0.0.0.0)
Timestamp:
04/13/09 09:07:55 (11 years ago)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • StuckBeacon

    v32 v33  
    139139 
    140140Tested it with an ipw2200, acx, and ralink clients, works fine. Crashes with my sony phone though (don't know what chip it uses) :(. 
     141 
     142== Detailed explanation of the cause, two possible solutions and some feedback == 
     143 
     144The following quoted email is currently available at http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.system/2008-09/msg00120.html, but I am pasting it in here as well to insure that it does not disappear. 
     145 
     146{{{ 
     147Madwifi 'stuck beacon' problem 
     148 
     149    * From: Rainer Weikusat <rweikusat@xxxxxxxxxxx> 
     150    * Date: Sun, 21 Sep 2008 20:23:04 +0200 
     151 
     152'Madwifi' is a partially open source driver for various 802.11 
     153chipsets produced by Atheros. There are actually three drivers for 
     154these chips, with Madwifi being the oldest and most 
     155feature-complete. Specifically, it is the only one which supports 
     156using such a card as wireless access point. The hardware itself is 
     157fairly 'simplistic', with most of the AP-functionality provided by the 
     158device driver, periodic transmission of beacon frames being among 
     159this. The way this is (presumably) supposed to work is that the card 
     160provides three different timers, the TBTT-timer (target beacon 
     161transmission time), the DBA-timer (DMA beacon alert) and the 
     162SWBA-timer (software beacon alert). All of these are programmed to 
     163fire once every beacon period, with the DBA-timer starting a little 
     164before the TBTT-timer (2us) and the SWBA-timer a little more (10us). 
     165When the SWBA-timer fires, the card generates an interrupt, upon 
     166reception of which the driver prepares the next beacon frame for 
     167transmission. When the DBA-timer expires, the card (presumably) starts 
     168to DMA the beacon data from RAM to the TX-FIFO of the NIC (I have no 
     169real idea what the TBTT-timer is used for, except that it must be 
     170active). The driver uses a specific hardware transmission queue for 
     171beacons (9 for 'my' card). The beacon send routine contains some logic 
     172to detect if the last beacon was actually sent before queueing the 
     173next one, being comprised of checking that the pending frames count 
     174for the beacon queue is zero and that the 'DMA enable' flag associated 
     175with it is clear. When either of both tests fails, a 'stuck beacon' is 
     176reported and the current beacon period skipped. After eleven 'stuck 
     177beacons' in sequence, a reset of the card is done in order to get 
     178things going again. A well-known issue with these chipsets and the 
     179driver is that the 'stuck beacon' condition will persist indefinitely, 
     180which causes the card to effectively cease to function as an AP (cf 
     181http://madwifi-project.org/wiki/StuckBeacon [sic]). 
     182 
     183Judging from 
     184 
     185* Is it possible that this could fix the terrible stuck beacon nightmare? 
     186 
     187answer: in our own integration madwifi version we dont have 
     188this stuck beacon nightmare anymore, patches for madwifi are 
     189commited by nbd as far as i know 
     190 
     191http://madwifi-project.org/wiki/news/20080829/new-hal-release-for-atheros-hardware [sic] 
     192 
     193the only people (I know of) having access to the source code of the 
     194Atheros hardware abstraction layer believe the issue to be fictious. 
     195One of the Atheros chipsets supported by the driver (AR5416) is 
     196supposed to provide 802.11n support for the 'next generation' hardware 
     197of my employer (which I believe to be fictious :->>). The persistent 
     198'stuck beacon' condition can reliably be triggered by trying to use 
     199the wlan interface of an IPhone with this AR5416-based AP, decreasing 
     200'commercial viability' of this approach somewhat. 
     201 
     202It is possible (for the card I have here, the two IPhones used for 
     203testing and a random laptop with an integrated Atheros 802.11 NIC 
     204causing the same issue to occur) to work around the problem by not 
     205using the DBA-timer (which only adds an unspecified delay to the 
     206beacon transmission for a reason I cannot presently imagine), ie not 
     207configuring it during 'beaconinit' (name of the routine programming 
     208the timers) and clearing the AR_Q_MISC_FSP_DBA_GATED flag of the 
     209beacon transmission queue after the the ath_beaconq_config-routine 
     210(if_ath.c) has finished configuring it (after the call to 
     211ath_hal_resettxqueue near its end has returned). This causes beacon 
     212transmissions to start immediatly after the ath_beacon_send routine has 
     213enabled DMA for the beacon queue in response to a SWBA-interrupt. The 
     214modified driver has survived having two IPhones associated with it 
     215(and actually being used) for five to six hours. 
     216 
     217NB: This information has been determined by perusing the publically 
     218available 'hardware abstraction code' in the open source ath9k-linux 
     219driver and experiments with the card. The modified driver has had very 
     220little testing and if someone manages to, eg, fry his NIC by trying to 
     221use my suggestion above, 'let his blood be on his own hands'. The 
     222necessary register addresses and constants to do so can be found in 
     223the ath9k source code being part of the 'wireless testing' Linux 
     224kernel tree. 
     225}}} 
     226 
     227While 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. 
     228 
     229And, 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 SuperRange2 (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. :-(