Mesh/Firmware/Splash page - Revision history

Matt: adds alternatives section

2013-11-10T08:50:20Z

adds alternatives section

← Older revision		Revision as of 01:50, 10 November 2013
Line 6:		Line 6:

	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 =

46.4.202.3: /* Current in-progress solution for iOS */

2013-10-30T03:37:59Z

Current in-progress solution for iOS

← Older revision		Revision as of 20:37, 29 October 2013
Line 215:		Line 215:
	::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)		:::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 ==

Mitar at 22:42, 3 September 2013

2013-09-03T22:42:33Z

← Older revision		Revision as of 15:42, 3 September 2013
Line 214:		Line 214:
	: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. [[~~Special~~:~~Contributions/24.5.192.44~~\|~~24.5.192.44~~]] 15:41, 3 September 2013 (PDT)		:::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)

	== Proxy ==		== Proxy ==

24.5.192.44: /* Current in-progress solution for iOS */

2013-09-03T22:41:56Z

Current in-progress solution for iOS

← Older revision		Revision as of 15:41, 3 September 2013
Line 214:		Line 214:
	: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. [[Special:Contributions/24.5.192.44\|24.5.192.44]] 15:41, 3 September 2013 (PDT)

	== Proxy ==		== Proxy ==

Tunabananas at 08:29, 29 August 2013

2013-08-29T08:29:29Z

← Older revision		Revision as of 01:29, 29 August 2013
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\|exit nodes] and so will only be active when the mesh is connected to the internet.		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.

Tunabananas at 08:29, 29 August 2013

2013-08-29T08:29:03Z

← Older revision		Revision as of 01:29, 29 August 2013
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 [~~[network topology~~\|exit nodes]] and so will only be active when the mesh is connected to the internet.		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.

Juul: /* iOS */

2013-08-28T11:28:04Z

iOS

← Older revision		Revision as of 04:28, 28 August 2013
Line 58:		Line 58:

	and present the response as the splash page.		and present the response as the splash page.

			It seems that GET requests are also sent to "/library/test/success.html" after the get for "/", and if it succeeds, then the splash page disappears as soon as it has appeared.

			The solutions seems to be to wait for a request for e.g. "http://sudo.mesh/drop_the_splash_page" and remove the redirect for that source IP for some number of hours / days and have a button on the splash page that links to that URL. The "button" could be the entire splash page, but that might be annoying if you're trying to scroll and accidentally click.

	== Windows ==		== Windows ==

Juul: /* Current in-progress solution for iOS */

2013-08-28T11:22:46Z

Current in-progress solution for iOS

← Older revision		Revision as of 04:22, 28 August 2013
Line 85:		Line 85:
	This is to ensure that the IP for www.apple.com is always the same for all the entire network and is always known. This is not a good solution. Instead, the configuration that relies on the IP should be updated every time the IP for www.apple.com changes.		This is to ensure that the IP for www.apple.com is always the same for all the entire network and is always known. This is not a good solution. Instead, the configuration that relies on the IP should be updated every time the IP for www.apple.com changes.

	:Apple is using Akamai and has many addresses. Moreover, it might be that multiple different companies share the same IP?		:Apple is using Akamai and has many addresses. Moreover, it might be that multiple different companies share the same IP? ([[User:Mitar\|Mitar]])
	:What about IPv6?		::Since we have caching DNS servers on the mesh exit nodes, everyone connected to the mesh will see the same IP for www.apple.com. If someone sets a different DNS server, then they will simply not see the splash page if they get a different IP for www.apple.com. We are not blocking the IP or even re-directing all of the traffic for the IP. We are simply re-directing port 80 for the IP through a squid proxy and matching on the host name and URL. The content will be delivered normally unless if the URL and host name is not a captive portal deteciton probe. The only way this could be a problem is if something other than an http server is listening on port 80 on www.apple.com. This is not likely to happen in the near future. ([[User:Juul\|Juul]] ([[User talk:Juul\|talk]]))
			:What about IPv6? ([[User:Mitar\|Mitar]])
			::The IPv6 solution is almost identical. ([[User:Juul\|Juul]] ([[User talk:Juul\|talk]]))

	An iptables rule redirects all port 80 traffic for the www.apple.com IP to a different port:		An iptables rule redirects all port 80 traffic for the www.apple.com IP to a different port:
Line 96:		Line 98:
	The squid proxy is run on port 3128 and set to run a program called rewrite.pl that sends alternate responses to specific GET requests.		The squid proxy is run on port 3128 and set to run a program called rewrite.pl that sends alternate responses to specific GET requests.

	:Why not using internetisdownredirect to redirect?		:Why not using internetisdownredirect to redirect? ([[User:Mitar\|Mitar]])
			::We want to run this on the exit nodes. Not on the mesh nodes. ([[User:Juul\|Juul]] ([[User talk:Juul\|talk]]))

	Squid 3.1 configuration:		Squid 3.1 configuration:
Line 205:		Line 208:
	One concern is: What happens when the client roams to another mesh node and then stays there until their dhcp lease expires? They may get a new IP if batman-adv decides that another gateway is closer/better. If the client gets a new IP, will it try the captive portal detection again?		One concern is: What happens when the client roams to another mesh node and then stays there until their dhcp lease expires? They may get a new IP if batman-adv decides that another gateway is closer/better. If the client gets a new IP, will it try the captive portal detection again?

	:Will not clients have global IPs for whole mesh?		: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]])

	== Proxy ==		== Proxy ==

Mitar: /* Current in-progress solution for iOS */

2013-08-23T06:10:40Z

Current in-progress solution for iOS

← Older revision		Revision as of 23:10, 22 August 2013
Line 95:		Line 95:

	The squid proxy is run on port 3128 and set to run a program called rewrite.pl that sends alternate responses to specific GET requests.		The squid proxy is run on port 3128 and set to run a program called rewrite.pl that sends alternate responses to specific GET requests.

			:Why not using internetisdownredirect to redirect?

	Squid 3.1 configuration:		Squid 3.1 configuration:
Line 202:		Line 204:

	One concern is: What happens when the client roams to another mesh node and then stays there until their dhcp lease expires? They may get a new IP if batman-adv decides that another gateway is closer/better. If the client gets a new IP, will it try the captive portal detection again?		One concern is: What happens when the client roams to another mesh node and then stays there until their dhcp lease expires? They may get a new IP if batman-adv decides that another gateway is closer/better. If the client gets a new IP, will it try the captive portal detection again?

			:Will not clients have global IPs for whole mesh?

	== Proxy ==		== Proxy ==

Mitar: /* Current in-progress solution for iOS */

2013-08-23T06:08:15Z

Current in-progress solution for iOS

← Older revision		Revision as of 23:08, 22 August 2013
Line 84:		Line 84:

	This is to ensure that the IP for www.apple.com is always the same for all the entire network and is always known. This is not a good solution. Instead, the configuration that relies on the IP should be updated every time the IP for www.apple.com changes.		This is to ensure that the IP for www.apple.com is always the same for all the entire network and is always known. This is not a good solution. Instead, the configuration that relies on the IP should be updated every time the IP for www.apple.com changes.

			:Apple is using Akamai and has many addresses. Moreover, it might be that multiple different companies share the same IP?
			:What about IPv6?

	An iptables rule redirects all port 80 traffic for the www.apple.com IP to a different port:		An iptables rule redirects all port 80 traffic for the www.apple.com IP to a different port: