- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 :
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 ofpeer mesh STAs
49 = REASON_INVALID_PMKID : Invalid pairwise master key identifier (PMKID)
8: LEAVING_NETWORK_DISASSOC : Disassociated because sending STA is leaving (or has left)BSS
Or Am I misinterpreting the IEEE documents ? Edit :Yes I was.
Thanks ,
- Labels:
-
Other
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Meraki is correct, here is this part of the IEEE table:
Association status codes
0 | Successful |
1 | Unspecified failure |
2 | Tunneled direct link setup (TDLS) wakeup schedule rejected but alternative schedule provided |
3 | TDLS wakeup schedule rejected |
5 | Security disabled |
6 | Unacceptable lifetime |
7 | Not in same basic service set (BSS) |
10 | Can't support all requested capabilities in capability information field |
11 | Reassociation denied due to inability to confirm that association exists |
12 | Association denied due to reason outside scope of this standard |
13 | Responding station doesn't support specified authentication algorithm |
14 | Received authentication frame with authentication transaction sequence number out of expected sequence |
15 | Authentication rejected because of challenge failure |
16 | Authentication rejected due to timeout waiting for next frame in sequence |
17 | Association denied because AP unable to handle additional associated stations |
18 | Association denied due to requesting station not supporting all data rates in the BSSBasicRateSet parameter, where BSS refers to basic service set |
19 | Association denied due to requesting station not supporting short preamble option |
20 | Association denied due to requesting station not supporting packet binary convolutional code (PBCC) modulation option |
21 | Association denied due to requesting station not supporting channel agility option |
22 | Association request rejected because spectrum management capability required |
23 | Association request rejected because of unacceptable information in the power capability element |
24 | Association request rejected because of unacceptable information in the supported channels element |
25 | Association denied due to requesting station not supporting short slot time option |
26 | Association denied due to requesting station not supporting direct sequence spread spectrum orthogonal frequency division multiplexing (DSSS-OFDM) option |
27 | Association denied because requesting station doesn't support high throughput (HT) features |
28 | Pairwise master key (PMK-R0) Key Holder (R0KH) unreachable |
29 | Association denied because requesting station doesn't support phased coexistence operation (PCO) transition time required by the AP |
30 | Association request rejected temporarily; try again later |
31 | Robust management frame policy violation |
32 | Unspecified. Quality of service (QoS)-related failure |
33 | Association denied because QoS AP has insufficient bandwidth to handle another QoS station |
34 | Association denied due to excessive frame loss rates or poor conditions on current operating channel, or both |
35 | Association (with QoS BSS) denied because the requesting station does not support the QoS facility |
37 | Request declined |
38 | Request not successful as one or more parameters have invalid values |
39 | Traffic 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 |
40 | Invalid information element (doesn't follow 802.11 standard) |
41 | Invalid group cipher |
42 | Invalid pairwise cipher |
43 | Invalid authentication and key management protocol (AKMP) |
44 | Unsupported robust security network element (RSNE) information element version |
45 | Invalid RSNE information element capabilities |
46 | Cipher suite rejected because of security policy |
47 | TS 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 |
48 | Direct link not allowed in the BSS by policy |
49 | Destination station not present within this BSS |
50 | Destination station not a QoS station |
51 | Association denied because ListenInterval too large |
52 | Invalid fast transition (FT) action frame count |
53 | Invalid shared key (pairwise master key identifier or PMKID) |
Please, if this post was useful, leave your kudos and mark it as solved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Source ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
https://support.google.com/chrome/a/answer/7172038?hl=en#zippy=%2Cassociation-status-codes
Please, if this post was useful, leave your kudos and mark it as solved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, but reason code 53 is association, in this case.
Please, if this post was useful, leave your kudos and mark it as solved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Makes sense that Meraki would re-use codes from Cisco's WLC.
Those '103' started to appear out of nowhere.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 :
Rollbacking to MR28.X fixes the issue. Weird. I will update my ticket
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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. 🙂
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Exactly 🙂 That would be so usefull !
