Cisco CleanAir will report the  following traps on CUWN WLCs: - AP APNAME06[1] (50:1c:bf:b4:d8:00) Device ID: 0x20f9, Type: WiFi Invalid Channel[31], Severity: 0, Channels: 149, Cluster ID: 0e:58:c0:79:38:7d, Previous Cluster ID: 0e:58:c0:79:38:7d, Event: Set - AP APNAME17[0] (34:db:fd:d4:62:60) Device ID: 0xd979, Type: WiFi Invalid Channel[31], Severity: 0, Channels: 11, Cluster ID: 0e:58:c0:7b:e0:1a, Previous Cluster ID: 0e:58:c0:7b:e0:1a, Event: Set - AP APNAME806[1] (50:1c:bf:b4:d8:00) Device ID: 0x20f2, Type: WiFi Inverted[30], Severity: 2, Channels: 149, Cluster ID: 0e:58:c0:7b:c9:8c, Previous Cluster ID: 0e:58:c0:7b:c9:8c, Event: Clear These are more likely RF interferer devices that could easily be sending RF inverted signals or signals on invalid 802.11 channels (somewhere in the 2.4GHz and 5GHz bands), and hence reported as such (CleanAir was not able to confirm what specific type of device that was, but was able to notice some inverted signals or signals on those invalid channels, and hence the messages). Basically, the WiFi invalid channel message means that the APs have detected some RF interferer devices transmitting on some shifted central frequency. For example, we have 1 - 13 channels on 2.4 GHz, imaging some device transmitting on channel 6.5 (in between 6 and 7), that will be invalid channel, which is simply detected by the Spectrum Expert of our ClearAir. What does WiFi Inverted mean? WiFi is encoded on the physical carrier using I and Q data; this is the relationship between phase, amplitude, and frequency. The following document explains this in depth: What is I/Q Data? Basically, spectrally inverted WiFi is a WiFi signal with the I and Q reversed; if you have a transmitter and a receiver both expecting this, you have an undetectable bridge (since normal WiFi chips will see noise).   *** ABOUT THE LOGS *** The logs basically show the AP name and radio that detected the invalid channel or inverted signal, as well as the channel used by the AP that could be affected by this RF interferer device: AP APNAME1[1] (84:78:ac:e8:23:80) Device ID: 0x613e, Type: WiFi Invalid Channel [31], Severity: 2, Channels: 149, Cluster ID: 0e:58:c0:73:61:c1, Previous Cluster ID: 0e:58:c0:73:61:c1, Event: Clear AP APNAME806[1] (50:1c:bf:b4:d8:00) Device ID: 0x20f2, Type: WiFi Inverted [30], Severity: 2, Channels: 149, Cluster ID: 0e:58:c0:7b:c9:8c, Previous Cluster ID: 0e:58:c0:7b:c9:8c, Event: Clear   The [31] doesn't make reference to a channel, but to the ID of this "Invalid Channel" or "Inverted" CleanAir detection action, and the Cluster ID is automatically made by CleanAir to give a MAC-Address based identifier to the interferer device that might not use MAC addresses (such as the signals from a Microwave oven). You can understand the purpose of this ID better with the following document: Cisco CleanAir - Cisco Unified Wireless Network Design Guide Therefore, you might want to physically look for RF interferer devices around the APs detecting and reporting these messages (so you can take them down -if possible- and if they are really affecting the performance of the WLAN). NOW, if this is generating too many traps and those RF interferer devices can't be tracked or taken down, or are not really affecting the WLAN, then the other recommendation we normally give for such scenarios is to disable the specific trap for these events (which are real events and there is nothing that can be done from the WLC to avoid them). You can disable the trap by using the following WLC command: config {802.11a | 802.11b} cleanair alarm device disable 802.11-nonstd In the end, the only way to put our finger on what exactly might be transmitting those signals on those locations, is by going onsite with a spectrum analyzer to confirm if what CleanAir is reporting is True: RF Signals on Invalid channels and inverted signals. If that onsite confirmation can't be done, then there is no way to confirm if this is actually true or not and we just need to rely on CleanAir, but if this is not happening anymore (just happened once or some days, and went away) then there are possibilities that this could happen due to: We have seen this on busy sites, generally the alert is of short duration, classified, then dropped. This indicates that this is likely due to a combination of collisions or bursty traffic that the APs can't interpret at all and perceives (due to the RF issues on the environment) that there are inverted signals or signals on invalid channels. In such cases this is basically a false alarm.   In addition, our Cisco RF engineers have confirmed the following: "WiFi Invalid Channel" is a WIFI packet that is not sent using the standard 802.11 channels, and so are invisible to normal WIFI clients, wIDS, and sniffers. This can also be achieved on any Wi-Fi chipset that the user has access to the radio command set. This used to be a very small subset of the market, but major manufacturers have recently released their HAL layers as open-source which significantly increases the risk from this type of attack: 802.11 relies on knowledge of the center frequency in the channel to properly align both receiver and transmitter. The amount of offset from the standard required varies by technology, for example: - For 11b (1/2/5.5/11), packets > 500 kHz from a nominal channel are not likely to be detected (except for +5M and +10M). - For 11a/g/n, packets > 250 kHz from a nominal channel are not likely to be detected. Hence, they can be used by hacker equipment to operate rogue networks that can't be detected by existing tools.   *** CONCLUSIONS *** Based on the information above, there are basically three possibilities for this scenario: 1) There are RF interferer devices (non-802.11) on the environment generating those signals. 2) RF on the environment is very busy, with interference and a combination of 802.11 collisions or bursty traffic. 3) There are actually hackers (basically using Rogue APs at the most, not specifically connecting to your WiFi infra) with the appropriate equipment sending signals at a frequency that is perceived as invalid channel for 802.11. For any of the three reasons, again, the only way to confirm if there are actually devices transmitting at these invalid frequencies or with those inverted signals (on those locations), is by going onsite with a spectrum analyzer to validate what CleanAir is telling us in case there are doubts. ... View more

