Client moving between 2.4 & 5 whilst stuck in IP learn state

[Tob]

Platform: 9800-L-F

Software: 17.3.2a

SSID:

WPA(AES/TKIP)+WPA2(AESCCMP128) running simple PSK authentication. No L3 Auth involved.

The DHCP forwarding is orchestrated by the 9800 via the SVI.

After scouring the configuration and comparing 9800 & 5508 the differences in config is as follows, I don't think that any of these settings should cause the problems we are experiencing, but I'd be happy to be wrong in this:

Value:	5508	Configuration location GUI:	9800	Configuration location GUI:
Aironet IE	Active	WLAN	Not active	WLAN profile
11v BSS Transition	Not active	WLAN	Active	WLAN profile
11v Directed Multicast Service	Not active	WLAN	Active	WLAN profile
Off Channel Scanning Defer	4/5/6	WLAN	5/6	WLAN profile
AAA Auth list	Not specified	WLAN	Specified	WLAN profile
PMF	Not active	WLAN	Optional	WLAN profile
mdns snooping	Active	WLAN	-	WLAN profile
Radius profiling	Not Active	WLAN	Active	Policy profile
Client Exclusion Timeout	Active	WLAN	Not Active	Policy profile
MFP Client Protection	Optional	WLAN	Not Active	CLI
Unicast video redirect	Active	Wireless > 802.11….>Media>Media	Not Active	Radio configurations > Media parameters
Multicast Direct Enable	Active	Wireless > 802.11….>Media>Media	Not Active	Radio configurations > Media parameters

We have a client, a media streaming dongle which runs some software on top of android. The client works fine when connected to the old controller which is a 5508, but when connecting to the 9800 controller it gets stuck in IP Learn state. The SSID on the 9800 can accommodate other device types just fine, cellular phones, laptops etc. The problem seems to be that the client never even tries to request a DHCP lease, I used the built in packet capture feature of the 9800 to determine this. What I can see is this which is when the client moves between 2.4 & 5:

291065 291.070996 AMPAKTec_c3:1b:16 Cisco_b2:29:8e EAPOL 191 Key (Message 4 of 4)
291064 291.070996 AMPAKTec_c3:1b:16 Cisco_b2:29:8e EAPOL 195 Key (Message 4 of 4)
291045 291.057004 AMPAKTec_c3:1b:16 Cisco_b2:29:8e EAPOL 219 Key (Message 2 of 4)
291044 291.057004 AMPAKTec_c3:1b:16 Cisco_b2:29:8e EAPOL 223 Key (Message 2 of 4)
290990 290.994004 AMPAKTec_c3:1b:16 Cisco_b2:29:8e 802.11 270 Association Request, SN=34, FN=0, Flags=........, SSID=%SSID%
290989 290.994004 AMPAKTec_c3:1b:16 Cisco_b2:29:8e 802.11 274 Association Request, SN=34, FN=0, Flags=........, SSID=%SSID%
290165 290.172040 AMPAKTec_c3:1b:16 Cisco_b2:29:81 EAPOL 191 Key (Message 4 of 4)
290164 290.172040 AMPAKTec_c3:1b:16 Cisco_b2:29:81 EAPOL 195 Key (Message 4 of 4)
290155 290.158049 AMPAKTec_c3:1b:16 Cisco_b2:29:81 EAPOL 219 Key (Message 2 of 4)
290154 290.158049 AMPAKTec_c3:1b:16 Cisco_b2:29:81 EAPOL 223 Key (Message 2 of 4)
290081 290.083996 AMPAKTec_c3:1b:16 Cisco_b2:29:81 802.11 271 Association Request, SN=34, FN=0, Flags=........, SSID=%SSID%
290080 290.083996 AMPAKTec_c3:1b:16 Cisco_b2:29:81 802.11 275 Association Request, SN=34, FN=0, Flags=........, SSID=%SSID%

The client jumps between 2.4 & 5 very frequently as also shown by the radioactive trace:

2021/05/05 08:54:27.787535 {wncd_x_R0-0}{1}: [client-orch-sm] [19376]: (note): MAC: c084.7dc3.1b16 Association received. BSSID 2c57.41b2.2981, old BSSID 2c57.41b2.298e, WLAN %SSID%, Slot 0 AP 2c57.41b2.2980, %AP%

2021/05/05 08:54:28.708367 {wncd_x_R0-0}{1}: [client-orch-sm] [19376]: (note): MAC: c084.7dc3.1b16 Association received. BSSID 2c57.41b2.298e, old BSSID 2c57.41b2.2981, WLAN %SSID%, Slot 1 AP 2c57.41b2.2980, %AP%

2021/05/05 08:54:32.911876 {wncd_x_R0-0}{1}: [client-orch-sm] [19376]: (note): MAC: c084.7dc3.1b16 Association received. BSSID 2c57.41b2.2981, old BSSID 2c57.41b2.298e, WLAN %SSID%, Slot 0 AP 2c57.41b2.2980, %AP%

From the radioactive trace I can verify that the client authenticates just fine:

2021/05/05 08:54:28.779879 {wncd_x_R0-0}{1}: [client-auth] [19376]: (note): MAC: c084.7dc3.1b16 L2 PSK Authentication Success. EAP type: NA, Resolved VLAN: %VLAN%, Audit Session id: D5011BAC000173FF3AE1E5FD

I'm trying to work with the manufacturer of the client to check if we can get any information from the client as to what is going on, also trying to get the device to have a static IP to check if the client works when that is set.

Any ideas as to what may be causing the error would be appreciated.

[saravlak]

First, update WLC code to 17.3.3 or 17.4.1.
what's the client state on WLC or where does it show it stuck at.
are you using same AP model, Data rate and global/RF-profile config on both WLCs.

[Tob]

Under Monitoring > Clients, the state of the client is "IP Learn".

Not using the same AP model, 9120 on 9800, 2600/2700/2800 on 5508.

There are many differences in regards to the RRM when we changed platform, we did a pretty big overhaul. I'll have a look at changing those values back I guess and see if that fixes the error.
I would list them but when I try and post the values I get an error in HTML formatting which the page says is fixed but after that when I try and post the site says that its detected flooding.

I'll look into upgrading to 17.3.3 (that's a LOT of stability fixes), we cant move past that release since we run 2700s.

[Scott Fella]

Try to keep the SSID between the two as close as possible.  You chart show differences and maybe one of those features is breaking these device connections.  Rule of thumb is to always disable k,v,r and keep the wlans similar so you can test properly.

[Rich R]

And the other discussion recently about scanner that couldn't handle change from CCX v4 to v5 solved by disabling Aironet IE.

[saravlak · Accepted solution]

Try disabling PMF and test it.

[Tob]

Sorry, PMF is set to "optional", adjusted my original post now. But I will have a look at changing each value on the list to match such as is on the 5508, following this I will adjust RRM etc to match.

[saravlak]

sure, try with open wlan and different WLAN datarate setting.

[Tob]

So since the controller had been been partially implemented (we did try the problematic SSID prior to implementing), it took a long time to upgrade the controller, but it now sits on 17.3.3, the upgrade did not fix the issue.

The fix which allowed the client to request an IP address was to completely disable PMF, that would be going from "PMF optional" to "PMF disabled". I'm guessing the client did not communicate with the WLC that it cannot handle PMF and as such the WLC assumes that it should be enabled.

[JPavonM]

Is it an Android 10 device? Try some of the proposed solutions here:

https://community.cisco.com/t5/wireless-and-mobility/issues-connecting-android-10-to-cisco-me/m-p/4096960#M116570

Cisco solved this behaviour in 17.3.1 code (defect CSCvu24770) but you need to disable in the WLAN profile "Device Analystics" feature and don not use "FT Adaptive", enabled is recommended.

If not, then try upgrading to 17.3.3. Defect CSCvw30043 doesn't match here as you say this is an Android device, but let's give it a try.

HTH
-Jesus
*** Please Rate Helpful Responses ***