WLC captive portal android 10+ devices no pop-ups

[117222400]

9800 WLC 17.3.3 + C9120AXI  APs

set guest wifi L3 web authentication, consent, captive portal

For iPhone all good working, but for Android devices (mostly Android10+) can't pop-up captive portal.

It occurs sometimes, for example: on Monday( 2 days off office).

It can connect to SSID and get DHCP IP address, but there is no pop-ups come out and can't consent.

Sometimes the pop-up can come out, and the captive portal consent is working.(can't find out the exact condition which can let the pop-up out)

2023/03/07 12:46:20.759345 {wncd_x_R0-0}{1}: [client-orch-sm] [21386]: (note): MAC: 04d6.aad5.aef8 Association received. BSSID ac4a.569a.552f, WLAN Guest, Slot 1 AP ac4a.569a.5520, SYDx-SP-LxAPxx
2023/03/07 12:46:20.759448 {wncd_x_R0-0}{1}: [client-orch-state] [21386]: (note): MAC: 04d6.aad5.aef8 Client state transition: S_CO_INIT -> S_CO_ASSOCIATING
2023/03/07 12:46:20.759726 {wncd_x_R0-0}{1}: [dot11] [21386]: (note): MAC: 04d6.aad5.aef8 Association success. AID 1, Roaming = False, WGB = False, 11r = False, 11w = False
2023/03/07 12:46:20.759798 {wncd_x_R0-0}{1}: [client-orch-state] [21386]: (note): MAC: 04d6.aad5.aef8 Client state transition: S_CO_ASSOCIATING -> S_CO_L2_AUTH_IN_PROGRESS
2023/03/07 12:46:20.759814 {wncd_x_R0-0}{1}: [client-auth] [21386]: (note): MAC: 04d6.aad5.aef8 L2 Authentication initiated. method PSK, Policy VLAN 0,AAA override = 1, NAC = 0
2023/03/07 12:46:20.759828 {wncd_x_R0-0}{1}: [sanet-shim-translate] [21386]: (ERR): 04d6.aad5.aef8 wlan_profile Not Found : Device information attributes not populated
2023/03/07 12:46:20.760319 {wncd_x_R0-0}{1}: [ewlc-infra-evq] [21386]: (note): Authentication Success. Resolved Policy bitmap:11 for client 04d6.aad5.aef8
2023/03/07 12:46:20.760390 {wncd_x_R0-0}{1}: [client-auth] [21386]: (note): MAC: 04d6.aad5.aef8 ADD MOBILE sent. Client state flags: 0x31 BSSID: MAC: ac4a.569a.552f capwap IFID: 0x90000157
2023/03/07 12:46:20.898716 {wncd_x_R0-0}{1}: [client-keymgmt] [21386]: (note): MAC: 04d6.aad5.aef8 EAP Key management successful. AKM:PSK Cipher:CCMP WPA Version: WPA2
2023/03/07 12:46:20.898760 {wncd_x_R0-0}{1}: [client-auth] [21386]: (note): MAC: 04d6.aad5.aef8 L2 Authentication initiated. method WEBAUTH, Policy VLAN 0,AAA override = 1
2023/03/07 12:46:20.898773 {wncd_x_R0-0}{1}: [sanet-shim-translate] [21386]: (ERR): 04d6.aad5.aef8 wlan_profile Not Found : Device information attributes not populated
2023/03/07 12:46:20.900218 {wncd_x_R0-0}{1}: [client-orch-sm] [21386]: (note): MAC: 04d6.aad5.aef8 Mobility discovery triggered. Client mode: Flex - Central Switching
2023/03/07 12:46:20.900220 {wncd_x_R0-0}{1}: [client-orch-state] [21386]: (note): MAC: 04d6.aad5.aef8 Client state transition: S_CO_L2_AUTH_IN_PROGRESS -> S_CO_MOBILITY_DISCOVERY_IN_PROGRESS
2023/03/07 12:46:23.901057 {wncd_x_R0-0}{1}: [mm-client] [21386]: (note): MAC: 04d6.aad5.aef8 Mobility Successful. Roam Type None, Sub Roam Type MM_SUB_ROAM_TYPE_NONE, Client IFID: 0xa0000090, Client Role: Local PoA: 0x90000157 PoP: 0x0
2023/03/07 12:46:23.901179 {wncd_x_R0-0}{1}: [client-auth] [21386]: (note): MAC: 04d6.aad5.aef8 ADD MOBILE sent. Client state flags: 0x32 BSSID: MAC: ac4a.569a.552f capwap IFID: 0x90000157
2023/03/07 12:46:23.901210 {wncd_x_R0-0}{1}: [client-orch-state] [21386]: (note): MAC: 04d6.aad5.aef8 Client state transition: S_CO_MOBILITY_DISCOVERY_IN_PROGRESS -> S_CO_DPATH_PLUMB_IN_PROGRESS
2023/03/07 12:46:23.901275 {wncd_x_R0-0}{1}: [dot11] [21386]: (note): MAC: 04d6.aad5.aef8 Client datapath entry params - ssid:WIFI88_GUEST,slot_id:1 bssid ifid: 0x90000154, radio_ifid: 0x9000014f, wlan_ifid: 0xf0400014
2023/03/07 12:46:23.901464 {wncd_x_R0-0}{1}: [dpath_svc] [21386]: (note): MAC: 04d6.aad5.aef8 Client datapath entry created for ifid 0xa0000090
2023/03/07 12:46:23.901607 {wncd_x_R0-0}{1}: [client-orch-state] [21386]: (note): MAC: 04d6.aad5.aef8 Client state transition: S_CO_DPATH_PLUMB_IN_PROGRESS -> S_CO_IP_LEARN_IN_PROGRESS
2023/03/07 12:46:24.551752 {wncd_x_R0-0}{1}: [client-iplearn] [21386]: (note): MAC: 04d6.aad5.aef8 Client IP learn successful. Method: DHCP IP: 10.217.81.100
2023/03/07 12:46:24.552044 {wncd_x_R0-0}{1}: [client-orch-state] [21386]: (note): MAC: 04d6.aad5.aef8 Client state transition: S_CO_IP_LEARN_IN_PROGRESS -> S_CO_L3_AUTH_IN_PROGRESS
2023/03/07 12:46:24.552075 {wncd_x_R0-0}{1}: [client-auth] [21386]: (note): MAC: 04d6.aad5.aef8 L3 Authentication initiated. LWA
2023/03/07 12:48:20.898531 {wncd_x_R0-0}{1}: [ewlc-infra-evq] [21386]: (ERR): SANET_AUTHC_FAILURE - No Response from Client username , audit session id 7E30D90A00010EDAB9F66D30,
2023/03/07 12:48:20.898554 {wncd_x_R0-0}{1}: [errmsg] [21386]: (note): %SESSION_MGR-5-FAIL: Authorization failed or unapplied for client (04d6.aad5.aef8) on Interface capwap_90000157 AuditSessionID 7E30D90A00010EDAB9F66D30. Failure reason: Authc fail. Authc failure reason: No Response from Client.
2023/03/07 12:48:20.899547 {wncd_x_R0-0}{1}: [ewlc-infra-evq] [21386]: (note): Authentication Success. Resolved Policy bitmap:0 for client 04d6.aad5.aef8
2023/03/07 12:48:20.899566 {wncd_x_R0-0}{1}: [client-auth] [21386]: (ERR): MAC: 04d6.aad5.aef8 L3 Authentication FAIL.
2023/03/07 12:48:20.900041 {wncd_x_R0-0}{1}: [client-orch-sm] [21386]: (note): MAC: 04d6.aad5.aef8 Client delete initiated. Reason: CO_CLIENT_DELETE_REASON_L3AUTH_FAIL, fsm-state transition 00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|01|07|13|17|18|28|33|42|44|46|48|4d|5c|5d|65|10|
2023/03/07 12:48:20.900118 {wncd_x_R0-0}{1}: [client-orch-sm] [21386]: (note): MAC: 04d6.aad5.aef8 Delete mobile payload sent forbssid: ac4a.569a.552f WTP mac: ac4a.569a.5520 slot id: 1
2023/03/07 12:48:20.900125 {wncd_x_R0-0}{1}: [client-orch-state] [21386]: (note): MAC: 04d6.aad5.aef8 Client state transition: S_CO_L3_AUTH_IN_PROGRESS -> S_CO_DELETE_IN_PROGRESS
2023/03/07 12:48:20.900571 {wncd_x_R0-0}{1}: [dpath_svc] [21386]: (note): MAC: 04d6.aad5.aef8 Client datapath entry deleted for ifid 0xa0000090
2023/03/07 12:48:20.900835 {wncd_x_R0-0}{1}: [sanet-shim-translate] [21386]: (note): MAC: 04d6.aad5.aef8 Session manager disconnect event called, session label: 0x2c000f13
2023/03/07 12:48:20.901267 {wncd_x_R0-0}{1}: [client-orch-state] [21386]: (note): MAC: 04d6.aad5.aef8 Client state transition: S_CO_DELETE_IN_PROGRESS -> S_CO_DELETED
2023/03/07 12:48:31.427812 {wncd_x_R0-0}{1}: [client-iplearn] [21386]: (ERR): MAC: 04d6.aad5.aef8 Iplearn receive client ip down. Client not waiting for IP. no FSM context
2023/03/07 12:48:31.428193 {wncd_x_R0-0}{1}: [client-iplearn] [21386]: (ERR): MAC: 04d6.aad5.aef8 Iplearn receive client ip down. Client not waiting for IP. no FSM context

The above is troubleshooting logs and could the experts have a look? much appreciated

It stuck at : Policy Manager State :  Webauth Pending

Thanks very much

Best regards

Fang

[117222400]

The below article said "captive portal is unreliable " , but the end user doesn't accept...

https://developer.android.com/about/versions/11/features/captive-portal#detection

[Rich R]

1. Update IOS-XE as per TAC recommended below
2. Check your WLC config with https://cway.cisco.com/wireless-config-analyzer/ using the output of "show tech wireless"
3. Turn off "Web Auth intercept HTTPs" - we found that the 9800 has extremely low/poor capacity for handling https redirects (9800-80 running 17.6.4 much worse than 8540 running AireOS 8.10) resulting in the WLC dropping client redirects for http probes causing missed captive portal popups, especially as client numbers increase.  TAC told us there is no option to tune or improve this performance and the only option is to turn off the https redirects.  Doing that resolved most of the problems for us.  If any remain after that then investigate on a case by case basis.  Basically they made it perform significantly worse than AireOS on 8540 so they recommend not using https redirects at all.  These drops are very difficult to detect anywhere on the WLC (and no alarms that it's over capacity and dropping packets) but on client packet captures you'll see the client getting no reply to the http probes.

[117222400]

Hi,Rich

Thank you very much for your detailed reply, and our company is very strict, it would be risky to update firmware or do some change to fit the best practice(as it may cause new issue), and also the management don't want to use http regarding its unsafely. Unless there is a direct solution to solve it.

It's a pity that I can't even try. I have to persuade the user to use other authentication SSID.

By the way, as far as I know, Cisco TAC team is not so good at technology and maybe community experts are better than them.

Thanks again.

[Rich R]

Failing to upgrade to current software is UNSAFE!  Numerous security vulnerabilities get fixed in IOS-XE updates for example - along with numerous other bugs.  Yes there can be regressions - that's why you TEST!  Anyway do whatever you want but you should be educating misinformed managers not blindly accepting their archaic theories!

"management don't want to use http regarding its unsafely" - oh dear me!!!!!
http is the ONLY way to do captive portal redirection safely.  Most modern browsers give security warnings if you try to redirect https, many block it COMPLETELY, likewise if the site being redirected uses HSTS.  ALL modern devices and browser captive portal assistants use http (not https) probes to discover captive portals.  You and your managers need to read up on how captive portal assistants work.  Some examples:
https://captivebehavior.wballiance.com/
Apple mostly uses http://captive.apple.com/hotspot-detect.html
Each OS and browser and even different versions use different URLs but they are ALL http://
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc766017(v=ws.10)?redirectedfrom=MSDN
https://www.techrepublic.com/article/what-do-microsoft-and-ncsi-have-in-common/
So Microsoft often uses http://www.msftncsi.com/ncsi.txt

So the redirect for that http request should always be https (=secure) but that is not what you are disabling.  You are disabling the redirect of client https traffic like web browsing and apps trying to connect to their servers securely.  That causes security errors due to mismatched certs and HSTS so is mostly pointless anyway because it will always fail for apps and captive portals and mostly for browsers too (some may still allow the user to proceed after severe security warnings).  So doing that also promotes insecure/bad user behaviour because you're forcing them to ignore security warnings.

Regarding TAC - the quality of 1st line TAC engineers varies considerably and some regions are worse than others.  It's not unusual to get a TAC engineer who knows less about the technology than you.  If that becomes apparent you need to escalate or demand re-queue to somebody capable.  I recently had one delay and literally do nothing for 1 month but make excuses.  The day I demanded a re-queue (after multiple previous promises of action) he suddenly started doing what he claimed he had done 3 weeks earlier.  I had one of his managers phone me and beg me, repeatedly, not to re-queue the case! (I suspect the outsourced teams are penalised if their cases get re-queued back to Cisco staff)  Within a week of re-queuing to a qualified Cisco engineer the case was resolved.  On the other hand some of those engineers are great and I've had some cases handled really well and promptly by the 1st line people.