01-19-2014 09:19 PM - edited 03-10-2019 09:18 PM
Hi all,
Having an issue with supplicant provisioning via CWA on an anchor controller. I am able to connect via CWA and authenticate etc no problems but when the device registration page appears it says "unable to connect to the network at this time" - the mac address is populated but the button says try again. Once I click try again it cycles back to the original guest portal login page. In the reports section the failed supplicant provisioning message is "Error while trying to determine access privileges: Fail to get hostName from session cache.".
I have tried the same policy without the anchor (ie local controller) and it works perfectly. Interestingly enough if I manually register the device first then connect to the guest portal it allows me to click register and proceed to supplicant provisioning. I have also tried the anchor setup using peap and the NSP redirect - this also works perfectly.
I can confirm ahead of time that firewalls etc are not an issue with permit IP any any between all working parts - no blocks no drops etc. The policy is the standard trustsec CWA setup with Enable self-provisioning ticked. For what it is worth I am absolutely confident with the config having deployed this before - albeit without an anchor controller.
Solved! Go to Solution.
01-28-2014 09:45 AM
Stephen,
I was able to work with TAC the customer account team to find a resolution. The issue is with the Anchor WLC and the session not being replicated. I was able to get around it by disabling radius accounting for the ssid on the anchor controller, but when looking at the bug it looks like an alternative fix is to disable fast ssid switching, which would cause issues with BYOD in the dual ssid world. I'm still doing testing, but the accounting change seems to have solved it. The bug ID is: CSCui38627
01-21-2014 08:06 AM
What version of software is running on the anchor WLC?
01-21-2014 07:41 PM
Both controllers are 5508 running 7.5.102.0
01-22-2014 05:03 PM
Stephen -
I'm seeing this same problem right now with the same scenario. Were you able to get it resolved?
01-22-2014 05:28 PM
The day I posted this issue was the day I discovered it and to date I have no fix. I have temporarly worked around the issue by making an anchored SSID that utilises peap with a NSP authz profile. I definately need this working so when I find a solution I will ensure I post it here.
Incidentally I am having all manner of dramas with the latest patch and onboarding. ANother significant issue I am dealing with is what appears to be the inability to onboard any OSX devices due to the device only been profiled as an Apple device. All other devices are successfully profiling but not OSX.
01-28-2014 09:45 AM
Stephen,
I was able to work with TAC the customer account team to find a resolution. The issue is with the Anchor WLC and the session not being replicated. I was able to get around it by disabling radius accounting for the ssid on the anchor controller, but when looking at the bug it looks like an alternative fix is to disable fast ssid switching, which would cause issues with BYOD in the dual ssid world. I'm still doing testing, but the accounting change seems to have solved it. The bug ID is: CSCui38627
01-28-2014 02:08 PM
Thank you very much for the update. I will give this a try later in the week and mark the thread as answered. Again thank you for the update
01-29-2014 06:45 PM
In my instance the Fast SSID setting has fixed the drama. I ttried the accounting but is did nothing. None the less thanks for your input.
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