625
edits
Difference between revisions of "Mesh/Firmware/Splash page"
Jump to navigation
Jump to search
Mesh/Firmware/Splash page (view source)
Revision as of 01:50, 10 November 2013
, 01:50, 10 November 2013adds alternatives section
Tunabananas (talk | contribs) m |
(adds alternatives section) |
||
| (4 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
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. | 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 [https://sudoroom.org/wiki/Mesh/Network_topology | 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 [https://sudoroom.org/wiki/Mesh/Network_topology 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 [https://github.com/sudomesh/internetisdownredirect 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. | 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 [https://github.com/sudomesh/internetisdownredirect 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. | Currently this page talks mostly about how to implement the fake captive portal. | ||
= Alternative Options = | |||
After some thought and investigation, there some alternative options that build off the proposed actions above and the research in the sections following. Instead of listening for captive portal requests and then responding with a fake captive portal, we do a few different things. First, let's consider the use case: | |||
<blockquote>Ideally, we want new users to know what this network is about.</blockquote> | |||
Running a default captive portal is simply not an option. It impedes usage of the network. However, what if there was an unobtrusive way to display a message to users that did not require using the crappy captive portal mechanism, or a complicated match on special captive portal probes. | |||
= Types of captive portal detection = | = Types of captive portal detection = | ||
| Line 214: | Line 222: | ||
:Will not clients have global IPs for whole mesh? ([[User:Mitar|Mitar]]) | :Will not clients have global IPs for whole mesh? ([[User:Mitar|Mitar]]) | ||
::The clients will get an IP that is on the mesh subnet and will be able to communicate with the entire mesh and internet. They will get different IPs depending on which dhcp server / internet gateway that is "closer" to them when their lease is up. This is how it's done in batman-adv. [[User:Juul|Juul]] ([[User talk:Juul|talk]]) | ::The clients will get an IP that is on the mesh subnet and will be able to communicate with the entire mesh and internet. They will get different IPs depending on which dhcp server / internet gateway that is "closer" to them when their lease is up. This is how it's done in batman-adv. [[User:Juul|Juul]] ([[User talk:Juul|talk]]) | ||
:::This is done in batman-adv if you have different topology. If you have VPN tunnels you might do it differently. The issue is that you might not want to have multiple gateways in the network anyway. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 15:42, 3 September 2013 (PDT) | |||
::::Yes we could run a central DHCP server, but that would make the mesh less resilient to segmentation. We are trying to make something that has as little centralization as possible. I'm interested in why we would not want multiple gateways though? ([[Special:Contributions/46.4.202.3|46.4.202.3]] 20:37, 29 October 2013 (PDT)) | |||
== Proxy == | == Proxy == | ||