nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Support Info Massage meaning

unknown

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

Find more posts tagged with

Accepted answers

All comments

unknown

Kicking in the dark here, but this could be due to this particular station having reporting of events enabled and it most likely didn't send the report to the AP for some reason and the AP is reporting that.

Is the performance degradation due to this messages? What kind of performance issues?

michael_brado

Engineering says the msg is not important, and is removed in current firmware versions.

unknown

Thank you for your answer. We are trying to isolate suspected problem. So we would like to know the meaning of the message in order to relation between the message and the symptom. I see that the msg is not important and no relation with the suspected problem. The symptom we are faced on is client throughput degradation. (less than 300kbps). I know there is a lot of factors so I try to isolate again and submit a support issue later. Thank you for your suggestions.

Beat Regards,

Matsuura

unknown

If you haven't made a validation survey yet I suggest you do that first. Also do a L1 analysis of the site and the areas where the problem is occurring.

You can also do a packet analysis and look for retries and the client and AP behaviour when they happen.

unknown

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.

unknown

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.

unknown

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.

opayaanma

Massage for a business trip to Busan The top massage therapists in all of Busan are constantly on call at this high-end business travel shop. 부산 출장 busan business trip massage massage in Seoul Busan business travel A manager in your 20s will attend to you when they come in 30 minutes.

opayaanma