cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
27628
Views
30
Helpful
29
Replies

Wireless AC Clients Randomly Disconnect

GiddyWhenSane
Level 1
Level 1

Users are being randomly disconnected from the wireless APs, all users are not disconnected at the same time.

 

When Windows clients are disconnected they receive the "globe" rather connected icon. After about 10-15 seconds the connectivity is restored without the user taking any action.

 

There is no indication they are being disconnected from the wireless network. We have received another incident where a Apple Macbook was disconnected so we are certain this is not specifically a windows problem.

 

The SSID is configured for both 2.4Ghz and 5Ghz bands with PSK and the clients have a DHCP lease of 1 day gathered from a separate DHCP server.

 

Devices involved:
WLC 9800-CL (16.12.4a)
10 x C9120AXI-E (16.12.4.31)

 

Disconnect occurs across the entire office space, do not believe this to be a specific AP issue.

 

As the time they are disconnected is so short, I initially wanted to go back to the users and advise that this just one of the issues of wireless networks in a shared office space. The client however is adamant they want to know why this is occurring.

 

All APs have been updated to attempt to resolve the issue as have the clients wireless drivers.

 

Copy of the radioactive trace logs attached when a disconnect occurred. I was unable to find an official reference for what the state transitions mean so I'm guessing that if a client was in "S_CO_RUN" it has previously successfully associated so when a client goes from "S_CO_RUN" to "S_CO_ASSOCIATING" it is an indication of a disconnect?

 

Also attached logs from a Windows client but they do not match with the actual times the client is disconnected.

 

Any suggestions on next steps to troubleshoot?

29 Replies 29

PT04647
Level 1
Level 1

Check session timeout in WLAN Policy Profile settings, by default on 16.12.4a is a 1800 seconds.

 

Users complaints about disconnection from Wi-Fi and the need to reconnect. Or the Wi-Fi connection worked, but the Internet did not work - reconnection solved the problem.

 

In trace logs of one problem client: Deleting the client, reason: 24, CO_CLIENT_DELETE_REASON_SESSION_TIMEOUT


Setting the session timeout to 0 solved the disconnection problem.

 

My setup WLC 9800-L 16.12.4a, C9115AXI-R 16.12.4.31

Keep in mind that there is a bug when setting the session timer to 0. Recommendations is to set it at the highest value.
-Scott
*** Please rate helpful posts ***

Can you explain what the session timeout is for? If you set a higher value, the disconnect will still be, but not so often.

ahmad.syed
Level 1
Level 1

Hi Team,

 

I am facing same issue of having globe icon on taskbar with disconnection . But its happening randomly and not for all user. 

We have central switching deployment with ISE

JPavonM
VIP
VIP

@GiddyWhenSane when you say Windows shows the globe is not usefull. Does the client disconnect, or does the client lose IP address? Can you see client connected with current association to the APs? Is this happening when they are static or are they moving and romaing between APs?

Hi ,

@JPavonM Yes, client disconnect. Its happening when they are static and its random 

 

Fabien Guicherd
Level 1
Level 1

Hello !
It seems that i have a similar problem, random disconnection on some laptops that are statics. But it seems that they lost "IP connection" and not wireless connection. 

When it occurs they still are connected to wifi but don't have access to the network. They have to disconnect and reconnect to the SSID (these explanation are from the customer, i have not see it by myself)

 

9800CL in 17.3.4c with AP9115 ; device drives are up to date, but the SSID they are using is with 802.1X and not PSK, in Flex mode

They are in HSRP mode with their Core Switchs (10.38.51.251 and .252).

 

We have debug enable on a computer, the user report problem at the following time : 9:50 / 11:52 / 14:40 / 17:28

Around these times, i have a lot of DHCP log like this :

2022/03/21 09:49:13.095382 {wncd_x_R0-0}{1}: [sisf-packet] [21465]: (info): RX: DHCPv4 from interface capwap_90000019 on vlan 51 Src MAC: dc41.a916.e284 Dst MAC: ffff.ffff.ffff src_ip: 0.0.0.0, dst_ip: 255.255.255.255, BOOTPREQUEST, SISF_DHCPREQUEST, giaddr: 0.0.0.0, yiaddr: 0.0.0.0, CMAC: dc41.a916.e284 
2022/03/21 09:49:13.097693 {wncd_x_R0-0}{1}: [sisf-packet] [21465]: (info): RX: DHCPv4 from interface capwap_90000019 on vlan 51 Src MAC: 4ce1.76ab.33c6 Dst MAC: ffff.ffff.ffff src_ip: 10.38.51.251, dst_ip: 255.255.255.255, BOOTPREPLY, SISF_DHCPACK, giaddr: 10.38.51.251, yiaddr: 10.38.51.154, CMAC: dc41.a916.e284
2022/03/21 09:49:13.097853 {wncd_x_R0-0}{1}: [sisf-packet] [21465]: (info): RX: DHCPv4 from interface capwap_90000019 on vlan 51 Src MAC: 4ce1.75f3.25c6 Dst MAC: ffff.ffff.ffff src_ip: 10.38.51.252, dst_ip: 255.255.255.255, BOOTPREPLY, SISF_DHCPACK, giaddr: 10.38.51.252, yiaddr: 10.38.51.154, CMAC: dc41.a916.e284
2022/03/21 09:49:15.100215 {wncd_x_R0-0}{1}: [auth-mgr-feat_dsensor] [21465]: (info): [dc41.a916.e284:capwap_90000019] Skipping DHCP TLVs for further processing. DHCP based classification isn't enabled
2022/03/21 09:49:15.100295 {wncd_x_R0-0}{1}: [sisf-packet] [21465]: (info): RX: DHCPv4 from interface capwap_90000019 on vlan 51 Src MAC: dc41.a916.e284 Dst MAC: ffff.ffff.ffff src_ip: 0.0.0.0, dst_ip: 255.255.255.255, BOOTPREQUEST, SISF_DHCPREQUEST, giaddr: 0.0.0.0, yiaddr: 0.0.0.0, CMAC: dc41.a916.e284
2022/03/21 09:49:15.102368 {wncd_x_R0-0}{1}: [sisf-packet] [21465]: (info): RX: DHCPv4 from interface capwap_90000019 on vlan 51 Src MAC: 4ce1.76ab.33c6 Dst MAC: ffff.ffff.ffff src_ip: 10.38.51.251, dst_ip: 255.255.255.255, BOOTPREPLY, SISF_DHCPACK, giaddr: 10.38.51.251, yiaddr: 10.38.51.154, CMAC: dc41.a916.e284
2022/03/21 09:49:15.102538 {wncd_x_R0-0}{1}: [sisf-packet] [21465]: (info): RX: DHCPv4 from interface capwap_90000019 on vlan 51 Src MAC: 4ce1.75f3.25c6 Dst MAC: ffff.ffff.ffff src_ip: 10.38.51.252, dst_ip: 255.255.255.255, BOOTPREPLY, SISF_DHCPACK, giaddr: 10.38.51.252, yiaddr: 10.38.51.154, CMAC: dc41.a916.e284
2022/03/21 09:49:16.546488 {wncd_x_R0-0}{1}: [sisf-packet] [21465]: (debug): RX: ARP from interface capwap_90000019 on vlan 51 Source MAC: dc41.a916.e284 Dest MAC: ffff.ffff.ffff ARP REQUEST, ARP sender MAC: dc41.a916.e284 ARP target MAC: 0000.0000.0000 ARP sender IP: 10.38.51.154, ARP target IP: 10.38.51.154,

 

So it can be a reason for their problem, but why it occurs ?

We will try to configure some device ip fixed ip to bypass the DHCP and see if we still have the problem

 

I attach the full logs of the day to the post if someone see another usefull logs

 

Thanks !

Kevin Litman
Level 1
Level 1

Any luck with resolving this issue? We just implemented the C9800-CL running 17.3.5a with 9115axi AP's and are having the EXACT same issue. We are using 802.1x and Flex.

Disable WMM.

JPavonM
VIP
VIP

Have you tried latest chipset driver releases?

I have found multiple connectivity issues with Realtek, Mediatek and Intel based chipsets in multiple codes, and there are multiple well-known issues that developers from such chipsets are constantly fixing.

Yeah, that's one of the first things we checked.

Intel chipset drivers are easy to download. 
Realtek drivers, however, is extremely difficult.  Realtek drivers found in the laptop manufacturer's website is not up-to-date and we ended up going to some dodgy website just to get newer firmware version.

All our laptops have Intel drivers. It's not affecting everyone so I wouldn't be surprised if it's a wireless adapter issue though. We had no issues before moving from our WLC 2504 and 3702i AP's.

JPavonM
VIP
VIP

@Kevin Litman it was working before doesn't mean it should be working now.

Take into consideration you have moved from an AC Wave 2 AP to an AX Wave 1 AP so all the communications between AP and chipset have changed dramatically with the addition of new fileds during connection negotiation that could lead to connectivity issues if both the AP code and the chipset drivers are not up-to-date. Additionally, issues do not neccesarily have to appear to all devices.

Have you checked session timeout? Try to use 54000 or 86400 values,

Try to configure the PSK SSID with all basics, disable PMF, FT and CCKM, use SHA1, disable Aironet, WMM and assisted roaming (dot11k/v) and try again.

If nothing works, then open a TAC case for further investigation.

Fabien Guicherd
Level 1
Level 1

After some tests we found out that the problem come from the 802.1X configuration
If we configure the SSID with PSK, we don't have the problem anymore.

As @JPavonM  suggest, we have configure the session timeout to 36000 if i remember, so people can stay connected an entire working day without beeing disconnected

Actually we are using the 9800CL with a Windows radius server, so our following step is to try another radius server to see if it's working and if the problem come from the 9800 or the Windows radius
Or if someone already have test this ? Or use another radius server actually maybe ?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: