Hey Robin! Glad you figured out what was your issue :)
> I found out that the problem here was that the Apple devices were > opening a separate browser session as part of the 'joining a wlan' > dialogue box, if they detected that there was a captive portal in the > way. When the user exited the browser to retrieve the registration text > message code, the phone assumed that the user had given up connecting > and completely closed the browser and worse, disconnected from the wlan, > thus causing the user to start registration over again from the > beginning. Not ideal. Yep… this is the Apple way of doing WISPr. A lot of vendors suggest to bypass it exactly the way you’ve done by allowing the “test URLs” in the passthrough. > Would be interested if anyone else has had any experience of this issue > and whether it's something that is integrated by default into PF in > version 4? Apparently there is a specific user agent used by Apple > devices when detecting connectivity 'user-agent: > CaptiveNetworkSupport/1.0 wispr', which in theory could just be allowed > through, but I couldn't think of a way of PF supporting that without > changing PF code (and I guess it's a bit of a security issue as it'd > allow people to spoof a user agent to bypass the captive portal > registration). We are already working on something like that. Since IOS7, Apple now use something like 200+ test URLs so it is becoming difficult to maintain an accurate list of passthrough. Going with the user-agent is probably the best way in this case. Also, there is no “bypass captive portal” in this scenario… The only thing that the “bypass” will do is to tell the device “yeah go ahead you are on the Internet and don’t prompt the user with the WISPr popup” by returning a 200 rather than a 302. The user will sill have to register the device on the portal when he will open a web browser. > If the passthroughs supported a regex expression, you could also do all > of the URLs in one go as they all look for "/library/test/success.html " > regardless of the URL, but I don't think PF supports this either? Unfortunately, I don’t think that’s the case. They are not all looking for that specific path I think. That was the case before IOS7. To stay up-to-date with the WISPr detection user-agent based stuff, I may suggest you to open a “bug” entry in our BTS (http://packetfence.org/bugs) for a feature request and we’ll be able to track the changes from there. Cheers! dw. -- Derek Wuelfrath [email protected] :: www.inverse.ca +1.514.447.4918 (x110) :: +1.866.353.6153 (x110) Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) On May 10, 2014, at 4:42 PM, Robin Williams <[email protected]> wrote: > Just an update on this one; > > I found out that the problem here was that the Apple devices were > opening a separate browser session as part of the 'joining a wlan' > dialogue box, if they detected that there was a captive portal in the > way. When the user exited the browser to retrieve the registration text > message code, the phone assumed that the user had given up connecting > and completely closed the browser and worse, disconnected from the wlan, > thus causing the user to start registration over again from the > beginning. Not ideal. > > As a work around I've added passthroughs for what seems like the most > common apple URLs which it uses to detect an Internet connection (there > may be more). This avoids the browser opening automatically when > joining a wlan and just allows the wlan to connect normally, and instead > allows the user to open safari themselves and go through the process > properly. > > [passthroughs] > ..... > 30=http://www.apple.com > 31=http://captive.apple.com > 32=http://www.appleiphonecell.com > 33=http://www.airport.us > 34=http://www.ibook.info > 35=http://www.itools.info > 36=http://www.thinkdifferent.us > ... > > > Would be interested if anyone else has had any experience of this issue > and whether it's something that is integrated by default into PF in > version 4? Apparently there is a specific user agent used by Apple > devices when detecting connectivity 'user-agent: > CaptiveNetworkSupport/1.0 wispr', which in theory could just be allowed > through, but I couldn't think of a way of PF supporting that without > changing PF code (and I guess it's a bit of a security issue as it'd > allow people to spoof a user agent to bypass the captive portal > registration). > > If the passthroughs supported a regex expression, you could also do all > of the URLs in one go as they all look for "/library/test/success.html " > regardless of the URL, but I don't think PF supports this either? > > Thanks, > Robin. > > > > > On 17/04/14 13:52, Robin Williams wrote: >> Hi all, >> >> We have some users using captive-portal via SMS authentication. >> >> I don't know if it's a recent apple update, but it seems in the user >> switching to their text message app to get their registration code (if >> they don't just get it from the notifications bar) and then switching >> back to the browser, the browser session is restarted as if the >> browser has been closed and re-opened. The net effect being that the >> registration process starts over before they get to put their >> registration code in. Is there any way around this by remembering the >> user MAC rather than using cookies, as presumably it does at the moment? >> >> Does a newer version address this, as we're still back on a 4.x revision? >> >> Thanks for any suggestions, maybe I'm missing an option? >> >> Robin >> > > > -- > > ------------------------------ > The Networking People (NorthWest) Limited. Registered office: c/o Hanleys, > Spring Court, Hale, Cheshire, WA14 2UQ. Registered in England & Wales with > company number: 07667393 > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipient > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited. > > ------------------------------------------------------------------------------ > Is your legacy SCM system holding you back? Join Perforce May 7 to find out: > • 3 signs your SCM is hindering your productivity > • Requirements for releasing software faster > • Expert tips and advice for migrating your SCM now > http://p.sf.net/sfu/perforce > _______________________________________________ > PacketFence-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/packetfence-users ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
