2

I am looking for a solution to trigger captive portal assistant on Android 4.0-7 and iOS 7-10 when connecting to a LAN with no internet connection.

Our application runs from a webserver on a LAN. We would like our users (who will typically be first-time users) to be able to access the application in as few steps as possible. The system currently works by connecting to a WiFi network, opening a browser and entering a URL. We would like to reduce this to one step (connecting to WiFi network) with the browser automatically opened by the captive portal assistant built into Android and iOS.

I am not looking for a standard captive portal set-up.

This system must trigger the captive portal assistants within Android and iOS without a request being sent to the genuine servers run by Google or Apple. No internet connection, not now, not ever.

The system is Debian based, with HOSTAPD and DNSMASQ running DHCP and DNS resolution. The webserver is NGINX with PHP7.0.

If a solution can be achieved using other packages available for Debian e.g. BIND or anything that could substitute what we are using now. I have n problem with changing the config.

I have never registered with superuser before, only lurked in the shadows and quietly learnt a lot from the fantastic members. Because of this I have no reputation to offer as bounty. If there is another way to repay someone who comes up with a working solution please let me know.

1
  • 1
    Just a comment from one year after your question. You asked "If there is another way to repay someone who comes up with a working solution please let me know.". In fact, upvoting and accepting an answer provides some rep points for the answerer, so you just have to accept the answer which has the solution. This is also useful for people like me, who search for a solution to a problem like yours and, if there is an accepted answer, knows that the solution works ;)
    – frarugi87
    Commented Oct 12, 2017 at 11:11

2 Answers 2

1

Captive portal detection generally works by attempting to access a page over HTTP and checking that the page returned is as expected.

Android for example will connect to http://clients1.google.com/generate_204, which simply returns an HTTP status of 204. Presumably, iOS clients work in a similar way.

In order to open your application in the way you describe, you would simply need to redirect all HTTP requests that aren't already destined to your application server. This way clients will never receive the expected result.

This could be achieved by using NAT with iptables if the clients have the Debian system set as their gateway. This could be done with a rule similar to the following, where APPSERVER is the IP address of your app server:

iptables -t nat -D PREROUTING ! -d APPSERVER -p tcp –-dport 80 -j DNAT –to-destination APPSERVER

I am not sure however how suitable using the captive portal assistant may be as they are often very limited and the user may have difficulty returning to the application if they accidentally close the captive portal assistant. Some older devices may also not be able to automatically detect the presence of a captive portal. Since the user will never be able to access the Internet over your network, the captive portal assistant may continue to show your application periodically or mark the network as having no Internet access and prevent future connections.

-1

The best thing I could find was an answer on serverfault (which infact is a better site for this question anyway).: here

Basically, you run a prebuilt application/container which does all the work for you.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .