WAP4410N wireless traffic locks up even when running latest firmware update

[ForceFlow]

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?

[Tom Watts]

Hi Force Flow, thisis a perpetual problem with the AP throughout it's releases (as you know).

There are a lot of things you can try to fix the problem

• Force the LAN port speed, ensure the router/switch match up
• Use N or G only connection
• Use TKIP security only (if you're using MAC product)
• After firmware upgrade, factory default the unit and manually configure

-Tom
Please mark answered for helpful posts

[ForceFlow]

1) LAN port speed doesn't appear to have any effect

2) Forcing a connection type doesn't seem to have any effect. This is also rather impractical.

3) I don't have that option (though there is a TKIP/AES mixed option). Either way, I'd rather not have to resort to using a weaker encryption method.

4) No effect.

I did manage to find some information about the error message (older versions of firmware didn't even offer that clue).

http://www.dd-wrt.com/wiki/index.php/Advanced_wireless_settings#Beacon_Interval

I ended up increasing the beacon interval from 100ms to 500ms under Wireless > Advanced Settings.

The wifi analyzer app on android seems to keep dropping the SSID when the beacon interval is set that high, so I might have to adjust it to find a good balance.

However, while it was set to 500ms, none of the access points went down for two days.

[edit]: I reduced the beacon interval incrementally down to 300ms. It started locking up at 250ms.

[ForceFlow]

I ended up increasing the beacon rate back up to 350ms, since the access points were still locking up a few times a day.

[bpmadminuser]

What i decided to do with our WAP4410N was try all the K9 firmware releases, and the 2.0.7.8 non k9, to see if the main problem "kernel:  ath_bstuck_tasklet: stuck beacon; resetting" still persisted.

In the end, the ONLY firmware to NOT have this issue was "WAP4410N-fw-2.0.2.1-K9".

So that's what is running right now, and it has been up 48 hours straight. The release notes for the "WAP4410N-fw-2.0.3.3-K9" says it has a fix for a SSID client isolation problem, but so far, the clients cant see each other, in the SSID that has isolation enabled. All the bugs that are listed as fixed in newer firmware aren't relevant to me since, the WAP doesn't even work properly with them installed.

Hope this helps someone else.

[pc-homepage]

Unfortunately even downgrading to 2.0.2.1-K9 did not help with this problem on my Cisco access point. In fact, it was far worse so I updated the firmware again to v2.0.7.4. I've gone through all the settings and see nothing that is amiss but based on one recomendation I saw I increased the beacon interval to 350 but it did not help either. I am open to ides before this device decomes a paperweight.

[pc-homepage]

Sorry, I meant to say that I updated the firmware again to v2.0.7.8.

[RToonders]

I have these config settings and the error packets stopped!

If settings are not mentioned, they are default values

Static IP adres

     x.x.x.x

IPv6

     Disabled

Force LAN Port Speed to 100M

     Enabled

Wireless Network Mode:   

     B/G/N mixed

Wireless Channel

     3 - 2.422 GHz

Wireless Isolation:(between SSID)

     Enabled

Wireless Isolation:(within SSID)

     Enabled

Advanced settings (wireless)

Worldwide Mode (802.11d):

     disabled

Channel Bandwidth:

     40  MHz

Guard Interval:

     short (400ns)

Especially the thick values are importent, hope someone can use this information!

[peter scarola]

Thanks for your hard work and dedication.  I cant wait to get home and try this.  This has been the most frustrating piece of equipment in my whole home network.  Since the latest firmware, mine has been locking up daily.

Thanks again,

Peter

[Andrea Florio]

i didn't see any answer from you, so i guess the work around worked...

i'm using the latest firmware 2.0.7.4 and still the problem persist... i get ping response time up to 3000 ms and i have to reboot the box... frustrating to say the least!

[ForceFlow]

Unfortunately, this was never solved. The workaround helped slightly, but did not come anywhere close to fully resolving the issue.

I finally gave up and ended up returning the WAPs that I could and then ended up going with another vendor--Ubiquiti Unifi-AP-Pro WAPs. I also heard that Meraki WAPs were a viable replacement, but I haven't actually used them myself.

[danniel.butler]

We switched our entire company away from doing business with Cisco because of their lack of support. Still have a few of these floating around with my customers and they are nothing but problematic. We are offering our customers a discounted upgrade to Ubiquity products just to be done with Cisco. We now use Ubiquity products almost exclusively and we haven't had a single issue.