I think the best way to troubleshoot a WLAN authentication issue is by first understanding clearly the process of the security method implemented, so I will first summarize how 802.1X/EAP works, as this is basically the secure Layer-2 authentication framework implemented on WLANs:   *** Components *** - Authentication Server: For WLANs this is a RADIUS Server where the authentication of the wireless clients actually takes place (ACS, ISE, Windows NPS, etc.). Here you define the specific EAP method that you want to allow and its settings (certificates, policies, etc.). Here you also have a local database with the client´s credentials to be checked, or it could be linked to an external database (AD for example). - Authenticator: This is the WLC/AP, and the role is basically to act as a "proxy" between the wireless client to be authenticated and the RADIUS Server that performs the authentication. Here you configure the SSID to force dot1X/EAP negotiation with the wireless clients trying to associate to this WLAN (using a specific key management and encryption method, like WPA/TKIP or WPA2/AES), and you define the RADIUS Server that will be used for this authentication. - Supplicant: The wireless client trying to connect to the secure WLAN. Here you configure the SSID profile that will be used for the association to this WLAN. You define the specific EAP method, and the client security credentials (username/password, certificates, tokens, etc.).   *** Authentication Process *** - The wireless client starts the association to the WLAN using the specific SSID and selecting an AP to connect. - Once basic wireless association is successful, WLC/AP sends an EAP identity request to the client in order start doing 802.1X/EAP. (Client could also start the EAP process by sending an EAPOL-Start to the AP). - The wireless client should answer back with an EAP identity response. - This response is sent from the WLC/AP to the RADIUS Server on a RADIUS Access-Request packet. - RADIUS Server processes the request and it replies back with a RADIUS Access-Challenge to start the EAP negotiation with the client (basically offering the client to start doing the EAP method that was configured for the wireless security policy). - WLC/AP receives this Challenge, and forwards it to the client as an EAP request. - Client answers back with an EAP response, which is forwarded by the WLC/AP to the RADIUS Server on another Access-Request. From here, the same exchange will happen multiple times between the server and the client (using the WLC/AP as intermediary) while the EAP method is negotiated and credentials are validated/authenticated. Depending on the EAP method we will see more/less exchanges, but in the end, the server should send to the WLC/AP a RADIUS Access-Accept if it passes (which contains the Master Session Key that will be used as the seed for the encryption cipher deployed, as well as the attributes that should be applied to this client -if used-) or a RADIUS Access-Reject if it fails. - The WLC/AP will inform the client about this result and deauthenticate it from the WLAN if it failed, or allowing it access to the network so it can start passing data traffic (if using WEP encryption, there is basically nothing else to do as the Master Session key derived during this authentication process is basically used as the seed for the encryption of the data frames that can now start passing between the client and the AP; if using WPA/WPA2, a key management process known as the 4-Way handshake should happen after the EAP-Success is sent to the client, so the Supplicant and Authenticator can derive first the encryption keys that will be used for the data frames following).   The Enterprise Mobility Design Guide is a very good public document we have with some of this information and more, so you can analyze this further: https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-5/Enterprise-Mobility-8-5-Design-Guide/Enterprise_Mobility_8-5_Deployment_Guide/MobilityGuide_Security.html   *** Important Facts *** - EAP is not a specific authentication method, but just the name of the base protocol. Based on this, a specific EAP method is actually configured for the secure authentication, which is selected depending on our needs, requirements, and what the devices support (such as LEAP, PEAP/EAP-MSCHAPv2, PEAP/EAP-GTC, EAP-TLS, EAP-FAST/MSCHAPv2, EAP-FAST/TLS, EAP-FAST/GTC, etc.). The following post can help as a quick summary about the EAP methods most commonly used for WLANs: https://supportforums.cisco.com/document/12572951/eap-methods-summary - This EAP method is only defined on the client (supplicant) and RADIUS Server (Authentication Server). Not on the WLC/AP (Authenticator). - EAPOL is the protocol used between the Supplicant and the Authenticator to transport the authentication frames between them (as 802.11 wireless Data Frames over the air), while RADIUS is the protocol used between the Authenticator and the Authentication Server to transport the authentication frames of this process (as UDP RADIUS packets over the wired infrastructure).   *** Troubleshooting *** Knowing that, without the need of understanding all the details about the specific EAP method deployed or about WiFi, you can easily Troubleshoot a WLAN authentication issue as follows: 1) First of all, check if the issue is happening to multiple clients/devices. If this is only happening to one, then more likely the issue is with the credentials of that client, or with the supplicant SSID setup on that client for the specific EAP method (or with the device itself, hardware or software). 2) If you confirm this is happening to multiple clients, then select one or two to troubleshoot. Check if the client is trying to connect to the SSID. If it is not even trying, the SSID is more likely not properly configured on the WLC/LAP. 3) Check the WLC/AP client association table so you can see the client status, if it is even trying to connect and what the status is. For example, on a Cisco WLC you will notice that the client is stuck on the authentication process because the client status will be 8021X_REQD. 4) If you noticed that the client is trying but failing or stuck on the authentication phase, then immediately check the failed attempts (failure authentication logs) on the RADIUS Server. 5) The server logs should normally tell you the reason of the authentication failure, but if you don´t see any attempts at all, then there could be an issue between the WLC/AP and the server. If there are failures on the server, the reasons are normally: EAP method not defined or not properly configured on the server or the client, wrong credentials, request is not matching the security policy defined, RADIUS Server has an issue with the external database (if used), RADIUS Server doesn´t know the WLC/AP trying to talk to it (it should be configured as AAA client -NAS- with a valid shared secret), the EAP method defined requires certificates from a CA (at least on the Server) and this is not properly setup... The server logs should normally be clear on the specific reason. 6) If you can´t find any logs at all on the server for attempts from this client and you know the WLC/AP is properly configured to communicate with this specific RADIUS Server, then there could be an issue between the WLC/AP and the server, so you might want to check network connectivity between them (proper routing, no ACLs/firewall blocking RADIUS traffic, no fragmentation issues, etc.). At this point, you could start this network troubleshooting between the Authenticator and the Authentication Server, but you could also start some debugging on the Authenticator, as this will clearly confirm if the problem is on the WLC/AP itself, in the client side, or in the server side, as you should see IF: - The WLC/AP even started with the EAP identity request or not. - If the client is responding with the EAP identity response or not. - If the WLC/AP is sending that response as a RADIUS Access-Request to the proper server or not. - If the server is responding (and how) or not. - If this response is forwarded to the client and if the client is responding, and then forwarded back to the server... Until the point you notice a failure due to a lack of response from the client, from the server, or because the WLC/AP is not forwarding what it should where it should. You could even check if the failure is happening during the key management negotiation (which normally happens due to software issues if the client actually supports the one configured on the WLC/AP). 7) After this, you will definitely focus your troubleshooting on the WLC/AP, the client side, or the server side, checking deeper connectivity between them (packet captures if needed), the settings of the specific EAP method defined on the client and the server, or looking for software issues due to bad behaviors on any of the three components.   *** Debug Notes *** CUWN On a Cisco WLC, you could use the following debugs: debug client <MAC-ADDRESS of the client you want to troubleshoot> debug aaa all enable   Some good material to understand the debugs: https://www.cisco.com/c/en/us/support/docs/wireless/aironet-1200-series/100260-wlc-debug-client.html https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/116493-technote-technology-00.html   Autonomous IOS On Autonomous IOS APs, you could use the following debugs: debug radius authentication debug dot11 aaa authenticator process debug dot11 aaa authenticator state-machine https://www.cisco.com/c/en/us/support/docs/wireless/aironet-1200-series/50843-debug-authen.html   NGWC For NGWC controllers developers have confirmed that running debugs on these platforms is processor intensive, so they want us to run traces instead, which are still very helpful to analyze the behavior. Therefore, we could use here ALL the following traces to troubleshoot the issue with one specific client: set trace wcm-dot1x eaptrace level debug  set trace wcm-dot1x detail level debug  set trace access-session method dot1x level debug  set trace group-wireless-client level debug  set trace wcm-dot1x event level debug  set trace wcm-dot1x aaa level debug  set trace aaa wireless events level debug  set trace access-session core sm level debug  set trace access-session method dot1x level debug set trace group-wireless-client filter mac xxxx.xxxx.xxxx  set trace wcm-dot1x event filter mac xxxx.xxxx.xxxx  set trace wcm-dot1x aaa filter mac xxxx.xxxx.xxxx  set trace aaa wireless events filter mac xxxx.xxxx.xxxx  set trace access-session core sm filter mac xxxx.xxxx.xxxx  set trace access-session method dot1x filter mac xxxx.xxxx.xxxx   - To clear the Traces from the log buffer use the following command (this will clear configured TRACE): set trace control sys-filtered-traces clear - To clear the trace Filter use the below commands: set trace group-wireless-client filter none set trace wcm-dot1x event filter none  set trace wcm-dot1x aaa filter none set trace aaa wireless events filter none set trace access-session core sm filter none set trace access-session method dot1x filter none set trace access-session core sm client dot11 filter none set trace access-session core sm client spi filter none set trace access-session core sm client filter none set trace access-session core sm feature filter none   More information about NGWC traces and debugs for EAP authentication troubleshooting is documented on the following configuration examples: http://www.cisco.com/c/en/us/support/docs/wireless/5700-series-wireless-lan-controllers/116600-config-eap-radius-00.html http://www.cisco.com/c/en/us/support/docs/wireless/5700-series-wireless-lan-controllers/117684-configure-WLAN-00.html http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/116532-configure-technology-00.html http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/117664-configure-WLAN-00.html   ... View more

