Question about WLC "debug client" command

[roesch4alc]

Hi all,

I´m using the debug client xx:xx:xx:xx:xx:xx command to troubleshoot some clients. With this command my controller activates different debugging options:

Debug Flags Enabled:
dhcp packet enabled.
dot11 mobile enabled.
dot11 state enabled
dot1x events enabled.
dot1x states enabled.
mobility client handoff enabled.
pem events enabled.
pem state enabled.
802.11r event debug enabled.
802.11w event debug enabled.
CCKM client debug enabled.

But I´ve realised, that after a specific time, the debugging will automatically stop. The mac addresses that was subject to my debugging, are still listed in the sh debug command, but all the mentioned options are gone away... Does somebody know, why this happens? Is this a security option for not create high load on the controller or why does the controller stop debugging as i configured it? I already searched for this, as I expect, that this is a known behaviour, but I didn´t find anything on this.

But I think some of you guys will know the answer

Regards

Sebastian

[Prakash Parvathala]

HI

Check this link below it may help you

http://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/112064-wlc-commands.html

Thank you

[roesch4alc]

Hi,

this document didn´t give an answer to my question, but meanwhile I´ve read, that the debugging will only be active as long the terminal session will be. I´ve already configured an ssh timeout of 2hours... Is there a way to extend this time or is there a way to execute the debugging seperate from the terminal session?

[sekhabbaz]

Use the "screen" application from any unix/Mac terminal session. 
When inside screen type ctrl+a and then H (capitol H) , this will start logging the screen session to a file called screen log.0 . Inside the screen session you just ssh to your WLC, start the debug and the detach from the screen session: ctrl + a and then d. 

Screen will keep the session alive for as long as its running. 

Good luck! 
Best regards Sebastian

[mohanak]

The command debug client <MACADDRESS> is a macro that enables eight debug commands, plus a filter on the MAC address provided, so only messages that contain the specified MAC address are shown. The eight debug commands show the most important details on client association and authentication. The filter helps with situations where there are multiple wireless clients. Situations such as when too much output is generated or the controller is overloaded when debugging is enabled without the filter.

The information collected covers important details about client association and authentication (with two exceptions mentioned later in this document).

The commands that are enabled are shown in this output:

(Cisco Controller) >show debug
 
MAC address ................................ 00:00:00:00:00:00
 
Debug Flags Enabled:
  dhcp packet enabled.
  dot11 mobile enabled.
  dot11 state enabled.
  dot1x events enabled.
  dot1x states enabled.
  pem events enabled.
  pem state enabled.

These commands cover address negotiation, 802.11 client state machine, 802.1x authentication, Policy Enforcement Module (PEM), and address negotiation (DHCP).

Refer link : http://www.cisco.com/c/en/us/support/docs/wireless/aironet-1200-series/100260-wlc-debug-client.html

[suresh natarajan]

Our controller managing many AP's with different regions in the globe and lot of clients.

Only one country APs having these logs:

%DOT1X-3-ABORT_AUTH: [PA]1x_bauth_sm.c:457  Authentication Aborted for client

%DOT1X-4-MAX_EAP_RETRANS: [PA]1x_ptsm.c:528 Max EAP retransmissions exceeded for client

If i enable these following two debug commands , is it only for the MAC ?

or aaa debug logs will flood for the other clients too and make WLC busy?

debug client <AA.BB.mac>

debug aaa all enable

[Scott Fella]

Best to first debug the client and look at that data. The debug aaa will show you everything that comes back to the controller and then you will have to filter it.
I would try to get some feedback from folks onsite to see if things are working well. It can be some devices with bad NICs or profiles having issues or a device that tried to manually connect to that SSID that isn’t part of your domain. You can look at the logs and see if a username comes in and verify if indeed that is one of your managed devices. That is if you are using 802.1x. PSK, you will not know unless you have a device list.

[JM700]

Try using-

config session timeout 0

You will need to logout manually after executing this command