cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10392
Views
10
Helpful
6
Replies

WLC 5508 - iOS devices dropping WiFi after upgrade to 8.0.140.0

sean Riley
Level 4
Level 4

We upgraded our WLC 5508 this past weekend from v 8.0.121.0 to v 8.0.140.0.  Since we have noticed that iOS devices (iPad, iPhones) are dissociating from the WLC after they are idle/sleeping for a given period of time.  As soon as you unlock an iOS device it reconnects to the WLAN without issue.  This seems to be happening with both certificate and 802.1x authenticated devices.  We are using ACS for authentication.  We did not have this issue before the upgrade.  Windows laptops connecting to the same WLAN seem to be OK.

WLC is in HA mode and primary controller has control.

AP's are Aironet 3702i's in local mode.

Any suggestions on how to start debugging?

Thanks.

2 Accepted Solutions

Accepted Solutions

The iOS devices having this issue are not using webauth, but instead 802.1x, so I do not believe "Sleeping Clients" is valid.  Correct?

I tried adjusting the global "User Idle Timeout (seconds)" to 4 hours, but the devices still seem to be disconnecting before this timeout.

I did see the WLAN being used has "Enable Session Timeout" set to 30 minutes.  Does this setting take priority over the global "User Idle Timeout (seconds)"?

Still seems strange that we these problems did not crop up until after the last upgrade.  I verified the timeout settings are the same as they were in prior 8.0.121.0 version.

View solution in original post

Since you are not using webauth, sleeping clients doesn't matter and you shouldn't be able to set that. I would just disable the session timer and leave idle timer at 300 seconds which is default globally. Make sure you are only using either WPA/TKIP or WPA2/AES, the later is preferred. Also make sure you don't have client load balancing enabled. 

-Scott 

*** Please rate helpful posts *** 

-Scott
*** Please rate helpful posts ***

View solution in original post

6 Replies 6

Leo Laohoo
Hall of Fame
Hall of Fame

are dissociating from the WLC after they are idle/sleeping for a given period of time.

I believe this has something to do with Sleeping Clients. 

This ensures the wireless client's will maximize their battery life.  

The iOS devices having this issue are not using webauth, but instead 802.1x, so I do not believe "Sleeping Clients" is valid.  Correct?

I tried adjusting the global "User Idle Timeout (seconds)" to 4 hours, but the devices still seem to be disconnecting before this timeout.

I did see the WLAN being used has "Enable Session Timeout" set to 30 minutes.  Does this setting take priority over the global "User Idle Timeout (seconds)"?

Still seems strange that we these problems did not crop up until after the last upgrade.  I verified the timeout settings are the same as they were in prior 8.0.121.0 version.

Since you are not using webauth, sleeping clients doesn't matter and you shouldn't be able to set that. I would just disable the session timer and leave idle timer at 300 seconds which is default globally. Make sure you are only using either WPA/TKIP or WPA2/AES, the later is preferred. Also make sure you don't have client load balancing enabled. 

-Scott 

*** Please rate helpful posts *** 

-Scott
*** Please rate helpful posts ***

Disabling the session timeout for the WLAN seems to have resolved our problems.  Just not sure why this behavior did not crop up until after the last upgrade, since the behavior we experienced was in-line with our configuration.  Thanks.

If you "disable" the session timeout on a 802.1x enabled WLAN the default value of 86400 will be used. You had it configured for 30 minutes before which means that the session will be terminated every 30 minutes no matter what. The idle time-out is a "early clean-up feature" which will remove the client before the session timeout expired based on inactivity.

Please rate useful posts... :-)

rafael.alves
Level 1
Level 1

Can you put one IOS client to debug:

(Cisco Controller) >debug client <XX:XX:XX:XX:XX:XX>

And get the logs it shows. You'll be able to determine the issue analyzing the log itself.

Review Cisco Networking for a $25 gift card