Support Info Massage meaning

[Anonymous]

There are a lot of following messages and degraded the performance of AP.

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[1]:10885

Could you please let me know the meaning of the "REPLAYFAILURE" and the condition of generation?

Thank you.
Matsuura

[Anonymous]

Thank you for your suggestion.
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.

[michael_brado]

Ruckus Development Engineering manager made a comment in ER-1702:

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.

and

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[6]: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.

[Anonymous]

Thank you for your information. They are very helpful to see a supportInfo for us.
We are trying to got a clue from investigation of RF environment.

Best Regards,
Matsuura

[michael_brado]

Yes, that is correct, and you are most welcome.

[Anonymous]

Explanation i received from one of the good support engineer -

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.