04-04-2017 03:07 AM - edited 07-05-2021 06:48 AM
Hello Together
We have a WLC AIR-CAP2702I-E-K9 Software Version 8.0.121.0 and 700 Access Points AIR-CAP2702I-E-K9. Our Problem is now that the Roaming on stand by mode with Android divices doesen't work error free. If they raom from one cell to the next the have from time to time disconections and loss off calls. With the IOS devices it works fine. Our Roaming Settings for the SSID are.
Security WPA+WPA2
Fast Transition active
Over the DS Active or inactive wit hteh same results.
Reassociation Timeout 20 secconds.
PMF Dasabled
WPA+WPA2 Parameters only WPA2 Policy-aes Enabled
Authentication Key Management
802.1X enabled
FT 802.1X enabled
WPA gtk-randomize State disabled
What are the recommended settings for ios and android devices?
Are some bugs know about the roaming with Android device with the WLC Software Version 8.0.121.0?
Thanks your Help
Lukas
04-04-2017 05:02 AM
WLC Software Version 8.0.121.0
Upgrade this version. We've seen strange things happening with this version.
Not all Android firmware act the same. Are the Androids running on the latest firmware?
Make is simple: Can the Android roam well with OPEN authentication or not?
04-04-2017 06:01 AM
Yes the Android are running with the latest firmware. We have several SSIDs. Without authentication they roam well. Also with the following Settings they roam fine: SSID -> Security -> Layer 2 :
Security WPA+WPA2
PMF Disabled
Fast Transition inactive
WPA+WPA2 Parameters only WPA2 Policy-aes Enabled
Authentication Key Management
802.1X enabled
But the ios Device doesent roam at all.
Confirm the cisco sheet (Enterprise_Best_Practices_for_Apple_Devices_on_Cisco_Wireless_LAN) the configuration for the IOS must be like i describe at the beginn but with this settings now the Android have Problems to roam.
Now my question is if there are settings how work for Android and for ios or if there is a other solution.
Thanks
04-04-2017 02:19 PM
Hi Lukas,
To echo what Leo stated, it would be good to possibly migrate to a newer and recommended version of AireOS on your WLC:
Now with that out of the way, sounds like you have an interesting scenario on your hands! If I understand you correctly, you're stating that your Android client devices on the latest Android build are roaming but not well. Whereas the iOS 10 devices are not roaming at all?
What is the make/model of Android client devices you are encountering this issue with? Given that Android devices vary wildly in capabilities and behavior across that partner ecosystem, this will be an important distinction.
What is the make/model of the Apple iOS devices you are encountering this issue with?
What is the name or WLAN ID that these respective devices are connecting to? Can you post the full WLAN config for review?
For starters, do you know if your Android devices support 802.11r (Fast Transition / FT)? If so, you may want to consider enabling it on a test WLAN and connect a test Android as well as iOS 10 device to the test SSID and roam about your facility. Otherwise, the iOS devices will only be able to use Sticky Key Caching (SKC), and depending on your Android devices in question, they may or may not use SKC or OKC as a PMK caching/fast secure roaming method. At worst, your clients are having to go through full 802.1X/EAP authentication at every roam, which is typically time consuming and can be disruptive to ongoing VoWiFi calls, etc.
Can't say unless we can check the device specs to confirm/deny. Best case scenario is if they both support 802.11r, then you can enable it and use FT over-the-air methodology as outlined in the iOS Enterprise Best Practices on Cisco WLANs as a general template:
That said, as you observed issues with FT enabled (though do try FT over-the-air by disabling FT over-the-DS), the best thing at this point is to reproduce the issue you're observing and collect the following:
1. An over-the-air (OTA) packet capture (sniffer should be NTP synchronized).
2. Save the CLI session output for the following WLC debugs to a text file:
Once you have reproduced the issue and the test has concluded, you can disable the above debugs using the following CLI command:
3. At the end of your test, save the following CLI session output from your WLC to another text file:
4. At the end of your test, also save the following CLI session output from the AP(s) you encountered the issue on to separate text files (per AP) as well:
With that, you should be able to pinpoint what may be the issue or at the very least, get you started down the right path to resolution. You can also then upload these logs and OTA captures to a Cisco TAC case once opened and they can further advise if/as needed, and continue troubleshooting with you.
For those that are not faint of heart; if you want to do a true deep-dive (or if the above is found to not be sufficient in and of itself), you can go through all steps as outlined in the below article:
Hopefully that helps!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide