Wireless client disconnecting

Question

Hi All,
We have a WLAN setup with 1 AP 1230 assigned as a WDS, and the 16 APs configured as Infrastructure AP. Off late, I am experiencing a problem where all my clients are getting disconnected frequently. I have checked the logs and the logs indicate the follwoing:
%DOT11-4-TKIP_MIC_FAILURE: TKIP Michael MIC failure was detected on a packet (TSC=0x19B42) received from 0013.ced4.bd48.
Oct 24 12:45:42 172.20.166.22 5673: Oct 24 07:15:42.428: %DOT11-3-TKIP_MIC_FAILURE_REPEATED: Two TKIP Michael MIC failures were detected within 48 seconds on Dot11Radio0 interface. The interface will be put on MIC failure hold state for next 60 seconds.
Oct 24 12:45:42 172.20.166.22 5674: Oct 24 07:15:42.429: %DOT11-4-TKIP_MIC_FAILURE: TKIP Michael MIC failure was detected on a packet (TSC=0x19B43) received from 0013.ced4.bd48.
Oct 24 12:45:42 172.20.166.22 5675: Oct 24 07:15:42.430: %DOT11-4-TKIP_MIC_FAILURE: TKIP Michael MIC failure was detected on a packet (TSC=0x19B44) received from 0013.ced4.bd48.
Oct 24 12:45:42 172.20.166.22 5676: Oct 24 07:15:42.430: Too many MIC failures.
I need a solution to overcome this problems. Please let me know if you need any further information, to help me provide a solution.
regds,
Mahesh

Answer 1

Good afternoon Mahesh...
Similar to a CRC, TKIP uses Message Integrity Check(MIC) to ensure protection of the payload and headers. Presently the Michael algorithm is used to accomplish this function. Essentially these messages are early warning signs of RF interference, hardware failure and or an active attack.
The initial error message of TKIP_MIC_FAILURE is rather harmless, as there is no effect to surrounding clients. It simply states that the AP has received a packet which failed its integrity check. MIC replaced WEP's CRC-32 checksum for improved security. You will NOT see this issue in LEAP as it does not utilize MIC.
TKIP_MIC_FAILURE_REPEATED, however is another story. If you see this log entry on an access point, you will want to respond quickly. This is stating that a workstation has sent X number of MIC failures in a certain number of seconds. As stated by the 802.11i standard, the access point goes into a blackout period. ( Cisco's default is 60 second blackout period), what this does is disassociates all wireless clients associated with the access point and puts the radio in a type of hold where it does not allow any associations until the blackout is lifted.
The offending client and those associated with the access point do not receive any sort of error. All the user will notice, is that their laptop's wireless has been disconnected. If the user's laptop is able to access another AP it will attempt to connect to it, if behaving and configure correctly. What we have seen in at our facility is the offending client will continue to cause TKIP errors and bring down the AP it just connected to.
Is there a Band-Aid to this problem?
Interface dot11radio x
countermeasure tkip hold-time 0
This is NOT a solution, its simply a fix to keep your APs from going into blackout. Again I would only use this if you had a larger volume of laptops with malfunctioning nics than your local techsupport could handle.
There are two typical causes for these errors, hardware problems and RF issues. RF changes even at 5ft, if you are able to go to multiple areas of your facility (saying you have a large facility) and take still shoot out errors, you likly have a hardware issue. Replace the card and your good to go.
While upgrading to the latest IOS is always the best messure even when not facing problems you will likly not see a decrease/increase.
hope this helps.... Simply put , research if its a single laptop... If it is, attempt to replace the nic.. We had one laptop which even after reloading the IOS, swapping the cards, etc it kept commiting the units. We kept the harddrive and sent the laptop off and was RMA'd. New laptop came in, put the old hdd back in, no problems.
We have not noticed a link between driver version nor firmware...