Captive Portal detection causing phones to disconnect from Wi-Fi in intranet environment

Question

Hello Android Enthusiasts!

I am the manager of an Internet Cafe on a cruise ship, and we're being plagued by a persistent problem that I can't quite solve.

We have a wireless network throughout the ship which can be used to access the Internet, but also includes a local intranet through which guests can view the daily events schedule, check their account, and use a free internal messaging service.

The issue we are running into seems to be with Captive Portal detection, and from my observations it appears to be affecting only Samsung phones (might just be S4 and higher), and has been observed on every OS from 4.2.2 and up. What happens is that they connect to the wireless network, and are then told that sign-in is required. A captive portal window will pop up, which does bring up our home page. If they then connect to the Internet, no problem. But if they just want to use the intranet, or if it takes them too long to fill out the user registration form, they get told that the network has been disconnected and we have to start over again from "sign-in is required."

I've done quite a bit of searching online for answers, and one is that the user must select "use network as is" from the captive portal options, but I see this option on very few devices. Other options have involved rooting the phone and running some terminal commands, which is obviously not something I can ask the guests to do.

We posed the issue to our shoreside networking team, and they came back saying they had whitelisted the following URLs and that this should fix the problem:

clients3.google.com/

apple.com/library/test/

captive.apple.com

connectivitycheck.android.com

connectivitycheck.gstatic.com

connectivitycheck.android.com/generate_204

clients3.google.com/generate_204

android.clients.google.com

It did not, phones are still being disconnected after about a minute if no Internet connection is made.

Is there anything else we can try? We are ultimately looking for a fix that won't require our users to do anything special.

Answer 1

We had a similar problem but I think it is not exactly the same problem.

We had an Galaxy S5 mini with Android 5.5.1 installed. We also have a "filter for websites" to deny access to some websites. The problem here was that after starting the phone it connected and then disconnected immediately from network. We found out that the network connectivity check is the problem. First tests show:

• When there is unrestricted Internet access it works.
• When there is no Internet access, network connection stays up. "No Internet connection" means we blocked all traffic on the firewall and all requests result in a timeout error.

When analysing more deeply and looking at the android source code we could identify the HTTP return code as problem. The device starts an HTTP request to connectivitycheck.android.com. This resulted in an HTTP 302 (moved temporarily) from our webfilter. Knowing this we did further tests:

• webfilter redirects access to connectivitycheck.android.com via HTTP/302 and all other internet sites are directly allowed: Here network connection was shut down again.
• deny access to connectivitycheck.android.com using firewall (therefore timeout for connectivity check) and all other internet sites are directly allowed: Here network connection stays up.

Therefore at the end we had two ways to fix the situation:

• allowing access to connectivitycheck.android.com without webfilter (therefore no HTTP 302)
• deny access to connectivitycheck.android.com on the firewall

But what about other Android versions? I did the same tests using a Galaxy S7 with Android 6.0.1. Here we never saw any problem. In Android 6 the connectivity check was slightly changed and is not suffering the above problem.

Answer 2

I've been plagued by this problem as well on one of my open source captive portal libraries.

It seems to be due to the fact that Samsung has decided to implement their own code that will not trigger the captive portal login as it should when a 302 redirect is sent (and wifi does not have internet).

It seems as though you need to serve the captive portal file with 200 when they try to access generate_204 endpoint, instead of just sending 302 redirect -- which works on every other device -- besides Samsung.

Samsung Captive Portal Detection

Thanks Samsung -- why can't you just follow normal captive portal standards!?

With this said though, i have had mixed results on different Samsung Sx devices... some don't even seem to query the /generate_204 when connecting to wifi