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 Meraki dashboard at Monitor > Event log) can be an invaluable tool for gaining additional visibility into current activity. The common wireless event log messages listed below, along with their origin and potential causes, can help you better understand your 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 access point (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:

The picture shows association process between STA and AP STA.

 

  • 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 basic service set identifier (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 - The client was disassociated due to inactivity. If a client is not heard from for five minutes, the AP will disassociated the client
  • 802.11 disassociation: Client was deauthenticated - Sending station (STA) is leaving or has left an Independent basic service set (IBSS) or extended service set (ESS). The client indicated to the AP that it's disconnecting from the wireless network. This can occur when a client enters sleep mode and disconnects the Wi-Fi radio to preserve battery life
  • 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. This event can also result from the client being unable to reach the AP due to wireless interference, coverage holes, or any condition that causes a client to stop communicating with an AP
  • 802.11 association rejected for client balancing - A client attempting to join an APt was rejected because the AP was steering the client toward another AP to evenly distribute client load
  • DFS Event Detected - The AP detected a radar signal and took dynamic action to avoid interference with the radar. For more information about Dynamic Frequency Selection (DFS) events, refer to our guide on Dynamic Frequency Selection (DFS)

802.11 Event Log Messages for iOS on MR26.6+ 

iOS devices can send more specific reasons for their disassociation and deauthentication frames. On MR 26.6 and later, APs read these messages and pass them to the dashboard event log. 

Events such as "disassociated because client interface was disabled" and "peer triggered disassociation," as well as other similar events, appear 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) also known as the 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 Wi-Fi Protected Access 2 (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):

The picture shows 802.1x authentication flow between supplicant, authenticator and RADIUS server.

 

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) 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, the APs 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 client misconfiguration or an incompatibility between the client and the AP. When a device roams between APs quickly, the device may not complete association with an AP before moving out of range. This can lower overall success rates without indicating a network issue. For more information about the 802.11 association process, refer to the 802.11 Association process article.

Authentication issues 

Authentication issues are among the most common types of connection failures. If authentication issues appear to be limited to specific clients, verify 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 that automatically attempts to reconnect to an SSID with incorrect saved credentials and fails repeatedly. 

If Authentication appear to be concentrated to a specific AP, the cause may be related to the type of authentication configured. This can indicate a potential issue with the upstream switch port 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, verify that the SSID is configured as expected and that any additional configuration required for 802.1X authentication is complete and correct on the associated server.

Fields Seen in 802.1X failure reason

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

type='802.1X auth fail' num_eap='9' first_time='0.012724844' associated='false' radio='1' vap='7'

Each field in the failure reason is described below:

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

DHCP issues 

Most commonly, DHCP issues are caused by VLAN tagging on the SSID or on an upstream switch port. 

If all clients on a specific SSID are failing DHCP: 

  1. Navigate to Wireless > Configure > Access Control. 

  1. Scroll to the Client Addressing section. 

  1. Verify that client addressing is configured correctly. 

  1. If VLAN tagging is in use, verify that the SSID is using the correct VLAN tagging setup. 

If DHCP issues appear to be concentrated around a specific AP, verify that the upstream switch port settings for that AP allow traffic for all necessary VLANs to pass. 

DNS issues 

DNS issues are typically caused by a misconfiguration on either the client or an upstream switch port. The following are common scenarios: 

  • A client is trying to resolve a local hostname but is using a public DNS server, which results in DNS failures. 

  • A client is trying to resolve a hostname using a local DNS server on another VLAN, but an upstream configuration error is preventing communication between the client and the server. This results in DNS errors for multiple clients on a single AP/SSID. 

Low success rates 

Low success rates can result from several factors. The following are common examples:

  • Client roaming: Environments with frequent client roaming or high-density deployments can experience low success rates due to multiple incomplete connections as clients move through the range of an AP.
  • Incorrect saved credentials: A client that automatically reconnects with incorrect saved credentials and fails repeatedly can lower the overall success rate.

To troubleshoot low success rates:

  1. Use the Connection Steps Graph to identify where in the connection process most failures are occurring.
  2. Check the Health by AP and Health by Client sections to identify if there is a clear source for the failed connections.