Captive portal to android phone
-
unlike the ipad and windoze machine, i see that android phones act a little differently when attaching to the captive portal. when i attached my phone to the captive portal, the portal login request came in as a notification instead of a web page coming up asking me to log in like it does on the other devices. once i did the login i never saw the success page come up as either a web page or notification like it does on the other devices, the login page just stayed on the screen. i was able to switch screens and get on the net so i know the login was successful. is this normal behavior?
the reason that i ask is that i have to document all of the different things that the user might see when working through the captive portal and the appropriate action to take when things go wrong.
-
the reason that i ask is that i have to document all of the different things that the user might see when working through the captive portal and the appropriate action to take when things go wrong.
Good luck. It's all completely dependent on the client device and has nothing to do with pfSense captive portal itself.
Captive portal blocks all internet access but intercepts requests to port 80 and forwards them to another location. What the client device does in that situation is up to the client.
-
….
the reason that i ask is that i have to document all of the different things that the user might see when working through the captive portal and the appropriate action to take when things go wrong.That's what I thought, way back, when I started to use a captive portal for ou (hotel) clients.
But, as Derelit stated, is was a mission impossible.Actually, it up to the user to understand and know how to connect to a wifi network.
Then, a basic web browser (not a mail client, not FB app, no Twitter, etc) should be launched.
Up from that point, everything will work as (not) advertised ;)But … OS's became "captive portal minded", as you can see with Microsoft Windows Desktop OS's like Window 7, 8,1 etc. The iDevices have also some basic captive portal detection (but still not perfect).
Read http://en.wikipedia.org/wiki/Captive_portal and if you have some time, read this https://forum.pfsense.org/index.php?topic=77143.0;nowap , a story about how to make a logout/disconnect page for pfSense, Cookies and other NSA issues.Things become even nicer when you use a (signed and valid !) certificate to authenticate over SSL using the captive portal of pfSEnse. Browser start to spit out "scary" messages because the user, after activating and accepting the Wifi connection, will surf to https://www.facebook.com (or, more frequent: https://www.google.com) or, our https captive portal page shows up, identifying itself with ANOTHER certificate then expected, using another URL. Browser starts to warn the user that something is happening (a regular man-in-de-middle situation) which is quiet understandable in this very unique situation.
The question is: our user really understands all this ?? Are you really ready to explain all this ? For all devices ? Good luck.
It would be a nice thing if someone puts up a RFC about captive portals …...
-
i looked at the forum link you referred to and a lot of the links in it have either expired or are no longer accessible. i'm going to dig into it some more. the project i'm working on is for a hotel and i want to set something up similar to other hotels that i have been to. their captive portal either uses a 4-5 digit code or a short easily typed expression that they change on a weekly basis.
based on my previous experiences, having to use a user id and password is too much user interaction and the codes generated by the voucher are too long and convoluted especially on a mobile platform. i'm not an html or xml wizard. i can read and understand it, but building my own code from scratch is more than i want to get into at this time.
thanks for the insight about the mobile platform.
-
4-5 digit code is pretty much useless and, plus not doable with CP. Set up WPA-2 there with some "easily typed" PSK and move on. You can change it as often as you want.
-
The bottom line is they need to open a browser and bring up a non-secure site. We have the call center tell them 10.0.0.1. Been thinking of ways to make that a little cleaner. I know what to do but don't want to change it right now.
CP breaks the internet by design. Broken internet makes the phone ring.
Changing the PSK on a WPA2 network instantly breaks all existing connections - all of whom have to now call the front desk for the new passphrase - at the same time. I routinely have thousands of active CP sessions. Not going to happen.
-
i looked at the forum link you referred to and a lot of the links in it have either expired or are no longer accessible.
Links (to pastebin.com) on last pages in that thread are still valid. Older links are older versions.
I'm still using that code to propose a log-out page, but very few are actually using it.
We give Internet access for free, so, who cares ;)i'm going to dig into it some more. the project i'm working on is for a hotel and i want to set something up similar to other hotels that i have been to. their captive portal either uses a 4-5 digit code or a short easily typed expression that they change on a weekly basis.
I'm using easy login codes (login user names) => the hotel room number like 101, 215 etc.
Passwords are the same for all users.
I can 'preset' the passwords for all users (portal users group) with some 'home made PHP lines'.Not a very secured environment but I can work with it this way because I never detected that client in room number "203" used login "214" (the all have the same password) to get an access.
A more strict login system (password generator) is easy to implement. -
s this normal behavior?
the reason that i ask is that i have to document all of the different things that the user might see when working through the captive portal and the appropriate action to take when things go wrong.
on newer android devices (lollipop) when you connect to our captive portal (and attempt to pass any traffic) (any ap) it notifies like you said "please login into wifi network" click notification, browser opens login page, accept TOS and user is http redirected to landing page. Able to browse from there etc. On older android (kitkat and back) once user connects to AP user has to open browser then is redirected to accept TOS.
I'm assuming this isn't as simple on apple devices because i see (apple device) users connect to the AP and then never attempt to access TOS page. lames! -
iOS works fine. They check a known URL and if they don't get "Success" back they bring up a mini browser that shows the portal page.
-
android is a pile of ****. We've had to completely re-engineer our onboarding process because of Android. The captive portal detection is actually a bad thing for us, and we do everything to make the phone think they have normal connectivity which forces them to manually open a browser. The big issue is that a lot of the captive portal browsers (the browsers that pop open when the device detects they are behind a portal) are limited in ability. With the most recent android update (5.0.2) the device detected a captive portal, and either shut down completely AFTER authenticating (leaving the user with no clue what URL they needed to go to in order to onboard their device OR if the browser stayed up, they were unable to download and install the application to configure their device for EAP-TLS. I had to poke a hole through for 'connectivitycheck.android.com' and force resolution to a single IP to keep my sanity (through DNS forwarder).
This fall we are authenticating (with username and password) the onboarding portal, and completely opening up the back-end (post authentication) so android users can download the onboarding application directly from the android market place. Creating an ACL that allows that is nearly impossible.
Google has forced me to waive the white flag. I hate them for it. They are becoming more arrogant and stupid than Apple, especially when it comes to the enterprise.
-
Old topic, similar problem. After some of my guests complained about lack of internet access through the Portal, I found that they were trying through the Google app, which requires logging in to their Google account before anything else happens.
Either they didnt have a separate browser installed, or if they did, they didnt know how to use it.
If they had Chrome, that worked OK.On this subject, I get a lot less problems reported using the username only for logging on. That is enough to keep out the casual leachers, which is all I care about.
