12-30-2020 03:24 AM - edited 07-05-2021 12:57 PM
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?
05-18-2021 12:00 AM
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
05-18-2021 06:02 AM
05-18-2021 11:40 PM
Can you explain what the session timeout is for? If you set a higher value, the disconnect will still be, but not so often.
03-09-2022 04:27 AM
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
03-09-2022 05:35 AM
@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?
03-09-2022 06:22 AM
03-23-2022 03:42 AM - edited 03-23-2022 05:06 AM
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 !
08-05-2022 08:24 AM - edited 08-05-2022 08:25 AM
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.
08-05-2022 05:45 PM
Disable WMM.
08-07-2022 08:16 AM
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.
08-07-2022 08:56 AM
08-07-2022 05:02 PM
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.
08-07-2022 05:06 PM
08-08-2022 01:00 AM
@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.
08-08-2022 01:14 AM
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 ?
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: