WLC 8540 authentication debug for a client

[Aleck_Sei]

Hello everyone

We work with a WLC 8540 (version 8.5.161.6) and Cisco 2802 and 3802 AP, and an external Radius server to perform authentication.
We need to trace one or several clients on the WLC to see what messages we receive from the Radius, both for OK and KO authentication.
If we use the commands:

(Cisco Controller) >debug client 00:00:00:00:00:00
(Cisco Controller) >debug aaa all enable
(Cisco Controller) >show debug

The WLC starts flooding the screen with all events, not just my client's. How can we do it?
On the other hand, is there a way to see the authentications of a particular client in the WLC Log history?

Thank you very much
@jorge1976

[balaji.bandi]

In order to enable mobility debugs, use the debug client <MACAddress>, and then use the debug mobility handoff enable command:

(Cisco Controller) >debug client 00:00:00:00:00:00   ( this should be client real MAC address example - debug client 04:f7:e4:ea:5b:66)
 
 (Cisco Controller) >debug mobility handoff enable 

here is some reference guide for troubleshooting :

https://mrncciew.com/2014/10/15/wlc-client-debug-part-1/

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/4400-series-wireless-lan-controllers/112064-wlc-commands.html

[Aleck_Sei]

Thank you very much for your answer.

I think something is wrong with the WLC. I choose a completely invented MAC with a client passing by and data immediately 
begins to appear on the screen... I don't understand what it could be.

(Cisco Controller) >debug client 00:00:00:00:00:aa

(Cisco Controller) >*Dot1x_NW_MsgTask_1: Feb 22 10:58:45.102: [PA] 1x: EAPOL frame with dst MAC 00:a3:8e:fe:c7:40 and BSSID 00:a3:8e:fe:c6:40 discarded
*Dot1x_NW_MsgTask_1: Feb 22 10:58:45.731: [PA] 1x: EAPOL frame with dst MAC a0:e0:af:6a:47:40 and BSSID a0:e0:af:73:8a:c0 discarded
*Dot1x_NW_MsgTask_6: Feb 22 10:58:48.840: [PA] 1x: EAPOL frame with dst MAC 70:db:98:67:27:e0 and BSSID f8:0b:cb:f0:ee:80 discarded
*Dot1x_NW_MsgTask_1: Feb 22 10:58:48.941: [PA] 1x: EAPOL frame with dst MAC 70:df:2f:4a:a3:80 and BSSID 70:df:2f:4d:f6:80 discarded
*Dot1x_NW_MsgTask_5: Feb 22 10:58:49.177: [PA] 1x: EAPOL frame with dst MAC 50:0f:80:a0:91:60 and BSSID 50:0f:80:ac:81:a0 discarded
*Dot1x_NW_MsgTask_5: Feb 22 10:58:49.369: [PA] 1x: EAPOL frame with dst MAC 70:db:98:10:99:80 and BSSID f8:0b:cb:f0:f3:a0 discarded
*Dot1x_NW_MsgTask_4: Feb 22 10:58:50.869: [PA] 1x: EAPOL frame with dst MAC 40:01:7a:8f:89:40 and BSSID 40:01:7a:97:1b:c0 discarded
*Dot1x_NW_MsgTask_4: Feb 22 10:58:51.208: [PA] 1x: EAPOL frame with dst MAC 6c:b2:ae:69:d0:00 and BSSID 6c:b2:ae:89:38:80 discarded
*Dot1x_NW_MsgTask_1: Feb 22 10:58:52.707: [PA] 1x: EAPOL frame with dst MAC 00:a3:8e:d5:18:60 and BSSID 00:a3:8e:d5:1b:e0 discarded
*Dot1x_NW_MsgTask_0: Feb 22 10:58:54.885: [PA] 1x: EAPOL frame with dst MAC 70:df:2f:80:dd:00 and BSSID 70:df:2f:03:4f:c0 discarded
*Dot1x_NW_MsgTask_4: Feb 22 10:58:56.640: [PA] 1x: EAPOL frame with dst MAC 00:2a:10:06:a4:d0 and BSSID 00:81:c4:d1:df:30 discarded
*Dot1x_NW_MsgTask_0: Feb 22 10:58:57.896: [PA] 1x: EAPOL frame with dst MAC 50:0f:80:f7:40:00 and BSSID 38:90:a5:09:2e:80 discarded
*Dot1x_NW_MsgTask_2: Feb 22 10:58:58.115: [PA] 1x: EAPOL frame with dst MAC 70:7d:b9:24:ef:e0 and BSSID 00:a3:8e:fe:b6:80 discarded
*Dot1x_NW_MsgTask_4: Feb 22 10:58:59.067: [PA] 1x: EAPOL frame with dst MAC 6c:b2:ae:53:f2:60 and BSSID 6c:b2:ae:6c:d4:60 discarded
*Dot1x_NW_MsgTask_6: Feb 22 10:58:59.218: [PA] 1x: EAPOL frame with dst MAC 00:27:e3:09:93:60 and BSSID 00:a3:8e:f8:78:40 discarded
*Dot1x_NW_MsgTask_0: Feb 22 10:58:59.374: [PA] 1x: EAPOL frame with dst MAC 00:2c:c8:fc:a0:e0 and BSSID 00:2c:c8:bc:7a:e0 discarded
*Dot1x_NW_MsgTask_6: Feb 22 10:58:59.403: [PA] 1x: EAPOL frame with dst MAC 00:27:e3:09:95:a0 and BSSID 00:a3:8e:fe:c7:60 discarded

[Mark Elsen]

 - You may leave the particular vty session 'alone' and reconnect to the controller through a new session ; note that client debugs can be analyzed with https://cway.cisco.com/wireless-debug-analyzer , your problem could be due to console messages having been directed to the vty connection too, in that case you may try terminal no monitor in enable mode , 

 M.

[Aleck_Sei]

Thank you very much for your answer.
I did what you suggested but without success. I think something is wrong with the WLC. If I do a debug with an invented address,
and launch the "debug AAA all enable" command, messages from all clients start to flood my screen, not just mine....
If I'm not mistaken, only events related to my address should appear.

[Mark Elsen]

                    >... messages from all clients start to flood my screen, not just mine...
  Possibly a bug  look into :  https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-tac-recommended-aireos.html

 M.

[Rich R]

1. "debug AAA all enable" is enabling debug for *all* AAA events, transactions, packets.

2. debug client 00:00:00:00:00:aa should only enable debugs for that client but it's a well known problem that in fact you get many unrelated debugs on newer versions of AireOS.  Using the debug analyzer (link provided by Marce) helps to filter that output for meaningful logs and presents a nicely formatted output.

3. Like Marce said already - update your software.  I recommend 8.5.182.7 or 8.10.183.0 - the current latest 8.5 and 8.10 releases.

[Aleck_Sei]

Thank you very much!