892
edits
Difference between revisions of "Mesh/Firmware/Splash page"
Mesh/Firmware/Splash page (view source)
Revision as of 13:37, 13 August 2013
, 13:37, 13 August 2013→Current in-progress solution
| Line 75: | Line 75: | ||
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. | 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. | ||
== Current in-progress solution == | == Current in-progress solution for iOS == | ||
The exit nodes run a dnsmasq caching dns server. They have an entry for www.apple.com in their /etc/hosts file: | The exit nodes run a dnsmasq caching dns server. They have an entry for www.apple.com in their /etc/hosts file: | ||
| Line 198: | Line 198: | ||
The last missing steps are to improve rewrite.pl to add firewall rules that bypass the squid proxy for the source IP after the user clicks past the splash screen. These should be flushed out after some period of time. Also, the matching for http://www.apple.com/ should only be activated for an IP for some minutes immediately after the request to http://www.apple.com/library/test/success.html such that requests to http://www.apple.com from non-captive-portal detecting devices will not be redirected. | The last missing steps are to improve rewrite.pl to add firewall rules that bypass the squid proxy for the source IP after the user clicks past the splash screen. These should be flushed out after some period of time. Also, the matching for http://www.apple.com/ should only be activated for an IP for some minutes immediately after the request to http://www.apple.com/library/test/success.html such that requests to http://www.apple.com from non-captive-portal detecting devices will not be redirected. | ||
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? | ||
== Proxy == | == Proxy == | ||