Difference between revisions of "Mesh/Firmware/Splash page"

From Sudo Room
Jump to navigation Jump to search
Line 23: Line 23:
The code that uses the HTTP 204 method is [https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/net/CaptivePortalTracker.java here]. This is the master branch, which I assume is latest stable or latest development, so I'm not sure what this "faster captive portal detection" in 4.2.2 is supposed to mean.
The code that uses the HTTP 204 method is [https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/net/CaptivePortalTracker.java here]. This is the master branch, which I assume is latest stable or latest development, so I'm not sure what this "faster captive portal detection" in 4.2.2 is supposed to mean.


== Mac OS and iOS ==
== Mac OS ==  


We don't know the complete set of checks. We know that it does an HTTP GET of http://www.apple.com/library/test/success.html and checks if the result is/contains "Success". The result from firefox is:
No idea. Maybe the same as iOS?
 
== iOS ==
 
Here is the sequence of events, as verified by [[User:Juul|Juul]] ([[User talk:Juul|talk]]) using an iPhone running iOS 5.0.1:
 
First a DNS lookup is issued for www.apple.com. Next the following HTTP GET is issued:
 
<pre>
GET /library/test/success.html HTTP/1.0
Host: www.apple.com
User-Agent: CaptiveNetworkSupport-183 wispr
Connection: close
</pre>
 
The result that it expects is an HTTP 200 with this content:
 
<pre>
<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>
</pre>
 
If it gets anything else, then it will do the following HTTP GET:


<pre>
<pre>
<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>
GET / HTTP/1.1
Host: www.apple.com
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9A405
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us
Accept-Encoding: gzip, d
</pre>
</pre>


This may not be the whole story though, though [http://www.davidcalculli.com/blog/2012/10/apples-secret-connecting-to-a-wi-fi-network-requires-an-active-internet-connection this] seems to indicate that it is.
and present the response as the splash page.


== Windows ==
== Windows ==

Revision as of 13:02, 13 August 2013

Some operating systems will attempt to detect whether you are behind a captive portal when you connect to a new network. This usually involves fetching a web page with known content from a web server controlled by the company behind the operating system. If a captive portal is detected, the operating system will pop up a dialog showing the web page from the captive portal.

We will run a fake captive portal that causes our splash page to be displayed on any operating system supporting captive portal detection. The fake captive portal will _only_ interfere with captive portal detection traffic. All other traffic will go through unaltered. The fake captive portal will run on the exit nodes and so will only be active when the mesh is connected to the internet.

If the mesh becomes disconnected from the internet, then all HTTP GET requests to the internet will receive 302 HTTP redirects to a community portal web app running on a server on the mesh that will inform the user that the internet is down. The redirection is accomplished with internetisdownredirect. If the node is not connected to any server running the community portal web app, then all HTTP GET requests will receive 302 HTTP redirects to a local web page telling the user that your mesh node has become disconnected from the rest of the mesh, and who to contact about it.

Currently this page talks mostly about how to implement the fake captive portal.

Types of captive portal detection

Android

Expects HTTP 204 response from http://clients3.google.com/generate_204

or

expects zero-length response body from http://www.google.com/blank.html

or something else.

Captive portal detection method appears to have changed in 4.2.2.

The code that uses the HTTP 204 method is here. This is the master branch, which I assume is latest stable or latest development, so I'm not sure what this "faster captive portal detection" in 4.2.2 is supposed to mean.

Mac OS

No idea. Maybe the same as iOS?

iOS

Here is the sequence of events, as verified by Juul (talk) using an iPhone running iOS 5.0.1:

First a DNS lookup is issued for www.apple.com. Next the following HTTP GET is issued: 

GET /library/test/success.html HTTP/1.0
Host: www.apple.com
User-Agent: CaptiveNetworkSupport-183 wispr
Connection: close

The result that it expects is an HTTP 200 with this content: 

<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>

If it gets anything else, then it will do the following HTTP GET: 

GET / HTTP/1.1
Host: www.apple.com
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9A405
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us
Accept-Encoding: gzip, d

and present the response as the splash page.

Windows

The captive portal detection is called NCSI (Network Connectivity Status Indicator). It works like so:

  • A DNS lookup of www.msftncsi.com followed by a GET request to the resulting IP with URL http://www.msftncsi.com/ncsi.txt. This file is expected to contain only the text "Microsoft NCSI" (no quotes).
  • A DNS lookup of dns.msftncsi.com. If the DNS lookup does not result in the IP 131.107.255.255, the internet connection is assumed to be non-functioning.

So: To get a splash page displayed, the initial request to http://www.msftncsi.com/ncsi.txt should not return the expected text (unknown if blocking the connection outright is good enough), but the DNS

More info here.

Solutions

The filtering should happen at the exit nodes (the servers from which traffic flows between the mesh and the internet). This means that we are not limited by the processing power of the routers.

Proxy

A proxy such as Polipo or Squid could be used.

iptables layer 7

Layer 7 filtering allows the use of regular expression matching of the beginning of the packet data.

ip-based optimization

One of the problems with a proxy and with layer 7 filtering is that it's slow. It would be nice if we could filter only the traffic going to the servers used for captive portal detection (using proxy or layer 7). Unfortunately these servers have not one, but a range of IP addresses (at least for www.apple.com), but a DNS request from an exit node and any user on the mesh going through that same exit node should get the same response. Thus, we should be able to have a script that:

  1. Periodically looks up the IP for the different servers
  2. Adds the result as an entry in /etc/hosts
  3. Updates iptables rules to direct traffic to those IP addresses through the proxy or layer 7 rules.

It may be that we could run an actual caching DNS server, but that DNS server would need a hook to be called every time certain entries change.

Retrieved from "https://sudoroom.org/mediawiki/index.php?title=Mesh/Firmware/Splash_page&oldid=5378"