DOT11-4-TKIP_REPLAY

[Dieselboy]

On one of my lightweight AP's I'm seeing the below logs. the client "5cf9...." is one of our Macs. I cannot see the other client associated at the moment.

Since the bottom client is legitimate. Am I right in thinking that these log messages could be due to interference, that is the wifi from the client bouncing off something nearby, like a metal wall and therefore arriving at the AP twice? Cisco documentation says "almost certainly an attack" however I can SSH to the 5cf9 device and log in. It is one of ours

Code Select Expand


*Feb 29 07:46:32.153: %DOT11-4-TKIP_REPLAY: Client 64bc.0c80.9a72 had 1 TKIP TSC replays
*Feb 29 07:53:35.819: %DOT11-4-TKIP_REPLAY: Client 64bc.0c80.9a72 had 1 TKIP TSC replays
*Feb 29 07:54:41.078: %DOT11-4-TKIP_REPLAY: Client 64bc.0c80.9a72 had 2 TKIP TSC replays
*Feb 29 07:55:31.278: %DOT11-4-TKIP_REPLAY: Client 64bc.0c80.9a72 had 1 TKIP TSC replays
*Feb 29 07:56:36.537: %DOT11-4-TKIP_REPLAY: Client 64bc.0c80.9a72 had 2 TKIP TSC replays
*Feb 29 07:57:42.809: %DOT11-4-TKIP_REPLAY: Client 64bc.0c80.9a72 had 1 TKIP TSC replays
*Feb 29 08:00:46.602: %DOT11-4-CCMP_REPLAY: Client 5cf9.3889.c77c had 1 AES-CCMP TSC replays


[wintermute000]

Doesn't sound promising... http://www.cisco.com/c/en/us/td/docs/wireless/access_point/12-4_10b_JA/configuration/guide/scg12410b/scg12410b-appC-errormsg.html

[Dieselboy]

Yes I found that earlier: not much information:

Error Message    DOT11-4-TKIP_REPLAY: "TKIP TSC replay was detected on a packet (TSC
0x%ssx received from %e)."
Explanation    TKIP TSC replay was detected on a frame. A replay of the TKIP TSC in a received packet almost indicates an active attack.

Recommended Action    None.

Since it's probably not an attack, I was wondering if interference would be the cause instead.

[Otanx]

No help here, but I have to chuckle at the "indicates an active attack" and "Recommended Action None". Someone is hacking you, you shouldn't do anything.

-Otanx

[SimonV]

Is it always the same MAC, or OUI/manufacturer? Could be faulty drivers. I spent days troubleshooting our controller shutting down SSIDs temporarily due to TKIP countermeasures. Turned out to be the Intel Centrino 6200 drivers sending malformed packets. Driver update on a couple hundred PCs  fixed it.

[Dieselboy]

Interesting, it's not the same mac all of the time. There have been wifi issues on this AP and the log message which stood out to me last week is no longer present. I've not had any wifi complaints this week though but that doesn't mean there aren't any issues.

Last weeks log message was: %DOT11-4-FLUSH_DEAUTH: Consecutive tx fail 500+: deauth 00c2.c617.f04d

TAC stated this log is due to a faulty wifi client hogging the airtime. We have suspected faulty wifi devices before.

I can look into network drivers when I'm over there, but most of the machines are Apple Mac, so I dont really know how those drivers are managed if at all.