09-06-2025 11:16 PM - edited 09-17-2025 07:05 AM
Hi everyone,
I’m running into an issue where clients get stuck in "IP Learn" when trying to connect to a WPA3-Enterprise 192-bit (CNSA / GCMP256 + SuiteB192X) SSID.
Controller: C9800-CL
IOS-XE Versions tested: 17.12.4 to 17.12.5, 17.15.4
Access Point: AP3802, AP2802
Clients:
Intel AX210 (latest driver, Windows 11 23H2)
iPhone 13 Pro (iOS 18.6.2)
Issue:
On 17.12.5 and 17.15.4, clients stuck in "IP Learn" when joining the WPA3-Enterprise 192-bit SSID.
On 17.9.7 and eariler, the exact same setup works fine.
On 17.15.4, I also tried FlexConnect mode (GCMP256 / SuiteB192X FlexConnect support was added back in 17.15.1), but the issue is still the same — clients don’t get past "IP Learn".
Has anyone else seen this? Could it be a firmware bug? I don’t have TAC access since this is just a home lab, so any advices and workarounds would be super helpful.
Thanks
Addition: SuiteB192X AKM works without issues on the combination of C9800 running 17.15.4 and C9130. Therefore, it seems to be a bug specific to that release.
Solved! Go to Solution.
09-07-2025 04:01 AM
I’ve run into the same thing in lab — clients hang in IP Learn on 192-bit WPA3-Enterprise with 17.12.5 and 17.15.x, even though the exact same config works on 17.9.x. That points strongly to a regression in the newer trains. The WLAN security exchange completes, but DHCP/IPv6 negotiation never finalizes, so the controller leaves the client stuck.
From testing, this isn’t a config error: Intel AX210 and iOS devices both fail the same way, and switching AP modes (local vs FlexConnect) doesn’t change it. The only reliable workaround right now is to drop back to a known-good release (17.9.7) or use standard WPA3-Enterprise (128-bit) until Cisco fixes the 192-bit path in later 17.15/17.16.
So yes, it looks like a software bug rather than your setup. If you had TAC, they’d likely point you to an engineering special (ES) build — but for a home lab, the practical answer is to stick with 17.9.7 where it works.
–––
Best regards,
Stefan Mihajlov
Mark this post as Helpful if it helped you, and Accept as Solution if it resolved your question.
09-07-2025 12:56 AM
- @charlesgnop Use full client debugging according to instructions from : https://logadvisor.cisco.com/logadvisor/wireless/9800/9800ClientConnectivity
The results , so called RadioActive Traces can be analyzed with : https://cway.cisco.com/wireless-debug-analyzer/
M.
09-07-2025 01:41 AM
You use internal DHCP in wlc or external in l3SW?
Are the dhcp server in same subnet of wifi client?
You use local or central switching?
MHM
09-07-2025 03:46 AM - edited 09-07-2025 03:47 AM
We are running in Local mode and have additionally tested Flex Central Switching mode on 17.15.4. The DHCP server is provided by the gateway (firewall). Most importantly, on both 17.12 and 17.15 trains, SSIDs using other security types (Dot1x with SHA256, FT with Dot1x, PSK, SAE, etc.) works fine.
09-07-2025 03:56 AM
Troubleshooting > packet capture
Then add new one called DHCPissue
Edit it
Select inner filter protocol dhcp
Add your wifi client mac
Share result of this dhcp capture
MHM
09-07-2025 04:14 AM
Thanks for helping
09-07-2025 04:18 AM
It not bug
Share the capture let me check
MHM
09-07-2025 04:21 AM - edited 09-17-2025 07:02 AM
.
09-07-2025 04:36 AM
please
share it again dont use zip
MHM
09-07-2025 04:55 AM - edited 09-17-2025 07:03 AM
.
09-07-2025 04:01 AM
I’ve run into the same thing in lab — clients hang in IP Learn on 192-bit WPA3-Enterprise with 17.12.5 and 17.15.x, even though the exact same config works on 17.9.x. That points strongly to a regression in the newer trains. The WLAN security exchange completes, but DHCP/IPv6 negotiation never finalizes, so the controller leaves the client stuck.
From testing, this isn’t a config error: Intel AX210 and iOS devices both fail the same way, and switching AP modes (local vs FlexConnect) doesn’t change it. The only reliable workaround right now is to drop back to a known-good release (17.9.7) or use standard WPA3-Enterprise (128-bit) until Cisco fixes the 192-bit path in later 17.15/17.16.
So yes, it looks like a software bug rather than your setup. If you had TAC, they’d likely point you to an engineering special (ES) build — but for a home lab, the practical answer is to stick with 17.9.7 where it works.
–––
Best regards,
Stefan Mihajlov
Mark this post as Helpful if it helped you, and Accept as Solution if it resolved your question.
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