cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
695
Views
3
Helpful
10
Replies

Clients stuck in "IP Learn" state on WPA3-Enterprise 192-bit SSID

charlesgnop
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

Stefan Mihajlov
Level 3
Level 3

@charlesgnop 

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.

View solution in original post

10 Replies 10

Mark Elsen
Hall of Fame
Hall of Fame

 

 - @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.



-- Let everything happen to you  
       Beauty and terror
      Just keep going    
       No feeling is final
Reiner Maria Rilke (1899)

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

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.

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

Thanks for helping

It not bug 

Share the capture let me check

MHM

.

please
share it again dont use zip

MHM

.

Stefan Mihajlov
Level 3
Level 3

@charlesgnop 

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.

Review Cisco Networking for a $25 gift card