search

sudomesh / sudowrt-firmware

Scripts to build the sudo mesh OpenWRT firmware.
Other
73 stars 19 forks source link

Create splash page to notify of network outage #106

Closed paidforby closed 6 years ago

paidforby commented 7 years ago

create an onNotFound dns redirect to a static splash page stored on router

paidforby commented 7 years ago

Found this in sudowrt-packages but it is just a place holder init script. We may need to use uHTTPd? https://wiki.openwrt.org/doc/uci/uhttpd
Also general sudocode to clarify that this should only take effect when there is no access to the WAN

receive http request
if ( not found && no internet access ) then
if ( not found on local mesh ) then
redirect to splash page
with links to monitoring page? or available services on the mesh?
paidforby commented 7 years ago

This looks like a good example to follow https://andrewwippler.com/2016/07/15/openwrt-captive-portal/
it uses nginx for the web server and the cgi-bin for redirection

paidforby commented 7 years ago

nginx is probably overkill for what we need to to do. Might be worth adding this to the feeds? https://github.com/br101/pingcheck

paidforby commented 7 years ago

Simpler solution? https://michael.stapelberg.de/Artikel/openwrt_wan_watchdog

paidforby commented 7 years ago

that simple script works, now can we just modify the dnsmasq config from that script? looking through the man page http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

paidforby commented 7 years ago

maybe have dnsmasq point to a different hosts file? something like mesh_hosts? and then only use that for name resolution until the network is back up?

paidforby commented 7 years ago

Found what I'm looking from that man page, dnsmasq --address

The domain specification works in the same was as for --server, with the additional facility that /#/ matches any domain. Thus --address=/#/1.2.3.4 will always return 1.2.3.4 for any query not answered from /etc/hosts or DHCP and not sent to an upstream nameserver by a more specific --server directive.

paidforby commented 7 years ago 
/etc/init.d/dnsmasq stop
dnsmasq --address=/#/170.30.0.1
/etc/init.d/dnsmasq start

worked for redirecting all traffic on the private SSID to the admin page, not sure about the peoplesopen SSID? (also my browser cached the page, so now i get shown the peoplesopen dash every time try to go to google...)

paidforby commented 7 years ago

having problems with dnsmasq and seems like a hacky way of doing it, going back to earlier example, current idea is this:

paidforby commented 7 years ago

totally gonna to write this in lua, http://bits.mdminhazulhaque.io/openwrt/run-custom-lua-script-as-cgi-with-uhttpd.html

sierkje commented 7 years ago

I'll have to read up, but I'll provide some feedback soon. Mostly just commenting because now I'll get email notifications.

paidforby commented 7 years ago

@sierkje this might interest you, https://github.com/wifidog/wifidog-auth its written in PHP, they also have one written in C

paidforby commented 7 years ago

opkg will neither update nor install packeages on my router because it is timing out. Unclear why, but it is making it impossible to test anything. I'm going to add a few prospective packages (e.g. uhttp_mod_lua, wifidog, nodogsplash...?) to the build feeds and rebuild the firmware tonight so I at least have something to test tomorrow.

paidforby commented 7 years ago

Anyone know how functional this is? https://github.com/sudomesh/sudowrt-packages/tree/master/net/mesh-watchdog

paidforby commented 7 years ago

Progress made: opkg update now works! it was trying to route through peoplesopen (which is clearly still down...) Solution was to turn down the peoplesopen tunneling interface with ifconfig l2tp0 down.

Now running into issues with the examples: Following the lua one, http://bits.mdminhazulhaque.io/openwrt/run-custom-lua-script-as-cgi-with-uhttpd.html It throws this error when running lua index.lua:

lua: index.lua:1: module 'luci.http.protocol' not found:
    no field package.preload['luci.http.protocol']
    no file './luci/http/protocol.lua'
    no file '/usr/share/lua/luci/http/protocol.lua'
    no file '/usr/share/lua/luci/http/protocol/init.lua'
    no file '/usr/lib/lua/luci/http/protocol.lua'
    no file '/usr/lib/lua/luci/http/protocol/init.lua'
    no file './luci/http/protocol.so'
    no file '/usr/lib/lua/luci/http/protocol.so'
    no file '/usr/lib/lua/loadall.so'
    no file './luci.so'
    no file '/usr/lib/lua/luci.so'
    no file '/usr/lib/lua/loadall.so'
stack traceback:
    [C]: in function 'require'
    index.lua:1: in main chunk
    [C]: ?

I'm questioning the legitimacy of this example as the author was not aware that lua uses -- for comments not #

As for nodogsplash, when I run opkg install nodogsplash I receive the following error:

Installing nodogsplash (0.9_beta9.9.8-2) to root...
Downloading http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages/routing/nodogsplash_0.9_beta9.9.8-2_ar71xx.ipk.
Multiple packages (kmod-ipt-ipopt and kmod-ipt-ipopt) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (kmod-ipt-ipopt and kmod-ipt-ipopt) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (kmod-ipt-core and kmod-ipt-core) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (kmod-ipt-core and kmod-ipt-core) providing same name marked HOLD or PREFER. Using latest.
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for nodogsplash:
 *  kernel (= 3.18.23-1-b2f200610f46d20ef52d269421369d0c) * 
 * opkg_install_cmd: Cannot install package nodogsplash.

running uname -a provides the following info

Linux <hostname> 3.18.45 #1 Sun Apr 30 16:18:06 UTC 2017 mips GNU/Linux

I read a few places that nodogsplash does not play well with the latest version of OpenWrt? Will research further, though I am more interested in pursuing a custom lua script rather than researching dependency/versioning issues for a package that still may not do what we want. @sierkje if you'd like to try for nodogsplash, I can set you up with a node on tues.

