cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5393
Views
5
Helpful
33
Replies

5508 8.0.140.0 ipad dropping connection

the-lebowski
Level 4
Level 4

Hi, have an issue with HA 5508 running 8.0.140.0 and ipads dropping wifi.  When it happens the end user has turn off wifi and turn it back on to be able to reconnect to the SSID.   We are not doing client load balancing, session timeout is set to 28800 seconds and both client user idle timeout and threshold are disabled. 

Has anyone seen this before?  

 

 

33 Replies 33

Any of those changes service impacting?   Also I have PRIME and didn't realize it had syslogs for my WLC but not seeing anything there similar to what I saw while debugging from the WLC itself.  Just all informational and when I filter for the IPAD MAC I get no results.   Just a bunch of webauth and http_parser logs.  

Any of those changes service impacting? No.

Prime have a different structure, use any syslog application.

Got syslog-ng running today and will try to capture when one of them **bleep**s the bed. Just to clarify I have logs going to syslog-ng from the HA WLCs and set to 'Debugging,' should that be enough?

No, that will show only WLC based logs at debug-level and it may not necessarily have client disconnect detail, Forward the trap-logs to trap-log-serve with client traps enabled and have debug client enabled and forwarded to ext. syslog server.

How do I ensure I am forwarding trap=logs from WLC? I setup syslog-ng but it looks to have stopped logging anything after the first day.

 

BUT I was able to gather logs for the ipad which are attached.  Have to comb through them but I don't even know what to look for, can someone look and see?  MAC is 78:7B:8A:1E:A9:2E 

In addition to my reply from two days ago

These debug output can be overwhelming, due to this Cisco created a very handy tool which you can find it here.

Without a specific time-frame and problem description it is impossible to perform proper troubleshooting. However, the following things do stand out in your log:

  • The end-point roams between 802.11b/g/n and 802.11a/n/ac radios; has a site survey been conducted to verify proper coverage and capacity for both bands?
  • During connection #12 the end-point did not respond to the EAP identity request from the access-point (it might have been asleep?).

Thanks for that link. Site survey was done initially back in 2013 or so. Last year a co-worker added AC modules to the existing APs and that's when we started to see these problems.

In case you don't configure a idle time-out value within the WLAN the global system parameter will be used instead (which is 300 seconds by default). Due to this it is recommended to configure this feature on the WLAN.

You should choose a value which works best with your end-points and also suits your security needs. Do keep in mind that the 5508 can fit up to 7000 sessions, so monitor the concurrent client count while changing these values. Usually 3600 seconds is a good starting-point within enterprise networks.

Last but not least, your current version of AireOS is not the recommended one. Unless you have a specific reason please consider to upgrade to 8.0.152.0 which is the current stable release. In case the problems still exists after the idle time-out change and upgrade you do need to gather a "debug client xx" log during the event for further analysis.

Please rate useful posts... :-)

Regarding your note, "In case you don't configure a idle time-out value within the WLAN the global system parameter will be used instead (which is 300 seconds by default). Due to this it is recommended to configure this feature on the WLAN.

 

Are you saying that if under the WLAN, I have client user idle timeout unchecked, that it will globally set this to 300?

"Are you saying that if under the WLAN, I have client user idle timeout unchecked, that it will globally set this to 300?"

Yes, the global setting will be applicable in that case. You can find this setting under in the GUI under the "controller" tab.

Leo Laohoo
Hall of Fame
Hall of Fame

The output shows the SSID to be running OPEN authentication.  So tell us more about this iPad(s): 

1.  How many iPad(s) are affected?  One?  Two?  Dozen? 

2.  When this issue occurs, are the iPad(s) stationary or are they roaming around? 

3.  Observing the iPad(s) when this issue occurs, what RSSI are the iPad(s) showing?

4.  What exact model of iPad(s) and what Apple iOS are they running on?

Its not open, this wlan uses radius and AD on the backend to auth.   

 

1. Four ipads, all of which are in conference rooms.

2. Stationary and most docked in a conference room.  Reported by end users because they are in a meeting and the ipad loses connectivity to wifi and they have jump through hoops to get it to reconnect. 

3. No idea

4. I would have to find out

What are they using the iPads for?  They loose the connection when they are using it or is the issue when the wake up the iPad? Each iPad using a different login or shared because the latter can cause you issues. 

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

Zoom and audio/video control in the conference rooms. Not sure if they are being used actively when they lose connection and  I will get more details from the help desk. I believe they are using the same u/p but why would that matter?  Users login into wifi from multiple devices, phone and laptop, etc..  

Hi there, have you ever found a solution to those problems?

We are having exactly the same issue, also using iPads for zoom room scheduling. Thanks. 

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: