Been running Voyage (yes v. old ver.!) on this core node (hosted on reliable old PIII pc!) on top of tower block for several years with essentially no issues until yesterday when we suffered an attack of the infamous "stuck beacon" issue (<a href="http://madwifi-project.org/wiki/StuckBeacon">http://madwifi-project.org/wiki/StuckBeacon</a>) causing outages during ~11am - 15.30 see Cacti screencap below:<br>

<br><img title="outage06.07.11.png" alt="outage06.07.11.png" src="cid:ii_13100aa18524206c"><br><br>Sysinfo:<br><br>2.6.15-486-voyage #1 PREEMPT Mon Mar 27 07:45:05 GMT 2006 i686<br><br>using: madwifi-ng-modules-2.6.15-486-voyage<br>

<br>Wifi card (there are three others also but different to this one and unaffected by this issue):<br><br>0000:04:08.0 0200: 168c:001b (rev 01)<br>        Subsystem: 168c:2063<br>        Flags: bus master, medium devsel, latency 168, IRQ 21<br>

        Memory at 40000000 (32-bit, non-prefetchable) [size=64K]<br>        Capabilities: [44] Power Management version 2<br><br>PCI-ID = 168c 2063  EnGenius EMP-8602 (400mw) or Compex WLM54AG<br><br><i>Above lspci info seems to conflict with comment posted (by previous sysadmin no longer around) about card type used but no previous issues have occurred similar to this...</i><br>

<br>iwconfig ath0:<br><br># NB Senao NMP-8602-PLUS card has antennae reversed, note antdiv diffs<br>auto ath0<br>iface ath0 inet static<br>        address ***.***.***.***  ## hidden for this post<br>        netmask 255.255.255.252<br>

        wireless_channel 165<br>        wireless_essid *******  ## hidden for this post<br>        pre-up wlanconfig ath0 create wlandev wifi0 wlanmode ap && \<br>                sysctl -w dev.wifi0.diversity=0 && \<br>

                sysctl -w dev.wifi0.txantenna=2 && \<br>                sysctl -w dev.wifi0.rxantenna=2 <br>        up athctrl -i wifi0 -d 2190 && \<br>        tc qdisc add dev ath0 root handle 1: prio && \<br>

        tc qdisc add dev ath0 parent 1:1 handle 10: sfq && \<br>        tc qdisc add dev ath0 parent 1:2 handle 20: sfq && \<br>        tc qdisc add dev ath0 parent 1:3 handle 30: sfq<br>        post-down wlanconfig ath0 destroy<br>

<br><br>At first we thought the issue was related to a bout of wet weather, but investigation on the antenna didn't indicate this and logs showed stuck beacon error. <br><br>Reading up on this it appears there isn't a known cause, but this snippet from an Italian post (translated) suggests it is caused by interference from other devices:<br>

<br><a href="http://lublog.tuttoeniente.net/archives/151/fonera-4-eliminare-wifi0-stuck-beacon-resetting-bmiss-count-4">http://lublog.tuttoeniente.net/archives/151/fonera-4-eliminare-wifi0-stuck-beacon-resetting-bmiss-count-4</a><br>

---------------------<br><div style="margin-left: 40px;">Fonera # 4: Delete "wifi0: stuck beacon; resetting (bmiss count 4)"<br><br>You, too, you came, like me, the infamous "wifi0: stuck beacon; resetting (bmiss count 4)" endlessly repeated in the output of dmesg ? The solution is there, but not entirely painless.<br>

<br>The problem is due to a bug in the chipset drivers for Atheros wireless interface of the Fonera, which manifests itself in particular in the presence of other wireless devices, such as access points or other audio video transmitters. For the record, I have both of these devices, then the infamous error has always accompanied me, and even the classic solution to set the network on channel 11 has solved the problem. This bug has been fixed in newer versions of madwifi, but there is only one Fonera in the old version.<br>

<br><snip>...</snip><br><br></div>(with a solution posted here relevant to Fonera)<br>-----------------------<br><br>All is back to normal today (despite more wet weather) so I'm wondering what triggered this. Interestingly the lift engineer/s were present during this episode and am beginning to suspect it is something related to them being in the area. Wireless devices? A/V transmitting kit? Even presence of iPhone is suggested in the Madwifi article above!!<br>

<br>What is the state of play with this? Anyone have similar experiences like this?<br><br>I know upgrade is the usual reply and solution, but having read the Madwifi page, in this case I am not sure, and don't want to try anything that could break this otherwise rock solid box resulting in site visit!<br>

<br>Sorry for rather large post, but I am fascinated to find out the cause of this - and any solution!<br><br>Thanks in advance,<br><br>A<br><br>--<br><a href="http://www.bristolwireless.net/">http://www.bristolwireless.net/</a>  | 0117 325 0067 |  <a href="mailto:sip%3Ainfo@bristolwireless.net">sip:info@bristolwireless.net</a><br>

Bristol Wireless<br>Windmill Hill City Farm<br>Philip Street<br>Bedminster<br>Bristol BS3 4EA<br>