I maintain multiple buildings, and each building has anywhere between 1 and 4 Cisco/Linksys WAP4410N access points. The problem is that at random intervals, the access points just stop sending and receiving wireless traffic. Every day or two, I have to log into every single access point (either via HTTPS or SSH) and reboot them in order for them to start working again.
In short, here are the config details:
- They are all version 2 hardware (either WAP4410N-A V02 or WAP4410N-E V02).
- They are running IPv4 (IPv6 is disabled) and get static IP addresses via DHCP.
- When there are WAPs with overlapping signals, each WAP is on a different non-overlapping channel (1, 6, or 11).
- Each WAP has two SSIDs (with spaces in their names). One is secured with WPA2. The other is unsecured.
- There are two VLANs on the Ethernet interface. Each of the two SSIDs are assigned to a separate VLAN.
- There is a DHCP server on the network, so the WAPs do not actually assign IP addresses to clients.
- All of the WAPs are running on PoE switches. However, some are gigabit and some are 10/100 switches. Brands vary (Dell and Linksys) and models vary.
Cisco finally recognized this issue as:
CSCtx62203—In certain environments and traffic model, the WAP4410N may lockup after some undetermined time. Workaround: Reboot the device.
As such, the workaround didn’t really offer anything new. Rebooting every WAP ends up being a very time consuming process. It’s awful. And since you have no control over when this issue surfaces and can’t put any safeguards in place, I get calls about it at various points of the day almost every day.
Supposedly the most recent firmware update (2.0.6.1) claimed to fix the issue, but it only seemed to make it worse. So now instead of a WAP locking up every day or two, it locks up anywhere between every 15 minutes to 4 hours when in use.
The firmware was updated and the following issue was fixed in firmware version 2.0.6.1: CSCtx62203—In certain environments and traffic model, the WAP4410N may lockup after some undetermined time. (A protection mechanism was added to guard against sporadic problems with client association that could occur after six to 24 hours.)
As for troubleshooting, there are no error packets. On access points running firmware 2.0.6.1, these messages appear:
Feb 7 13:42:27 Syslogd start up
Feb 7 13:51:59 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 7 13:52:01 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 7 13:52:05 syslog: Found beacon stuck, down and up the VAP interface.
Feb 7 14:47:01 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 7 14:47:02 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 7 14:47:05 syslog: Found beacon stuck, down and up the VAP interface.
Feb 7 15:22:53 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 7 15:22:56 syslog: Found beacon stuck, down and up the VAP interface.
Feb 7 16:15:19 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 7 16:15:33 syslog: Found beacon stuck, down and up the VAP interface.
Feb 7 12:27:25 Syslogd start up
Feb 7 14:06:18 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 7 14:06:23 syslog: Found beacon stuck, down and up the VAP interface.
Feb 7 14:44:28 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 7 14:44:31 syslog: Found beacon stuck, down and up the VAP interface.
Feb 7 15:09:18 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 7 15:09:24 syslog: Found beacon stuck, down and up the VAP interface.
Feb 7 15:42:23 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 7 15:42:25 syslog: Found beacon stuck, down and up the VAP interface.
Feb 7 16:52:18 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 7 16:52:24 syslog: Found beacon stuck, down and up the VAP interface.
Feb 7 16:53:05 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 7 17:20:05 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 7 17:20:08 syslog: Found beacon stuck, down and up the VAP interface.
Feb 7 17:23:34 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 7 17:23:39 syslog: Found beacon stuck, down and up the VAP interface.
Feb 7 21:21:28 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 7 21:21:30 syslog: Found beacon stuck, down and up the VAP interface.
Feb 8 09:55:23 kernel: ath_bstuck_tasklet: stuck beacon; resetting (bmiss count 36)
Feb 8 09:55:29 syslog: Found beacon stuck, down and up the VAP interface.
These log messages appear on both WAP4410N-A V02 and WAP4410N-E V02 devices.
I noticed that when the “beacon stuck” message appears, wireless traffic locked up 10-15 minutes prior to the message’s appearance in the log, and the SSID drops for 4-6 minutes after the message appears.
Is there anything that can be done to address the issue?
