I would start with looking at the router logs by using show log.
Like any cisco, if logging is enabled, you should see at least some %DOT11 messages like %DOT11-6-ASSOC, %DOT11-6-DISASSOC...
To enable logging with a 10kB buffer (default is 4096bytes):
router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#logging buffered 10000
If nothing obvious appears from the logs, you could try to activate some debugs on the router:
router#debug dot11 ?
Content-Engine cisco content engine service module
Dot11Radio IEEE 802.11 WLAN
Service-Engine cisco application engine service module
aaa Authentication, Authorization, and Accounting
arp-cache ARP Cache
events IEEE 802.11 events
forwarding 802.11 AP forwarding
mgmt 802.11 Management
network-map Network Map
packets IEEE 802.11 packets
syslog Turn Off Dot11 syslog msgs
virtual-interface 802.11 virtual interface
That should help to troubleshoot the issue.
Be sure also to disable logging console as logging on the serial console generates a cpu interrupt for any character (hence a high cpu usage), and prefer terminal monitor if you're debugging from a vty (telnet/ssh).
A syslog server would be quite useful also. It will store all the logs from the router, and they can then be processed (script of some kind, your eyes...) on the server.
router(config)#logging ?
Hostname or A.B.C.D IP address of the logging host
router(config)#logging <ip of syslog server>
Best Answer
Has anything changed physically in your environment that could be causing radio frequency interference? or have the clients moved further away than normal? I looked up that syslog message and got the following:
Q. What does error message mean: "Packet to client xxxx reached max retries, removing the client"? A. The Packet to client xxxx reached max retries, removing the client error message means that the AP disassociates the client because the client did not respond to max keep-alive messages sent by the AP. This can be an indication of a bad RF. Configure this command on the AP in order to eliminate this issue and to enable the client to not lose the connection:
packet retries 128 drop-packet The increase of packet re-tries to 128 with the drop-packet option is a workaround for the bad RF problem. Refer to Configuring the Maximum Data Retries for more information on this command.
Taken from: http://www.cisco.com/en/US/products/hw/wireless/ps4555/products_qanda_item09186a0080094cdc.shtml