This is the same problem we have with Mac laptops, the 'pseudo' browser will allow the user to run through the whole onboarding process until the final download step where it refuses to allow the user to download a config file.
Our only fixes are to continually educate users to close the 'pseudo' browser and open a full version of safari, or to add pre-auth acls to allow the device to fully access the apple urls it is checking so that the 'pseudo' browser never pops up and the user manually opens a standard browser to get the initial captive portal. Looks like android will need something similar. (although we already have some of google open to allow guests to use google credentials to authenticate, so it probably won't be much extra to add) Wyatt Schill Senior Network Engineer CCNA-Security, CCNP-R&S Green River College 12401 SE 320th St. Auburn, WA 98092 wsch...@greenriver.edu<mailto:wsch...@greenriver.edu> [Green River new official mascot logoEmail] From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Turner, Ryan H Sent: Tuesday, September 5, 2017 1:34 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Defeating Android 8.X Captive Portal detection Even though Android is only 7% of our install base, it amounts to 75% of my problems... It 'appears' on first glance that google has changed the captive portal detection on version 8. It 'appears' (very early into this, so this may change) that google now checks for both a generate_204 on both connectivitycheck.gstatic.com and a gen_204 on www.google.com<http://www.google.com>. Why is this a problem? We, as many people do, have a onboarding SSID. TLS requires proper onboarding. That means that we need to process people through the portal in an orderly manner to get them where they need to go. When Android 8.X detects a captive portal, it will prompt the user to 'sign in'. This process opens a pseudo browser (a browser that is limited in what it can do) to the captive portal login. After the user logs in, the user stays inside of the 'pseudo' browser. The browser has limited powers, and apparently will not allow the user to download or install an agent or configuration files. You can see the problem... They will get to the onboarding page, and nothing will work. I've managed to 'by pass' the problem, but it isn't ideal. Has anyone else seen this with commercial portals and figured out ways around it? It is possible all of this is in error, but I just got done with a bunch of packet captures that seems to validate this. I only have one Oreo user in my vicinity, so I will need to get my hands on a few more to see if this really is an issue, or just bad luck. Ryan Turner Manager of Network Operations ITS Communication Technologies The University of North Carolina at Chapel Hill r...@unc.edu<mailto:r...@unc.edu> +1 919 445 0113 Office +1 919 274 7926 Mobile ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
