Oct 16 05:52:21 RuckusAP daemon.warn Eved: MLME-REPLAYFAILURE.indication(wlan3 AES-CCM keyid=100 unicast RA:addr=50:a7:33:f7:c9:68 TA:addr=e8:99:c4:aa:0e:2a) (pkt-rsc:10879 k->rsc:10885
Could you please let me know the meaning of the "REPLAYFAILURE" and the condition of generation?
Is the performance degradation due to this messages? What kind of performance issues?
Customer already did several examination such as packet capture on radio etc.
In this first investigation, they found a lot of messages that I asked then simply asking what is the meaning. In order to get a clue, we are analysing the log and some capture data. It looks like an environment dependant issue.
If we would not get a clue or not to isolate a problem, we will submit a support case with our analysis result.
My understanding is this is mainly caused by STA's re-transmission. It is normal to see replay failure in this case. I believe these messages are suppressed to avoid confusion in later releases.
You can ignore this as non-issue.
Yes, you can ignore the following message:
"Aug 22 12:56:41 HSK 1220-042 daemon.warn Eved: MLME-REPLAYFAILURE.indication(wlan15 AES-CCM keyid=68 unicast RA:addr=c4:10:8a:ff:3a:7d TA:addr=c4:10:8a:bf:3b:1d) (pkt-rsc:21846880 k->rsc:21846928 "
This message is caused due to retransmissions and is displayed in case of WPA/WPA2 security being used. It is completely safe to ignore this message.
This is a unicast key scenario, where sender and receiver obviously both possess the same key. Under WPA, the encryption process provides an additional layer of packet-replay protection through use of sequence counter - this is very standard security engineering today, to prevent replay attack. And the replay attack / detection is very simple: keep track of the last known received sequence number, and if ever receiving a packet with a sequence # smaller or same, throw it away.
That is to say, over an WPA network, there are 2 mechanisms for duplicate (or even replay) detection: one provided by 802.11 protocol layer, and another one provided by 802.11i encryption layer.
The reason we have these logs is because of previous Atheros/Qualcomm chip / driver issue that requires a very ugly patch to deal in this area, where the link actually breaks because the received sequence counter is messed up. These logs in that case give us a clue. So to judge whether those logs are bad or not (by the way, it is not labeled an 'error', but 'warning') is whether packets can pass.
Repeat: the replay logs shall be considered harmless, unless there is an actual packet-passing problem.