Skip to main content
Cisco Meraki Documentation

Common Wireless Event Log Messages and Issues

  1. Last updated
  2. Save as PDF

When monitoring your wireless environment, the event log (in the Dashboard at Monitor > Event log) can be an invaluable tool in gaining additional visibility into current activity. A list of the common wireless event log messages along with their origin and their potential causes can help to bring a better understanding of the wireless environment.

Learn more with these free online training courses on the Meraki Learning Hub:

Sign in with your Cisco SSO or create a free account to start training.

802.11 Event Log Messages

The 802.11 event log messages are from codes specified in the 802.11 wireless standard from the Institute of Electrical and Electronic Engineers (IEEE). 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".

  • 802.11 association - Denotes the joining of a client to an AP on a specified channel with the current received signal strength indication (RSSI).

Example:

May 26 14:45:21 00:18:0a:00:00:01 101 IPAD2 802.11 association channel: 36, rssi: 45

Below is an example of the association process as specified by the 802.11 standard:

2650d396-1f59-4170-b0fa-1e16594f502c

 

  • 802.11 disassociation: previous authentication expired - A client that is attempting to join the service set identifier (SSID) is incorrectly entering the pre-shared key (PSK), or a client left the BSSID without sending a deauthentication frame (could be from a client shutting down or leaving the AP)
  • 802.11 disassociation: client has left AP - A client informed the AP that it should no longer keep the client in its association table. You may see this if the client has potentially gone into a hibernate state, a powered down state, or the client may have chosen to roam to another AP.

Example:

May 26 14:51:35 00:18:0a:00:00:01 101 IPAD2 802.11 disassociation client has left AP
  • 802.11 disassociation: Client association expired - Client was disassociated due to inactivity. If a client is not heard from for 5 minutes, then the client will be disassociated.
  • 802.11 disassociation: Client was deauthenticated - Sending STA is leaving or has left Independent BSS or ESS. Client indicated to the AP that it's disconnecting from the wireless network. Could be from a client going into 'sleep' mode and disconnecting the WiFi radio for battery savings.
  • 802.11 disassociation: unknown reason - A client is no longer communicating with the AP, yet failed to notify the AP that it should be dropped from the association table. Alternately, it can also be a result of the client being unable to reach the AP due to wireless interference, coverage holes, or anything that would suddenly cause a client to stop being heard by an AP.
  • 802.11 association rejected for client balancing - A client that was attempting to join with an access point was rejected, as the access point in question was attempting to steer the client toward another access point in order to evenly distribute the client loads to another nearby access point
  • DFS Event Detected - The access point detected a radar signal and dynamically took action as to not interfere with the radar. To read more about DFS events please refer to our guide on Dynamic Frequency Selection (DFS)

802.11 Event Log Messages for iOS on MR26.6+ 

iOS devices are able to send more specific reasons for their disassociation/deauthentication frames. However, on MR 26.6+, APs are able to read these messages, and they are then passed to the dashboard event log. In previous MR firmware versions, the AP was not interpreting this information.
You will find events such as: "disassociated because client interface was disabled", and "peer triggered disassociation" as well as other similar events in the details section of 802.11 disassociation events in the event log. 

WPA Event Log Messages

  • WPA authentication - Denotes that the client has successfully entered the pre-shared key (PSK) for the associated SSID.

Example:

May 26 14:54:16 00:18:0a:00:00:01 101 IPAD2 WPA authentication

 

  • WPA deauthentication - Signifies that the secure session to the client (known by association ID or AID) has ended to the virtual access point (VAP aka SSID) on the listed radio number.

Example:

May 26 14:51:35 00:18:0a:00:00:01 101 IPAD2 WPA deauthentication vap: 0, radio: 1, aid: 1844047018

802.1X/RADIUS Event Log Messages

  • SSIDs that use WPA2-Enterprise for authenticating splash pages will have related 802.1X and RADIUS messages in the event log
  • You may occasionally see 802.1X re-authentication messages at periodic intervals which is explained here.

 

Example of a successful 802.1X sequence in the event logs (using Meraki-hosted RADIUS):

May 26 15:30:30 00:18:0a:00:00:01 101 IPAD2 802.1X authentication identity: caleb@meraki.com, vap: 0, radio: 1
May 26 15:30:30 00:18:0a:00:00:01 101 IPAD2 802.1X EAP success identity: caleb@meraki.com, vap: 0, radio: 1
May 26 15:30:30 00:18:0a:00:00:01 101 IPAD2 RADIUS response group: , vlan: 0, vap: 0
May 26 15:30:27 00:18:0a:00:00:01 101 IPAD2 802.11 association channel: 36, rssi: 53

 

Example of a failed (due to incorrect password) 802.1X sequence in the event logs (using Meraki-hosted RADIUS):

May 26 15:29:34 00:18:0a:00:00:01 101 IPAD2 802.11 disassociation client has left AP
May 26 15:29:34 00:18:0a:00:00:01 101 IPAD2 802.1X deauthentication identity: caleb@meraki.com, vap: 0, radio: 1
May 26 15:29:34 00:18:0a:00:00:01 101 IPAD2 802.1X EAP failure identity: caleb@meraki.com, vap: 0, radio: 1
May 26 15:29:30 00:18:0a:00:00:01 101 IPAD2 802.1X deauthentication identity: caleb@meraki.com, vap: 0, radio: 1
May 26 15:29:30 00:18:0a:00:00:01 101 IPAD2 802.11 association channel: 36, rssi: 46

 