Con el experto de Cisco: Jeal Jiménez Haga sus preguntas y aclare sus dudas a cerca de como implementar, configurar, y hacer troubleshooting/análisis en una Cisco WLAN, cubriendo las opciones y funcionalidades que se soportan hoy en día en los productos WLAN del portafolio de Cisco. Jeal Jiménez es ingeniero de soporte High Touch especializado en tecnologías WLAN (LAN inalámbrica). Anteriormente colaboró como ingeniero de soporte donde se centró en la tecnología LAN inalámbrica (WLAN / WiFi) en el Centro de Asistencia Técnica TAC, antes de ser promovido como escalation lead y trainer, trabajando también como administrador del laboratorio de Cisco durante estos años. Tiene más de nueve años de experiencia en el área de las tecnologías de LAN inalámbrica, y ha contribuido con documentación interna y externa en Cisco. También contribuyó para el examen escrito CCIE Wireless y demás certificaciones Cisco wireless (CCNA y CCNP). Poseé una Ingeniería de Sistemas de la Universidad Latina en Heredia, Costa Rica. Jeal también cuenta con las certificaciones CCNA, CCNP R&S, CWNA, CWSP, VCP5-DCV y CCIE Wireless (# 31554). Por favor use las estrellas para calificar las respuestas e indique si la respuesta que ha recibido es la correcta.   Puede ser que Jeal no pueda responder cada una de las preguntas debido la cantidad que anticipamos para este evento. Recuerde que usted puede preguntar o seguir haciendo preguntas en la comunidad de Wireless   Este evento estará disponible del lunes 27 de Julio al 12 de Agosto del 2015. ... View more