paidforby commented 7 years ago

bypassed nodogsplash error with opkg install nodogsplash --nodeps no clue if it will function properly

sierkje commented 7 years ago
  1. Glad to see all your hours of work finally paid off.
  2. We want to use a "captive portal provider" that does not require an external gateway. (Wifidog won't work, for example.) But I'm not invested in nodogsplash at all.
  3. I'd appreciate it if you could/would set me up with a node; either for trying nodogsplash or for working on other stuff.
paidforby commented 7 years ago

Will do! I have a hello world lua script running over the uhttpd server, https://wiki.openwrt.org/doc/uci/uhttpd#luciwithembeddedluainterpreter

I'm going to continue working with that, perhaps I'll have more done by tuesday.

paidforby commented 7 years ago

nodogsplash is now working also! it will need a little work, I think I can just start and stop it with that wan-watchdog script, then we just need a decent looking frontend.

jnny commented 7 years ago

some relevant repos, albeit dated (ping @Juul for updates to these):

historical/research:

really need to re-organize the wiki and trim outdated stuff. hope some of this is helpful and maybe saves some time!

jhpoelen commented 7 years ago

as shared by @Juul on mesh mailing list (hopefully we can consolidate this info into pages mentioned by @jnny

Folks have been talking about using splash pages and captive portals. I figured I'd summarize past sudo mesh experiences.

Neither the wifi standard nor any commonly implemented network standards include a mechanism for logging in, paying or even clicking accept before gaining access to a network.

As a sorta hack people have implemented captive portals where you connect to a network but then don't gain access to the wider internet until you perform some action.

This is usually implemented such that when you connect you appear to be connected to the internet, but trying to access the internet doesn't work and when you attempt to access a website via HTTP you will instead get a different website showing you some sorta login or splash page. This is done by intercepting HTTP requests and always sending the splash page as a response, no matter what the HTTP request was. This hack was already very problematic for headless devices since they have no way of performing the web action required to gain access to the network.

With the widespread use of HTTPS, the splash page hack became even more problematic since the browser upon seeing a site other than the expected site will of course give an SSL warning due to the SSL certificate not matching the domain name.

Devices then began implementing captive portal detection. This is bad. It's a hack to deal with another hack. They accomplish this by requesting a web page over HTTP from a specific URL where they know what the response is supposed to be, and if they get a response other than the expected response then they know they are behind a captive portal and they can present the user with the splash page. This is implemented differently by different devices. Microsoft devices and Android devices contact a specific hostname (or set of hostnames) that are set aside for only doing captive portal detection. Apple devices are different in that they try to access a web page at apple.com. As far as I know, no linux desktop systems perform captive portal detection. Most devices will pop up the captive portal page when they detect the captive portal, but e.g. some android devices will show the connection icon in yellow instead of white and will put a notification in the notification area that can be clicked to pop up the captive portal. This can be very easy to miss and the user might just get annoyed that the internet isn't working. Also, some iDevices will only sometimes show the captive portal page. It seems like they tend to show it the first time they encounter it, but when re-connected they sometimes seemed to sit there doing nothing. This was a couple of iOS versions ago so it may have changed.

We previously implemented a fake captive portal, where the idea was that we could pop up a splash page by pretending to be a captive portal by faking out the captive portal detectors, which would cause them to display the splash page even though the internet is fully available. This solution is good because it doesn't interfere with headless devices.

However, this is really complicated. You have to know the IPs of all hostnames involved in captive portal detection, and of course Apple, Microsoft, etc. use many different IPs for the same hostname, so the IP a given client receives from a DNS server can be different from the IP another client gets. So you either need to constantly keep a fully updated list of IPs for each hostname or you need to try to ensure that all clients use a DNS server you control so you can provide fake responses to DNS queries for those hostnames. This last solution is probably the best one (and the one we used), but then you end up with the apple-specific issue that now all DNS requests for apple.com end up going to the IP you provided rather than apple.com. You can forward everything but HTTP requests to the real apple.com IP but for the HTTP requests you'll have to filter them and forward all of the requests except the captive portal requests based on URL. We had several issues with e.g. iOS updates failing due to this system being imperfectly implemented on our end.

This whole system was implemented on the exit node but it gave us quite a few issues so I ended up disabling it until we could find the time to get it back up.

You can find most of the related scripts here:

https://github.com/sudomesh/exitnode

with a few scripts from this system also present in the firmware.

I can walk anyone interested through this system when I get back.

Apologies for the undirected info dump but I figured it might be useful.

-- marc/juul

jhpoelen commented 7 years ago

assuming that most folks have secondary internet - why not make a red/green dashboard on http://peoplesopen.net to indicate the various services, including internet access through the exit node?

jhpoelen commented 7 years ago

In addition to the green/red there would be a way to direct to discussion room / mailing list or other way to get in touch or help fix / troubleshoot the issue.

jhpoelen commented 6 years ago

Consensus was reached to not use a splash page.

bennlich commented 6 years ago

@jhpoelen just to clarify, I think you mean consensus was reached not to use a captive portal status page. But some other status page, like the red/green thing on peoplesopen.net you mention, might still be desired. Is that right?

jhpoelen commented 6 years ago

@bennlich yep - the red/green light would be monitoring the network as a whole. I was thinking to spend some time on monitoring this week. Would you be interested in pairing up on that?

paidforby commented 6 years ago

@bennlich and @jhpoelen I believe what y'all are talking about is relevant to this bug https://github.com/sudomesh/bugs/issues/14 discussion can be redirected there