Android 10 Wi-Fi issues with WPA2 on Cisco IOS-XE and AireOS

Last updated on June 6th, 2020 at 08:19 pm

It was on October 19th when Cisco announced WPA3 support on the new AireOS 8.10 code. As of the date of this article, there are 3 versions of the code that fixes inherited bugs, 8.10.105, 8.10.112 and 8.10.121.

Also, on October 6th the IOS-XE Gibraltar 16.12.1s code was released for the new Catalyst 9800 controllers with WPA3 support. More recent versions 17.1.1s and 17.2.1 have been released to support new features to match those supported by the AireOS controllers.

On the other hand, the different operating system manufacturers added support for WPA3 some time ago and, in the case that concerns us, Google has added WPA3 support in Android 10.

The connectivity issue happens when using any combination of WPA2 on a SSID. It doesn’t matter if it is WPA2-Personal or WPA2-Enterprise mode, or even using WPA2-WPA3-SAE transition mode.

After further searching on the Internet, multiple users with different mobile devices already detected failures after the release of Android 10. And it seems that this issue s not only concerning Cisco WLAN solutions.

Connectivity Tests

The connectivity tests have been conducted only with Xiaomi Android 10 devices.

Different security settings have been tested, all of which have resulted in connection failures:

  • WPA2-PSK-SHA1: with 802.11w PMF (disabled/optional/required) and 802.11r FT (disabled, adaptive)
  • WPA2-PSK-SHA1-SHA256: with 802.11w PMF (disabled/optional/required) and 802.11r FT (disabled, adaptive)
  • WPA2-8021X-SHA1: with 802.11w PMF (disabled/optional/required) and 802.11r FT (disabled, adaptive)
  • WPA2-8021X-SHA1-SHA256: with 802.11w PMF (disabled/optional/required) and 802.11r FT (disabled, adaptive)
  • WPA2-WPA3-SAE-SHA1: with 802.11w PMF (optional/required) and 802.11r FT (disabled) ==> Test devices not supporting SAE at the time of this post
  • WPA2-WPA3-SAE-SHA256: with 802.11w PMF (optional/required) and 802.11r FT (disabled) ==> Test devices not supporting SAE at the time of this post
  • WPA2-WPA3-SAE-SHA1-SHA256: with 802.11w PMF (optional/required) and 802.11r FT (disabled) ==> Test devices not supporting SAE at the time of this post
  • WPA3-SAE: with 802.11w PMF required and 802.11r FT disabled ==> Test devices not supporting SAE at the time of this post

The next security features combinations resulted in sucessfull connection of Android 10 devices. The problem with those is that legacy mobile clients not support all of them, so the workaround recover newest devices but miss oldest ones:

  • WPA2-PSK-SHA256: with 802.11w PMF (optional/required) and 802.11r FT enabled
  • WPA2-PSK-SHA1: with 802.11w PMF (disabled/optional/required) and 802.11r FT enabled
  • WPA2-PSK-SHA1-SHA256: with 802.11w PMF (disabled/optional/required) and 802.11r FT enabled
  • WPA2-8021X-SHA1: with 802.11w PMF (disabled/optional/required) and 802.11r FT enabled
  • WPA2-8021X-SHA1-SHA256: with 802.11w PMF (disabled/optional/required) and 802.11r FT enabled
  • WPA2-8021X-SHA256: with 802.11w PMF (disabled/optional/required) and 802.11r FT disabled
  • WPA3-802.1X: with 802.11w PMF required and 802.11r FT disabled

IMPORTANT:

A list of devices that support WPA3-SAE is available on the Wi-Fi Alliance website (https://www.wi-fi.org/product-finder-results?sort_by=default&sort_order=desc&categories=4&capabilities=16&certifications=96). It shows that the devices that support it are all those released at the end of 2019 and beginning of 2020.

After running several configuration tests, and performing over-the–air packet captures (OTA) and performing debugs on the AP and controller, I can see the device does not transmit the Association-Request packet, which starts the connection process.

Since Android is based on a Linux system, it uses the wpa_supplicant service to connect to WLAN networks. So connecting to the device through the Android Debug Bridge (ADB) tool, and debugging the connection event log, we can see that the supplicant doesn’t send any packet (CTRL-EVENT-ASSOC-REJECT).

In the log output we can see some relevant information. This information shows that the wireless adapter driver recognizes several encryption suites, including the one used by WPA2 and WPA3 (CCMP-128).

(…)
wpa_supplicant: nl80211: cipher 00-0f-ac:1
wpa_supplicant: nl80211: Supported cipher 00-0f-ac:5
wpa_supplicant: nl80211: Supported cipher 00-0f-ac:2
wpa_supplicant: nl80211: Supported cipher 00-40-96:254
wpa_supplicant: nl80211: Supported cipher 00-40-96:255
wpa_supplicant: nl80211: Supported cipher 00-0f-ac:4 ==> (CCMP-128)
wpa_supplicant: nl80211: Supported cipher 00-14-72:1
wpa_supplicant: nl80211: Supported cipher 00-0f-ac:6
wpa_supplicant: nl80211: Supported cipher 00-0f-ac:11
wpa_supplicant: nl80211: Supported cipher 00-0f-ac:12
(…)
wlan0: Trying to associate with SSID ‘_WPA2-P-SSID’
wpa_supplicant: wlan0: Adapt 11r Enabled for BSS aa:11:22:33:44:5f
wpa_supplicant: eap_proxy: eap_proxy_notify_config
wpa_supplicant: eap_proxy: eap_proxy_allowed_method
wpa_supplicant: eap_proxy: eap_proxy_allowed_method
wpa_supplicant: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=aa:11:22:33:44:5f status_code=1
(…)

However, during connection attempts, there is no packet been sent from the device as displayed in OTA packet captures, the AP or the controller. This is the output shown in the Android debug:

wpa_supplicant: getCapabilitiesInternal capabilities: NONE IEEE8021X WPA-EAP WPA-PSK WPA-EAP-SUITE-B WPA-EAP-SUITE-B-192 OWE DPP FILS-SHA256 FILS-SHA384 FT-PSK
wpa_supplicant: eap_proxy: eap_proxy_notify_config
wpa_supplicant: wlan0: Trying to associate with SSID ‘_WPA2-P-SSID’
wpa_supplicant: wlan0: Adapt 11r Enabled for BSS aa:11:22:33:44:5f
QCNEJ/WlanStaInfoRelay: Received action: android.net.wifi.STATE_CHANGE
HingeNetworkManager: NETWORK_STATE_CHANGED_ACTION: mIsWifiConnected=false
DPMJ : |SERVICE| DPM received action android.net.wifi.STATE_CHANGE
CommStateMonitor: onReceive: android.net.wifi.STATE_CHANGE
QCNEJ/NativeHalConnector: -> SND notifyWlanStaStatusChanged([WlanStaInfo]: wifiSwitchState = 1 rssi = -127 ssid = DeviceNet bssid = aa:11:22:33:44:5f dnsInfo = 0.0.0.0;0.0.0.0;0.0.0.0;0.0.0.0; freqBand = _2GHz countryCode = [RatInfo]: networkType = 1 subType = 101 networkState = CONNECTING netHdl = -1 ipAddrV4 = ipAddrV6 = ifNameV4 = ifNameV6 = slotIdx = 0 isAndroidValidated = false) timeStamp = 2020-05-06 15:53:00.799
wpa_supplicant: eap_proxy: eap_proxy_notify_config
wpa_supplicant: eap_proxy: eap_proxy_allowed_method
wpa_supplicant: eap_proxy: eap_proxy_allowed_method
DPMJ : |SERVICE| sendWifiStatus – subType: 21 networkState: 0 softApState: 11 rssi=0 ssid= bssid=00:00:00:00:00:00 ipV4Addr= ifNameV4= ipAddrV6= ifNameV6=
wpa_supplicant: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=aa:11:22:33:44:5f status_code=1
wpa_supplicant: eap_proxy: eap_proxy_notify_config

For those interersted in a partial fix to this bug using WPA2-SHA256, below are the configurations changes for WPA2-Personal or WPA2-Enterprise SSID’s:

## WPA2-PERSONAL SSID
config wlan security wpa akm psk disable
config wlan security wpa akm pmf psk enable <wlan_id>
config wlan security wpa akm psk set-key ascii <psk> <wlan_id>
config wlan security ft disable <wlan_id>  <== must be disabled when removing previous security features if adaptive is selected
!

## WPA2-ENTERPRISE SSID
config wlan security wpa akm 802.1x disable <wlan_id>
config wlan security wpa akm pmf 802.1x enable <wlan_id>
config wlan security ft disable <wlan_id>  <== must be disabled when removing previous security features if adaptive is selected

3 June 2020 Update

After some investigation along with Cisco engineers, it seems that the issue is due to a firmware bug in some Qualcomm chipsets, and devices from Nokia/Sony/Xiaomi triggering that bug when processing newly added Cisco IE Att 44 in the beacons.

Qualcomm is fixing it per device model with new security patches (Mi10 received it with April 2020 security Patch).

From Cisco side, after many tests and troubleshooting sessions with engineers, there is an official workaround to avoid this issue.

  • Enable SHA256-only with any Fast Transition (802.11r) combination
  • Enable Fast Transition (802.11r): this workaround works using any SHA1, SHA256 or SHA1+SHA256 combination. This is covered under CSCvu24770.

These are all the security features I’ve tested:

PMF (disabled/optional/required)dot11r adaptivedot11r enableddot11r disableddot11r adaptive + overDSdot11r enabled + overDS
SHA1NoYesNoNoYes
SHA256InvalidYesYesInvalidYes
SHA1+SHA256NoYesNoNoYes
Xiaomi Mi8 + Cisco AP3800/4800


IMPORTANT:

During the last few days I have been collaborating on two threads from the Cisco community forum regarding these bugs.
These are the links:
AireOS: https://community.cisco.com/t5/wireless-and-mobility/issues-connecting-android-10-to-cisco-me/td-p/4009289
IOS-XE: https://community.cisco.com/t5/wireless-and-mobility/wlc9k8-ap9k-android10-connectivity-issue/td-p/4027403

I’m also working with Cisco TAC and BU engineers in the resoluition of this issue.

One thought on “Android 10 Wi-Fi issues with WPA2 on Cisco IOS-XE and AireOS

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.