Clients periodically can not connect to WiFi

[Alexander Khokhlov]

Hello

WLC 5520,8.3.150.0,AP2802, Dell 7490 (Windows witct corporate certificate)

 There are more than 100 points in total, the accident appears at different points at different times. Clients periodically can’t connect to the SSID with 802.1x protocol on one of the points.

Wherein:
- can connect to the SSID with 802.1x at other points
- can connect to the another SSID (with PSK) at the same point
Reloading the point temporarily helps, but then the problem appears on another point.

the command "debug client 7C:2A:31:XX:XX:XX" gives output on the controller only if the client connects to the network with a PSK. If the client connects to the network with a 802.1X, then there is no output on the controller.

[marce1000]

               - Ref : https://developer.cisco.com/docs/wireless-troubleshooting-tools/

  Have a sanity check of your controller configuration with https://cway.cisco.com/tools/WirelessAnalyzer/  , 

  further more use the https://cway.cisco.com/tools/WirelessDebugAnalyzer/   for client debugging (e.g)

 M.

[Alexander Khokhlov]

1. I don’t touch the configuration analysis yet, because the accident is temporary and occurs after a reboot point
2. during an accident, the command "debug client XX.XX." on the WLC does not output anything, and its output on the point is not analyzed by this link (https://cway.cisco.com/wireless-debug-analyzer/)   (input file AP_TEST -  I just did a test - I clicked delete on a regular client)

[marce1000]

  >1. I don’t touch the configuration analysis yet, because the accident is temporary

   Poor argument , you should do the reverse and take the configuration analysis

 M.

[Alexander Khokhlov]

performed analysis
regarding 802.1 only found this, but I think this is not what I'm looking for

30064

General: EAPoL request timeout larger than 400 ms. EAP key requests may benefit for faster recovery, and better behavior on bad RF, by using higher counts, lower retry timeout. Please validate on your specific client types before enforcing the changes

Action: EAPoL request timer found to be higher than 400ms. In most scenarios, 400 would allow faster recovery in case of problems. Some devices may need longer timers, so always check. Use command: config advanced eap eapol-key-timeout, to adjust

still it became interesting, just might explain why I do not see the output of the "debug client XX" on the controller

30123

General: Multicast Unicast forwarding mode is enabled, and either multicast or broadcast is in use with more than 50 APs. Depending on network traffic characteristics, this could have large performance impact. It is advisable to use multicast-multicast mode to prevent issues, which may have multicast routing dependencies on your infrastructure

Action: None

[Scott Fella]

You should not have the need to define multiple wireless profiles on a client, that may be what is causing issues. If the client device is under your control, it should be using 802.1x SSID not PSK. Try to remove the PSK profiles and any other profiles that use other SSID's in your network, then just have that user provide his or her feedback after a few hours or the end of the day to see if that helps. When a device switches SSID's you need fast ssid enabled, also keep in mind if the issue is when the device switches SSID's by itself and the user complains of loosing network availability due to being on a different network. If you think its an issue with one access point, swap that out with another and test or just rma it and see if that fixes it.

[Alexander Khokhlov]

1. First, problems with 802.1x started, and then they just started to apply a profile with a PSK
2. access points are always different, so I don’t think about them
3. when trying to connect manually, the user sees "checking network properties", i.e. no jumps to other places

[Scott Fella]

Well your issue is then with how 802.1x is deployed. Can be your wlan configuration, your radius server or policy, the nic driver and or the device wireless profile settings. If you don’t see any debug output’s on the controller, then it’s how the wlan profile is defined, it’s not performing 802.1x the way it’s supposed to. I just ran into issues like that last week and it was due to the device having a bug which was not setting the EAP-PEAP configuration properly.

[Rich R]

8.3.150.0 went end of software maintenance 15th Nov 2019 https://www.cisco.com/c/en/us/products/collateral/wireless/8500-series-wireless-controllers/bulletin-c25-742339.html so even if this is caused by a bug Cisco won't fix it. You should really be looking to upgrade to a current release of code like 8.5.161.0 or later which has literally hundreds of bug fixes since 8.3.150.0 - check the release notes for details of resolved caveats.

[Alexander Khokhlov]

I would gladly upgrade to version 8.5, but we have 29 points 1261 that do not want to change to new ones.

[Scott Fella]

Well you still need to review the radius logs etc. You need to eliminate the variables I specified to make things easier.

[Alexander Khokhlov]

I tried the command "debug client XX.XX.XX" on WLC during the accident. When connected to a network with a PSK, information is displayed. When connected to a network with a 802.1x, there is nothing in the output of the controller. Information does not even reach the radius server.

I don’t think that our client is to blame, because:
if you go to another point, then the client connects via 802.1x
if you reboot this point, then the client will also connect via 802.1x

[Scott Fella]

That points to your device wireless profile being wrong or a bad NIC like I mentioned. You need to eliminate those pieces. When you don’t see the debug in the client it’s because the device is not associating properly.

[Scott Fella]

If you believe the client device is not the issue, then the issue is with your wireless. Either your wlan settings or a bug, which you can look up in the bug tool. 802.1x being a bug with a code version will show up there, if you can’t find anything, then it’s your configuration.