05-11-2021 12:57 AM - edited 07-05-2021 01:17 PM
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.
Solved! Go to Solution.
05-11-2021 11:33 PM
Try disabling PMF and test it.
05-11-2021 01:13 AM
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.
05-11-2021 02:51 AM - edited 05-11-2021 02:52 AM
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.
05-11-2021 09:25 AM
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.
05-11-2021 04:19 PM
And the other discussion recently about scanner that couldn't handle change from CCX v4 to v5 solved by disabling Aironet IE.
05-11-2021 11:33 PM
Try disabling PMF and test it.
05-11-2021 11:36 PM - edited 05-11-2021 11:38 PM
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.
05-11-2021 11:42 PM
sure, try with open wlan and different WLAN datarate setting.
06-21-2021 01:44 AM
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.
05-12-2021 12:24 AM - edited 05-12-2021 12:24 AM
Is it an Android 10 device? Try some of the proposed solutions here:
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 ***
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