Captive Portal When Connected Not Displaying Sign-in is Required
-
Hi Last Week i Have Enabled Captive Portal and Displaying on Android and IOS Devices "Sign-in is Required" but now it is not Displaying now?
-
Anything you'd like to add to this? For instance, relevant details like whether this is happening to all devices or just IOS devices? Whether you're getting a network address at all, or if your DNS is functioning correctly?
Saying something is broken may get you sympathy but it won't get you much help.
-
Anything you'd like to add to this? For instance, relevant details like whether this is happening to all devices or just IOS devices? Whether you're getting a network address at all, or if your DNS is functioning correctly?
Saying something is broken may get you sympathy but it won't get you much help.
Sorry im just a newbie in network concerns, this is my DNS
127.0.0.1
112.198.111.84
112.198.115.84
124.106.7.37
124.106.6.37
209.244.0.3
209.244.0.4
8.8.8.8
8.8.4.4Hope it will help
-
As mentioned, is this happening to just IOS devices or to all devices (PCs, Macs, etc)? On the affected devices, are you able to browse the internet without signing into the CP or not? If not, are you able to resolve external addresses (running 'nslookup' or 'dig' from your client)? Are you clients disconnecting from the network before you find you can't access the CP?
I'm fishing for possible answers here, but again you need to provide more information if you really want someone to help you with this. Like what version of PFS are you using, how you've set up the firewall, what tests/checks you've run already to find an answer for yourself, etc.
-
As mentioned, is this happening to just IOS devices or to all devices (PCs, Macs, etc)? On the affected devices, are you able to browse the internet without signing into the CP or not? If not, are you able to resolve external addresses (running 'nslookup' or 'dig' from your client)? Are you clients disconnecting from the network before you find you can't access the CP?
I'm fishing for possible answers here, but again you need to provide more information if you really want someone to help you with this. Like what version of PFS are you using, how you've set up the firewall, what tests/checks you've run already to find an answer for yourself, etc.
Only Android Users and Laptop User are not displaying the Sign in Option in the Notification Bar.No connection in the internet unless i launch a browser and type google, and it will redirect to the portal log in page,no disconnection issue on the device to see the portal,.im sorry but i do not know what is nslookup or dig is from my client
-
No connection in the internet unless i launch a browser and type google, and it will redirect to the portal log in page
That's because your browser has to open onto an external page in order for the captive portal page to launch. The browser redirects only when an attempt is made to access an external site. This is normal behaviour.
-
Hmm. When I connect to one access point, it automatically opens the browser and to the captive portal, then gets redirected to msn after.
We tried this on a different access point but it didn't happen.
(I tried looking for where this msn redirection might be coming from but it seems it's not a browser config, but I can't see it in the AP manager too)
Is this because of the AP? Is there any way I can configure the portal to launch itself working across different devices? Thanks -
Captive portals don't "launch themselves."
Portals intercept connection attempts to web sites and return the portal page instead.
If there is no http connection attempt by the user device, there can be no portal page displayed.
That's a pretty long list of name servers. Why?
What DNS servers are you giving your clients via DHCP?
Are you using pfSense DNS Forwarder or DNS Resolver or ?? ?
This shouldn't behave differently on different access points if they are all proper access points (meaning they are layer 2 bridges).
If you have a mix of consumer routers trying to be access points you could get all kinds of different behavior depending on what you've done.
-
I hope you didn't get me confused with the OP coz it seemed like it. aha
Anyway, my question's answered, so THANKS. :)
-
.
You are confusing this.
What the OP are talking about, is the captive-portal auto-detect feature that exist on certain devices (Windows 8/8.1/10, Newer androids and newer iOS).
I don't know the exakt internals of this, but some of them rely on DNS (If DNS for www.google.com returns something else than xxx.xxx.xxx.xxx, then its a captive portal), some just fire off a web request to a static web server and see if its replyed with a redirect, then its a captive portal.This auto-detect feature on some devices, launches the browser automatically upon detecting a captive-portal, thus it can give the impression of the "captive portal launching itself".
What the OP and people in this thread are out after, is triggering this auto-detect feature.When captive portal detection is triggered, it might look like this:
-
It's all the same problem.
Some devices try to automatically detect captive portals by making a web request when connecting to a wi-fi network. Apple, for instance, has a slew of URLs out on the internet that return nothing but the text "Success." So if an Apple device gets anything else (like the contents of a portal page) in response to a request for one of those it brings up a mini browser and makes another web request giving your portal a chance to display.
This creates the illusion of the portal being more automatic but it is really not.
Everything I said in the post above still applies. No web request, no portal page.
This is all true whether the web request is being (or not being) made automatically or manually by the end user in a browser.
Completely up to the client to make all this happen. But everything has to be set in the portal to allow all this to happen. DNS is often the culprit. Improper passthroughs (for DNS servers) are often the culprit.
-
Captive portals don't "launch themselves."
Portals intercept connection attempts to web sites and return the portal page instead.
If there is no http connection attempt by the user device, there can be no portal page displayed.
Kinda found the answer for my question here (well, Dere's answer, plus this): http://serverfault.com/questions/695874/default-browser-opens-to-msn-com-when-logging-into-windows-server :) Thanks again
-
…., plus this): http://serverfault.com/questions/695874/default-browser-opens-to-msn-com-when-logging-into-windows-server :)
That page from serverfault.com explains why a certain browser opens a certain page (on the net) when it starts up.
As such, it has nothing to do with "captive portals".All recent "Windows OS" use a "captive portal" detection system as soon as a "NIC" connection is established. The just use some kind of 'curl' call to some (probably Microsoft) site (better : server) - this test doesn't use a full blow browser.
IF a DNS resolution is possible AND the server can not reached, THEN it figured out that it could be behind a captive portal, and a yellow popup will show you (bottom right on screen) that some User attention is needed. clicking on the yellow popup will open de default browser which will (== should) open a web server page 'somewhere on the net', which, in turn, will kick of the magic : the portal page will be show so the user can authenticate which will open up the connection. -
Quoting from the link I posted:
I'm guessing if it can't hit msftncsi.com it pops up a browser window in case you need to log into a hotspot. Thanks so much!
So it HAS something to do with CPs (and it has something to do w/ MY QUESTION) in a sense that it tells us the event isn't portal-side.
so (complementing Dere's answer,) THAT answered my question.