Below is an example of the 802.1X authentication process as specified by the 802.11 standard (Supplicant = client, Authenticator = AP, AS = RADIUS server):

dadd2898-90d8-451e-9ddf-17fd0a9e87f1

 

Air Marshal Event Log Messages

  • The Air Marshal capabilities of Meraki APs can provide detection and classification of potential attacks in the wireless environment.
  • The frequency of the messages and the associated MAC address(es) can help to diagnose. More information on the Air Marshal product can be found here.
  • Single or multiple device packet flood - Denotes that an AP has detected that single or multiple client(s) have attempted to flood the wireless environment with a type of packet. These message can indicate a malicious attack or temporary, client-based misbehavior. 

Examples:

May 26 16:21:54 00:18:0a:00:00:01 Single device packet flood alarm_id: 3402, radio: 1, reason: left_channel
May 26 16:16:09 00:18:0a:00:00:01 Single device packet flood alarm_id: 1514, radio: 1, reason: timer_expired
May 26 16:16:09 00:18:0a:00:00:01 Single device packet flood alarm_id: 1515, radio: 1, reason: timer_expired
May 26 16:15:13 00:18:0a:00:00:01 Single device packet flood inter_arrival: 10000, device: 84:3A:4B:00:00:01, alarm_id: 1515
May 26 16:13:40 00:18:0a:00:00:01 Single device packet flood inter_arrival: 10000, device: 84:3A:4B:00:00:01, alarm_id: 1514

 

  • Channel scan - When APs are not serving clients, they can scan channels on which they were previously serving clients to identify attacks.

Example:

May 26 13:52:03 00:18:0a:00:00:01 Channel scan channel: 36, clients: 0, active: 0

Common Issues

Association Issues 

Association failures are commonly caused by either a client misconfiguration or an incompatibility between the client and access point. Sometimes when a device roams between APs quickly it will not be able to fully associate to an AP before going out of range, which can contribute to low overall Success Rates without actually indicating an issue in the network. For more information about the 802.11 association process please see our 802.11 Association process article.

Authentication Issues 

Authentication issues are one of the most common types of connection failures. If Authentication issues appear to be limited to specific clients ensure that those clients are connecting to the correct SSID and have the correct user credentials. One of the most common reasons for low success rates in a network is a client with incorrect credentials that is attempting to automatically re-connect to an SSID and failing repeatedly. 

If Authentication issues appear to be located around a certain AP then depending on the type of Authentication configured that could indicate a potential issue with the upstream switchport configuration or a configuration error on an Authentication server, such as a RADIUS server.

If Authentication issues appear to be centered on a specific SSID, ensure that the SSID is configured as expected and that any additional configuration, such as required for 802.1X Authentication, is completed and correct on the associated server.

Fields Seen in 802.1X Failure Reason

An example of 802.1X authentication failure reason on Wireless Health page would look like:

type='802.1X auth fail' num_eap='9' first_time='0.012724844' associated='false' radio='1' vap='7'
  • type='802.1X auth fail': Denotes that client used 802.1X to get authenticated
  • num_eap='9': Denotes that authentication failed at the 9th RADIUS packet exchange between client machine and authentication server
  • first_time='0.012724844': Tells the time it took for MR to get the first EAP packet from client machine. This information could be useful for troubleshooting and understanding latency issues.
  • associated='false': Denotes current state of the client
  • radio='1': Denotes that client is attempting to connect to 5Ghz band (0 = 2.4Ghz and 1 = 5Ghz)
  • vap='7': Denotes that client is attempting to connect to SSID#8 (vap='0' = SSID#1, vap='1' = SSID#2, and so on..)

DHCP Issues 

Most commonly when clients are experiencing DHCP issues the root cause is related to VLAN tagging either on the SSID or on an upstream switchport. If all clients on a certain SSID are failing DHCP then the first thing to check is that client addressing is set correctly on the the SSID. This can be checked by going to Wireless > Configure > Access Control and scrolling to the Client Addressing section of the page. Ensure that the addressing is configured properly and if using VLAN tagging, ensure that the SSID is using the correct VLAN tagging setup.

If DHCP issues appear to be centered around a specific AP ensure that the upstream switchport settings of that AP are configured properly to allow traffic for all the necessary VLANs to pass. 

DNS Issues 

DNS Issues are typically caused by a misconfiguration on either the client or an upstream switchport. For example, if the client is trying to resolve a local hostname but attempting to use a public DNS server we may see DNS failures recorded. Alternatively, if the client is trying to resolve a hostname using a local DNS server located on another VLAN but an upstream configuration error is preventing communication between the client and server we would see DNS errors generated for multiple clients on a single AP/SSID. 

Low Success Rates 

Low Success Rates can be caused by a number of factors. Environments that see lots of client roaming or have a high density deployment can experience unexpectedly low success rates due to multiple incomplete connections as clients quickly roam through the range of a given access point.  Other situations such as having a client with incorrect saved credentials automatically reconnecting and failing repeatedly can quickly contribute to a low overall Success Rate as well. The best way to troubleshoot a low success rate is to use the Connection Steps Graph to quickly identify where in the process the majority of connection failures are occurring, then checking the Health by AP and Health by Client sections to identify if there is an easily identifiable source for the failed connections.