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
- 1 Post
- 0 Reply Likes
Posted 5 years ago
Primož Marinšek, AlphaDog
- 413 Posts
- 49 Reply Likes
Is the performance degradation due to this messages? What kind of performance issues?
Michael Brado, Official Rep
- 3079 Posts
- 444 Reply Likes
- 14 Posts
- 0 Reply Likes
Beat Regards,
Matsuura
Primož Marinšek, AlphaDog
- 413 Posts
- 49 Reply Likes
You can also do a packet analysis and look for retries and the client and AP behaviour when they happen.
- 14 Posts
- 0 Reply Likes
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, Official Rep
- 3079 Posts
- 444 Reply Likes
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.
- 14 Posts
- 0 Reply Likes
We are trying to got a clue from investigation of RF environment.
Best Regards,
Matsuura
Michael Brado, Official Rep
- 2864 Posts
- 399 Reply Likes
- 21 Posts
- 2 Reply Likes
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.
Related Categories
-
ZoneDirector
- 2639 Conversations
- 777 Followers