Wireless - Meraki Reason codes

RaphaelL
Kind of a big deal
Kind of a big deal

Wireless - Meraki Reason codes

Hi ,


Does anyone know if Meraki is disclosing it's proprietary reason codes ?

802.11 reason codes are already available through the IEEE ( as mentioned in the documentation below ) 

https://documentation.meraki.com/MR/Monitoring_and_Reporting/Common_Wireless_Event_Log_Messages

 

Here is an example of a reason code from Meraki : 

 

RaphaelL_0-1678806891742.png

 

Also , I think that Meraki is not using the IEEE reason code description/id correctly ... 

 

53 = MESH-MAX-PEERS : The mesh STA has reached the supported maximum number of
peer mesh STAs

49 = REASON_INVALID_PMKID : Invalid pairwise master key identifier (PMKID)

RaphaelL_1-1678806938427.png

 

8: LEAVING_NETWORK_DISASSOC : Disassociated because sending STA is leaving (or has left)
BSS

 

RaphaelL_2-1678806980685.png

 

 

Or Am I misinterpreting the IEEE documents ?       Edit :Yes I was.

 

Thanks , 

 

11 Replies 11
alemabrahao
Kind of a big deal
Kind of a big deal

Meraki is correct, here is this part of the IEEE table:

 

Association status codes

Status code Meaning
0Successful
1Unspecified failure
2Tunneled direct link setup (TDLS) wakeup schedule rejected but alternative schedule provided
3TDLS wakeup schedule rejected
5Security disabled
6Unacceptable lifetime
7Not in same basic service set (BSS)
10Can't support all requested capabilities in capability information field
11Reassociation denied due to inability to confirm that association exists
12Association denied due to reason outside scope of this standard
13Responding station doesn't support specified authentication algorithm
14Received authentication frame with authentication transaction sequence number out of expected sequence
15Authentication rejected because of challenge failure
16Authentication rejected due to timeout waiting for next frame in sequence
17Association denied because AP unable to handle additional associated stations
18Association denied due to requesting station not supporting all data rates in the BSSBasicRateSet parameter, where BSS refers to basic service set
19Association denied due to requesting station not supporting short preamble option
20Association denied due to requesting station not supporting packet binary convolutional code (PBCC) modulation option
21Association denied due to requesting station not supporting channel agility option
22Association request rejected because spectrum management capability required
23Association request rejected because of unacceptable information in the power capability element
24Association request rejected because of unacceptable information in the supported channels element
25Association denied due to requesting station not supporting short slot time option
26Association denied due to requesting station not supporting direct sequence spread spectrum orthogonal frequency division multiplexing (DSSS-OFDM) option
27Association denied because requesting station doesn't support high throughput (HT) features
28Pairwise master key (PMK-R0) Key Holder (R0KH) unreachable
29Association denied because requesting station doesn't support phased coexistence operation (PCO) transition time required by the AP
30Association request rejected temporarily; try again later
31Robust management frame policy violation
32Unspecified. Quality of service (QoS)-related failure
33Association denied because QoS AP has insufficient bandwidth to handle another QoS station
34Association denied due to excessive frame loss rates or poor conditions on current operating channel, or both
35Association (with QoS BSS) denied because the requesting station does not support the QoS facility
37Request declined
38Request not successful as one or more parameters have invalid values
39Traffic stream (TS) not created because request can't be honored; however, suggested traffic specification (TSPEC) provided so that the initiating station may attempt to set another TS with suggested changes to TSPEC
40Invalid information element (doesn't follow 802.11 standard)
41Invalid group cipher
42Invalid pairwise cipher
43Invalid authentication and key management protocol (AKMP)
44Unsupported robust security network element (RSNE) information element version
45Invalid RSNE information element capabilities
46Cipher suite rejected because of security policy
47TS not created; however, hybrid coordinator (HC) may be capable of creating TS, in response to a request, after the time indicated in TS delay element
48Direct link not allowed in the BSS by policy
49Destination station not present within this BSS
50Destination station not a QoS station
51Association denied because ListenInterval too large
52Invalid fast transition (FT) action frame count
53Invalid shared key (pairwise master key identifier or PMKID)
I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
RaphaelL
Kind of a big deal
Kind of a big deal

Source ?

alemabrahao
Kind of a big deal
Kind of a big deal

https://support.google.com/chrome/a/answer/7172038?hl=en#zippy=%2Cassociation-status-codes

 

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
RaphaelL
Kind of a big deal
Kind of a big deal

Edit : The full list of specified 802.11 reason codes can be found in IEEE's documentation in this article (requires account) under "Table 9-49—Reason codes" in section "9.4.1.7 Reason Code field".

 

So I was only focusing on section 9.4.1.7 ( de-auth ) , but my codes are in the section 9.4.1.9 ( auth ).

 

My first question is still valid.

alemabrahao
Kind of a big deal
Kind of a big deal

Ok, but reason code 53 is association, in this case.

 

alemabrahao_0-1678814346778.png

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
RaphaelL
Kind of a big deal
Kind of a big deal

That's what I said.

 

Logs are Auth/Assoc 

So I was only focusing on section 9.4.1.7 ( de-auth ) , but my codes are in the section 9.4.1.9 ( auth ).

rhbirkelund
Kind of a big deal
Kind of a big deal

I can't exactly say what Reason 103 is, but according to StackExchange , it could have something to do with the re-keying process, where the client is sending an M2 with what the AP considers a MIC error. Reducing the EAPoL timeourt might do the trick.

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.
RaphaelL
Kind of a big deal
Kind of a big deal

Makes sense that Meraki would re-use codes from Cisco's WLC. 

 

Those '103' started to appear out of nowhere. 

RaphaelL
Kind of a big deal
Kind of a big deal

I was able to capture it. I'm not an expert on that field at all. But it seems you were right with the M2. I can see a couple a 'retry' then finaly M2,M4 and the client is auth again : 

 

RaphaelL_0-1678892332806.png

Rollbacking to MR28.X fixes the issue. Weird. I will update my ticket

rhbirkelund
Kind of a big deal
Kind of a big deal

But it still doesn't change the fact the there is still no documentation on the Meraki proprietory reason codes, as well as detailed information on what they mean/are caused. 🙂

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.
RaphaelL
Kind of a big deal
Kind of a big deal

Exactly 🙂 That would be so usefull !

Get notified when there are additional replies to this discussion.