RouterDiscussions.com

I believe I solved my problem. I found an error in the DNS settings our DHCP was passing to clients, corrected that.  I also removed the DNS entries from the network section of the AP.  The WAP4410N has been up (at my office) since last Saturday, without any problems. I hope this helps some of the people still having issues, and thanks to everyone in for their help.

Ive seen similar behavior.  I narrowed it down to a laptop with Intel IPW 2200 and Windows XP.  Taking the machine out of the environment seemed to cause the WAP4410N to stay up much longer.  HOWEVER, swapping the WAP4410N with a Netgear WG302 enabled the laptop to happily coexist and the AP has been up for over 3 weeks and counting. So yes, a client may be "causing" the problem, or you could say the WAP4410N has a problem that certain clients expose.

Ive been doing some testing with the WAP4410N.  I took it home and have been using it there.  I have had no problems with it - 4 days now.  This leads me to believe our network could be causing the problem.  Any ideas?  Again our router (D-Link DFL300) handles our DHCP and firewall,  DNS is handled by our server(s) (DNS set up on 2 servers), and everything is attached to a Dell PowerConnect 2748 switch.  We also use Symantec Endpoint Protection.

The best way to get some resolution to this issue is to call the SBSC @ 1-866-606-1866 and open a case with the engineer. This will most likely result in doing some troubleshooting and the case being escalated. You should also point the engineer to the forum thread (this one) and have him/her note in the case everything that has been done. Then the escalation team can contact you and work on it from there. Make sure you have the serial number when you call. Bill

While one way to interpret that log output is a "de-auth" attack, another is hardware/software bug.  The problem with clients losing connectivity to the WAP4410N is widely reported.  I suspect many AP users would take issue with the explanation that they
e simply under attack and theres nothing wrong with the access point.  The only way to really troubleshoot this is to temporarily substitute an AP from another vendor and see if the problem is resolved.  In my environment, the substitution absolutely fixed the problem.  Its unfortunate that Cisco can or (I hope this isn the case) won bother to try and duplicate these problems in their lab environment(s).  If the dialog in this forum is the total of effort Cisco is putting in to resolving this issue, its pretty safe to say it will never be fixed.