This article describes the issue of the client in the session manager (SM) traces pointing to a client disassociation.

The client in the session manager (SM) traces points to a client disassociation.

If you activate the sm traces (set trace sm level 10) you can observe the cause for a client being disconnected.

If you get the following set of messages:

SM-DOT11: sm_dot11_handle_deassociate: ev type 5 (good), token 0, mac xx:xx:xx:xx:xx:xx > the wireless client sends a deassociate request
SM-STATE: (2) mac xx:xx:xx:xx:xx:xx, flags 1807800228a12fh, to change state ACTIVE -> DEASSOCIATED, by sm_dot11_handle_deassociate > the client's state transitions from ACTIVE to DEASSOCIATED, as the session is going to be deleted after the client's request
SM-DOT11: sending de-assoc response for client xx:xx:xx:xx:xx:xx > the controller is sending a deassociate response to the client that sent the deassociate request        
(2) sm_do_client_boot: xx:xx:xx:xx:xx:xx will be removed from AP with deauth frame > this is the second part of the above line; it states that a packet is sent towards the client; on its way, it clears the internal data related to xx:xx:xx:xx:xx:xx from the controller and from the AP
SM-EVENT: forcing disassociation and de-auth of client at xx:xx:xx:xx:xx:xx, AP 1, qp=0  > this is also part of the internal clearance of the logs for this client

So, if you see that the wireless client is losing connectivity to the AP/network and the above message in the sm traces, it means that the diassociation came from the client's side. This means that the client has something that they do not like and decides to disconnect. Further debugging should also be done on the client's side; maybe even some wireless packet captures.

2020-10-10: Archived article.