03-14-2023 08:18 AM
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 ,
03-14-2023 09:18 AM
Meraki is correct, here is this part of the IEEE table:
| 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) |
03-14-2023 09:47 AM
Source ?
03-14-2023 10:06 AM
https://support.google.com/chrome/a/answer/7172038?hl=en#zippy=%2Cassociation-status-codes
03-14-2023 09:54 AM
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.
03-14-2023 10:19 AM
Ok, but reason code 53 is association, in this case.
03-14-2023 10:27 AM
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 ).
03-14-2023 10:38 AM
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.
03-14-2023 10:51 AM
Makes sense that Meraki would re-use codes from Cisco's WLC.
Those '103' started to appear out of nowhere.
03-15-2023 07:59 AM
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
03-15-2023 08:39 AM
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. 🙂
03-15-2023 08:40 AM
Exactly 🙂 That would be so usefull !
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide