Sudo Room - User contributions [en]

5MoF 2017-04-05

2017-04-06T02:45:54Z

Mitar: Added slides.

Put your name and title of your presentation - additionally a link if anyone wants to learn more.

Please feel free to email ([mailto:info@sudoroom.org info@sudoroom.org]) if you have questions or concerns about this event or 5MoF in general.

1.

2. Chris Jefferies - raspberry pis, auto-wifi raspian, xbee radios, wemos D1mini radios, node-red, MQTT, graphite/grafana, hubot/rocket.chat

3. Eran - CENX4 - A completely open, modular MIDI controller platform

4. Mitar - What is Intel SGX and how you can secure your JavaScript using my new [https://github.com/luckychain/node-secureworker NPM package]. ([https://docs.google.com/presentation/d/1oVyJUyNrsXY1QW0Plyw-jA5a7GeMsR84J-5yJ6IEXks slides])

5. [[User:juul|juul]] - [https://fread.ink/ fread.ink] - Building a free and open source alternate operating system for electronic paper ebook readers.

6. Jake - Buck converters, how do they work?

8. Captain Morgan - Making flexible circuits

9. Robb - Prof-quality open source event live streaming

10. [[User:Romyilano]] - My project to build a healthy eating tool through cartoon characters that interact with your environment.

5MoF 2017-04-05

2017-04-05T23:02:12Z

Mitar:

Put your name and title of your presentation - additionally a link if anyone wants to learn more.

Please feel free to email ([mailto:info@sudoroom.org info@sudoroom.org]) if you have questions or concerns about this event or 5MoF in general.

1.

2. Chris Jefferies - raspberry pis, auto-wifi raspian, xbee radios, wemos D1mini radios, node-red, MQTT, graphite/grafana, hubot/rocket.chat

3. Eran - CENX4 - A completely open, modular MIDI controller platform

4. Mitar - What is Intel SGX and how you can secure your JavaScript using my new [https://github.com/luckychain/node-secureworker NPM package].

5. [[User:juul|juul]] - [https://fread.ink/ fread.ink] - Building a free and open source alternate operating system for electronic paper ebook readers.

6. Jake - Buck converters, how do they work?

8. Captain Morgan - Making flexible circuits

9. Robb - Prof-quality open source event live streaming

10. [[User:Romyilano]] - My project to build a healthy eating tool through cartoon characters that interact with your environment.

5MoF 2017-04-05

2017-03-16T07:06:57Z

Mitar: Added SGX presentation.

Put your name and title of your presentation - additionally a link if anyone wants to learn more.

Please feel free to email ([mailto:info@sudoroom.org info@sudoroom.org]) if you have questions or concerns about this event or 5MoF in general.

1.

2.

3. [[User:tunabananas|tunabananas]] - How to Buy a Building - and keep it radical! - You've got a solid community, but how does one catalyze excited newbie energy / burnt out founders / confused in-betweens into the kind of productivity needed to acquire and maintain a multi-use space when moving from DIY -> DIT -> WE GONNA OWN THIS BUILDING OMG WTF?!?

4. Mitar - What is Intel SGX and how you can secure your JavaScript using my new [https://github.com/luckychain/node-secureworker|NPM package].

5.

6.

8.

9.

10.

Mesh/Firmware

2013-10-26T07:53:21Z

Mitar: /* Watchdog script */

Documentation for the sudo mesh firmware.

= Firmware generation features =

It should be easy to generate a new firmware with the following custom config:

*Location and ownership information.
:Contact info should be saved in a secure database but maybe not on the node itself?
*Randomly generated passwords set for wpa2, admin interface and ssh.
:The SSH password should be stored securely and a couple of stickers with the wpa2 and admin password should be printed for the user.
*Web interface
*ssh key generation

[http://meshkit.freifunk.net/ Freifunk Meshkit] is pretty neat!

[https://github.com/sudomesh/openwrt-firmware Sudomesh Firmware Github Repo]

Status:

= Stuff the firmware should have =

<big>Ranked from most to least important</big>

== InternetIsDownRedirect ==

When the node doesn't have internet access, it will redirect traffic to our mesh hosted [[Mesh/Firmware#Splash_page|Splash Page]].

We need something hosted on the node that can check if it has access to the internet. There's a bit of an issue where certain OSes won't connect to APs that don't have internet access. [[User:Juul|Juul]] will look into building a hack that properly manages these requests and redirects them to our node-hosted site.

InternetIsDownRedirect may also have to fake the expected captive portal detection responses? We need to figure out if android/iOS/Mac/Windows will connect to a wifi that does not have internet access.

Status: Implemented except for OS-specific captive portal requests.

== Splash page ==

We can capture OS specific probes in order to specifically redirect captive portal requests without affecting any other network traffic.

Features:

* Brief info on the mesh
* Link to our website?

Status:

[[User:Juul|Juul]] is in the process of implementing. He needs help with:
* Finding out captive portal request protocols for different OSes. He's covered Iphone, but needs information on other hardware
* We need UX/UI designers!
* Co-located server ($$)

== SSH server ==

The SSH server should be contactable from any interface. It should initially allow root access using a random generated password that the mesh group has and that the node owner can get and change if they are so inclined.

Status: Need Key generation feature. Otherwise Implemented in openwrt. See firmware generation above.

== BATMAN-adv ==

We'll use this as the mesh protocol.

Status: Implemented

== Multiple virtual network interfaces with their own SSIDs ==

*One ad-hock mode, unencrypted interface for the mesh nodes, e.g. sudomesh-backchannel
*One access point mode, unencrypted interface, for non-mesh devices to connect to the mesh, e.g. sudomesh.
*One access point mode, private interface with WPA2, for the people who own the nodes. [optional]

Traffic on the private interface should be completely separated from traffic on the non-private interfaces unless a client connected to the private interface requests an IP on the mesh.

Maybe the last one is optional because some people may not need that feature (they already have another access point and they want to keep it), but then how do people administrate the router?

In order to serve a secure web admin config to home users, we'll probably always serve 3 APs with one private WPA encrypted home link so that users can access their admin page.

Status: Implemented

== Web admin interface ==

Development information should be put in [[Mesh/Firmware/Web_Admin_Development|Web Admin Dev]]. This section can remain a wish-list.

A very simple one-page interface. It should do at least the following:

*Display some set of user statistics
:Ideally we could list/graph the number of people who have associated with your mesh node.
:We could also just list/graph the up/down data of people who have been using the mesh.
*Set location, name, description.
:But do you want to know the location centrally as well so that you can display nodes on the map? Will people enter this information twice or will you pull this information from nodes and then display on the map? Same for name and description. I would suggest that information is stored only once. In your case on the node itself. So probably you can then pull this information through nodewatcher scripts on nodes and then display nodes the map. Just really should not require people to enter or maintain information on two places because it desyncs very fast. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:20, 24 July 2013 (PDT)
*Let people select how much bandwidth they share.
:They always share 100% when they're not using the connection themselves.
::This works if people are using their private SSIDs on the node. But if the node is connected to their existing home network you might not easily configure such sharing. But maybe there is a way to detect that host network is free and can limits can be increased. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:20, 24 July 2013 (PDT)
:Do any ISPs have bandwidth caps around here? If so, let people specify how many MB to share per month.
:Maybe also a button for temporary increase limits (make them more restrictive) which are then after some time automatically restored.
*Let people change the admin password and the private wifi wpa2 password.
:Probably private SSID as well.
*Donate / "buy routers as presents for your friends"-button.
:One idea we had (but this is probably better for splash screen) is "adopt a node". Where a neighbor who uses a node a lot and depends on the node can donate some money to keep it up, but can then give a nickname or avatar to the node. Or something. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:20, 24 July 2013 (PDT)

Status: [[User:Maxb|Maxb]] is implementing.

Source here:

https://github.com/sudomesh/luci-app-peopleswifi

== Watchdog script ==

Node tests itself to see if it has connectivity, etc and resets itself if necessary. OpenWrt supports the hardware watchdog on our PicoStations without any additional hacking, yay!

By default the hardware watchdog will automatically hard-reset the AP if /dev/watchdog is not written to at least once every 60 seconds. A Lua library has been written to interface with the batman-adv kernel module through the batctl command line utility. We need to identify a list of conditions that require a hard-reset and work them into the Lua watchdog script in the openwrt-firmware repository.

The Freifunk group has an awesome watchdog setup, details: http://wiki.freifunk.net/Kamikaze/LuCI/Watchdog

list of possible reset conditions: high sustained load, cron goes down, sshd goes down.

[https://github.com/wlanslovenija/firmware-packages-opkg/tree/master/util/nodewatcher-watchdog nodewatcher watchdog]

== QoS / bandwidth shaping ==

To support letting node owners select how much bandwidth they share.

Status: [[User:Juul|Juul]] is hacking on.

== Internet VPN ==

The firmware should tunnel all Internet traffic from the mesh through a VPN server, unless this feature is specifically disabled.

This should not be a single VPN server, as that would be a single point of failure.

I suggest to use [http://wlan-si.net/blog/2012/10/29/tunneldigger-the-new-vpn-solution/ TunnelDigger]. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 21:50, 11 July 2013 (PDT)

[[Mesh/Network_topology|Network Topology]]

Status: [[User:Juul|Juul]] is implementing.

== Mesh VPN ==

If the mesh does not see any other nodes (and maybe even if it does?), and it has internet, then it should connect to another node or two over VPN. The easy solution is to use the same VPN servers as for the internet.

[[Mesh/Network_topology|Network Topology]]

Status: Implemented

== DHCP and batman-adv gateway mode ==

Nodes with an internet connection should run DHCP and [http://www.open-mesh.org/projects/batman-adv/wiki/Gateways batman-adv gateway mode]. We want to detect if the node can connect to a relay in which case it should configure as a batman-adv gateway server node. Otherwise they should configure as batman-adv gateway clients.

Staus: Needs hacking.

== Location and status reporting ==

Something that reports location and status when polled.

We developed this format and easy to publish status data from nodes for our [http://dev.wlan-si.net/wiki/Nodewatcher/NodeTelemetryProvider nodewatcher]. OpenWrt packages are [https://github.com/wlanslovenija/firmware-packages-opkg/tree/master/util here]. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:02, 11 July 2013 (PDT)

Nice to have:

*Status info: How many nodes is your node connected to. Is the internet link working.
*An "I don't know what my internet bandwidth is, test it for me"-function.
*Usage statistics (so people can see how many people they helped get internet!)
:This is the most important thing! [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:20, 24 July 2013 (PDT)
:You should add as well graphs on how much bandwidth was consumed by the node. This is useful when hosts see that their Internet is slow and believe that it was because of the node. Then they can check and see if it is really node (which often is not) or maybe just ISP has problems. Important because people like to attribute issues they have to nodes they don't understand. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:20, 24 July 2013 (PDT)
*Let people put up a bit of info about their node / house / co-op, on a simple web page that people can access only if they're connected to that node. It could be shown as part of the splash page.

Status: Waiting for nodewatcher project to finish

== Intelligent Wifi Channel Switching ==

It would be nice to be able to have the network intelligently determine channels

== IPv6 support ==

We should have IPv6 support, but I am ok with launching the mesh with only IPv4 and adding in IPv6 later. ([[User:Juul|Juul]] ([[User talk:Juul|talk]]))

= Stuff the firmware could have =

== DNS server ==

Each node could run its own (caching) DNS server. Doing this would allow people to access the admin interface for their node by going to e.g. http://me.mesh/ from the private interface.

== RSSI Testing and Logging ==

At intervals, the nodes could conduct RSSI tests and log them with some way to compare and visualize signal strengths over time.

== Caching web proxy ==

We could use [http://www.pps.univ-paris-diderot.fr/~jch/software/polipo/ Polipo] to improve people's browsing experience. Not sure how much cpu and memory this would need. We may not be able to run it on the routers with less than 32 MB ram (e.g. the Bullet 2 HPs).

== Block ads and tracking ==

We could use e.g. [http://www.pps.univ-paris-diderot.fr/~jch/software/polipo/ Polipo] with the sources from both adblock plus and ghostery. If we implement this, it should be an optional (default off) feature that you can select on the splash page, with a "remember this" that remembers either using a cookie or using your MAC (but then we'd be logging people's MAC addresses :-S). The block should probably be time-limited (e.g. 30 days).

= Compatible devices =

We should have ready-made images for:

*One really cheap indoor router (with 3G usb stick support?) like [http://wiki.openwrt.org/toh/tp-link/tl-wr703n TP-Link TL-WR703N]
*One nice high-speed indoor router (300 mbps 802.11n)
*Ubiquiti hardware. Most of the AirMAX stuff.

Mesh/Firmware/Generating

2013-10-17T13:09:47Z

Mitar: /* Model (rough) */

= Model (rough) =

Build Server:
The one and only server responsible for building and signing SudoMesh OpenWRT images, mostly a collection of bash scripts.

Configuration Server:
One of possibly multiple servers responsible for and authenticated to query, configure and update nodes.
* python SSL socket server for configuring nodes over secure socket.
* python web server as a UI to the SSL configuration server.
** SSL libraries on the client (node) are often big. BusyBox wget does not support SSL for example. In wlan slovenija we were thinking of using SSH/SCP instead. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 06:09, 17 October 2013 (PDT)

Node:
The basic build block of any mesh!
*node-admin: extended from the openWRT admin page, used by node owner for configuration.
*node-conf-client: lua client for accepting configs and answering config queries from a configuraion server.

= Node Attributes =

The following attributes are required of the Build Server at image build time:

*Hardware model
*Firmware version

The following attributes are required of the Configuration Server for initial configuration:

*SSH host RSA keypair
*SSH host DSA keypair (optional?)
*SSH host ECDSA keypair (optional?)
*SSH keys allowed root access for debugging

The following attributes are required of the Node Op for initial configuration through the Configuration Server:

*Geographic address
*Node Op name
*Node Op email address
*Node Op phone number

= wlan slovenija =

wlan slovenija has a firmware generator tool. Here are some links:

*[https://github.com/wlanslovenija/nodewatcher/blob/master/generator/config_generator.py config_generator.py: the core code for the generator]
*[https://github.com/wlanslovenija/nodewatcher/blob/master/generator/build_image.py build_image.py: the command line tool that uses config_generator.py]

Some relevant code from config_generator.py:

<pre>
buildString = 'make image FILES="../files" PROFILE="%s" PACKAGES="policy-routing olsrd uhttpd tc nodewatcher-core nodewatcher-clients ntpclient hostapd -ppp -ppp-mod-pppoe -wpad-mini kmod-l2tp kmod-l2tp-ip kmod-l2tp-eth tunneldigger wireless-tools qos-scripts %s"' % (profile_map[self.portLayout], pkgs)
os.chdir(path)
os.system(buildString)
</pre>

The whole ''nodewatcher'' system is in fact a web interface to the image generator (this is how it all started, historically, as a web interface + IP allocation, and then we added network monitoring, node telemetry and so on).

*[http://nodes.wlan-si.net/ live version]

= freifunk =

Freifunk has a web app called meshkit for generating images.

*[http://meshkit.freifunk.net/ live web app]
*[https://github.com/freifunk/meshkit source code]

Meshkit takes a strange approach. From the readme file:

<pre>
Meshkit itself just writes a uci config file and stores it in
/etc/config/meshkwizard in the resulting firmware image. The actual
configuration is done by meshwizard, which uses community profiles
and the settings from meshkit to configure the device at first boot after
the device has been flashed.
</pre>

While I understand why community profiles would be a good idea, it seems odd that the configuration would happen on the device. Why not generate all of the required configuration before generating the image? That way you save a bit of space and an extra reboot of the device.

After looking at the code, I am not inclined to use it. Lots of freifunk-specific stuff. Few comments. In the end, all it does that we really care about is take a few values from the web app, write some config files for openwrt and run "make image" with some parameters. It does have a system for queuing builds, which is nice. Honestly, I think we're going to be better off making our own system

Mesh/Firmware/Splash page

2013-09-03T22:42:33Z

Mitar:

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.

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.

= 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 [http://www.igate.com/iblog/index.php/android-v4-2-2-updates/ appears to have changed in 4.2.2].

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 ==

Request is made to "http://www.apple.com/library/test/success.html".

== 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 to the resulting IP:

<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, again to the www.apple.com IP:

<pre>
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>

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 ==

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 [http://blog.superuser.com/2011/05/16/windows-7-network-awareness/ 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.

== 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:

<pre>
184.85.61.15 www.apple.com
</pre>

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? ([[User:Mitar|Mitar]])
::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:

<pre>
iptables -t nat -A PREROUTING -i bat0 -p tcp -d 184.85.61.15 --dport 80 -j REDIRECT --to-port 3128
</pre>

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? ([[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:

<pre>
acl mesh src 10.0.0.0/8
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl Safe_ports port 80
acl CONNECT method CONNECT
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access allow localhost
http_access allow mesh
http_access deny all
http_port 3128 transparent
coredump_dir /var/spool/squid3
# program to run to re-write urls of incoming requests
url_rewrite_program /etc/squid3/rewrite.pl
# The number of redirector processes to spawn
url_rewrite_children 10
# Bypass rewrite if all rewrite processes are busy
url_rewrite_bypass on
# This is almost certainly not needed
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
</pre>

We should see if we can use the squid ''url_rewrite_access'' directive to ensure that the rewrite.pl program is only run for the specific queries that need rewriting.

The rewrite.pl program simply replies to the captive portal probe queries with the replies from a local apache server. Here is the code of /etc/squid3/rewrite.pl:

<pre>
#!/usr/bin/perl

$splash_response = "http://localhost/splash.html\n";

$|=1;
while (<>) {
chomp;
@line = split;
$url = $line[0];
if ($url =~ /^http:\/\/www\.apple\.com\/library\/test\/success\.html/) {

print $splash_response;

} elsif ($url =~ /^http:\/\/www\.apple\.com\/$/) {

print $splash_response;

} else {
print $url . "\n";
}
}
</pre>

For versions 3.4 of squid and above, the program should look like this instead (reference [http://www.squid-cache.org/Versions/v3/3.1/cfgman/url_rewrite_program.html v3.1 docs] and [http://www.squid-cache.org/Versions/v3/3.4/cfgman/url_rewrite_program.html v3.4 docs]):

<pre>
#!/usr/bin/perl

$splash_response = "OK rewrite-url=http://localhost/splash.html\n";

$|=1;
while (<>) {
chomp;
@line = split;
$url = $line[0];
if ($url =~ /^http:\/\/www\.apple\.com\/library\/test\/success\.html/) {

print $splash_response;

} elsif ($url =~ /^http:\/\/www\.apple\.com\/$/) {

print $splash_response;

} else {
print "ERR\n";
}
}
</pre>

An apache 2 with standard configuration is running and in /var/www/splash.html has the following file:

<pre>
<!DOCTYPE html>
<html lang="en">
<head>
<meta CHARSET=utf8mb4"utf-8">
<title>peopleswifi.org</title>
</head>
<body>
<h1>Welcome to People's Wifi</h1>
<p>
Click anywhere to continue!
</p>
</body>
</html>
</pre>

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?

: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]])
:::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 ==

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:

# Periodically looks up the IP for the different servers
# Adds the result as an entry in /etc/hosts
# 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.

Mesh/Decisions

2013-08-23T06:24:52Z

Mitar: /* Block captive portal detection only */

Each new community mesh project faces a set of decisions. This page contains a discussion of some of these decisions.

= Mesh router as primary access point =

Adding a WPA2-PSK encrypted virtal access point to the router would allow node-owners to use the mesh router either as their primary private access point, or as a secondary access point in places where their existing access point doesn't reach. This could be a nice added feature, but would require some more firmware work.

:The issue with that is that primary access points are often optimally in the center of the house, while mesh nodes should be on the edge of the house.

== Decision ==

We're already been working on this. The web admin interface will be fairly minimal, allowing changing the ssid and password of the private access point, as well as manual tcp/udp port forwarding. The nat-pmp and upnp daemons will also be installed and the gui will provide access to disable/enable them.

= Commercial || non-commercial =

It may seem obvious that a community mesh project should should be non-commercial in nature, however, all societies are different and the cost and availability of hardware and skilled volunteer labour will vary quite a bit. In some places it may be possible to run a mesh based solely on donations and volunteer efforts. In other places it may be necessary to find sustainable income models. Especially in less developed countries it may be more viable to use the mesh as a way for locals to become small business owners that maintain the network and sell access to the community at affordable rates.

Here are some options spanning the range of non-commercial to commercial:

*Donations, volunteers and grants only.
*Sale of merchandise.
*Sale of pre-flashed routers with profit margin.
*Ads for local businesses on splash page.
*Pay to get higher bandwidth (freemium).
*Limited data per day for free. Pay to get more.
*Free for low-income individuals only.
*Free for private individuals and non-profits only.
*Free for node-owners only.
*Free for node-owners and they node-owners can sell access.
*Everyone has to pay.

:What about paying in work? Time-banking?

== Decision ==

I think we should stop right before the freemium model [[User:Juul|Juul]] ([[User talk:Juul|talk]]).

= Internet =

== Internet connected mesh || LAN only ==

One big decision is whether to provide internet access through the mesh. A non-internet-connected mesh would provide little popular appeal outside of disaster scenarios, and so would likely have to be designed specifically with disaster scenarios in mind, unless it is simply a platform for hackers and academics to use and learn from.

=== Decision ===

Our mesh will definitely be internet-connected.

== Sharing of Internet by node-owners ==

Do we let the node-owners share their internet connection with the mesh? If so, how do we prioritize the traffic? Do we let the node-owners decide how much of the bandwidth they share? Do we let them set a data usage cap?

If the node-owners don't use the mesh router as their access point, then there is really no way we can tell how much bandwidth is being used by the node-owner. This means the limit on the mesh-node's internet usage will have to be a hard limit, instead of being able to take advantage of unused internet bandwidth.

=== Decision ===

We let the node-owners choose to share internet or not. We let them select a percentage of available bandwidth that the mesh can always use. Whether or not this is a hard limit will probably have to depend on whether or not they have another access point that they use (or if they ever use wired ethernet).

== Connecting isolated mesh nodes over the internet ==

It's possible to connect isolated segments of the mesh through the node-owner's internet connections. For layer2 mesh protocols at least, this requires a tunnel to one or more servers that act as mesh nodes on the internet. The mesh nodes could also attempt to directly connect to a few other mesh nodes, but that would require more complication such as NAT traversal.

=== Decision ===

I have set up tunneldigger from wlan-slovenia which uses L2TP tunnels for this. Some work is still needed in dealing with MTU correctly.

== Hiding node-owners source IP ==

If someone uses internet provided by the mesh to e.g. download the newest Game Of Thrones episode, and the ISP of some innocent node-owner receives a letter from the U.S. copyright mafia, then at the very least it would be a scary experience likely resulting in the node-owner taking their node offline. In order to provide some buffer we can tunnel all internet traffic through one or more servers or "exit nodes" owned by the mesh group.

=== Decision ===

We definitely want to hide source IPs of home Cable/DSL lines.

= Organizational structure =

== Formal organization || No centralized entity || Separation of organization and network ==

The people involved in running the mesh could establish a formal organization, such as a 501c3 or a LLC, or they could simply have a formal or informal agreement between each-other, e.g. something like a group peering agreement.

The third option is to have both: The network is its own thing and anyone can peer (possibly with the requirement of signing a peering agreement) but there is also a formal organization that provides and coordinates certain services, such as e.g. selling of pre-flashed firmwares, troubleshooting mesh problems, getting funds for extra internet bandwidth for the mesh, developing firmware, spreading the word, etc. In this case, the network and central organization should probably have separate names.

== Non-profit || For profit ==

If there is a central organization, it could be either a for-profit or a non-profit. There are many variations, but some of the most relevant are:

=== 501c3 ===

Positives: Tax-exempt status. Tax-deductibility of donations. Assurance that the organization will not e.g. be bought up Google.

Negatives: Limited political activity (but EFF is a 501c3, so it's not too bad). Structure contains innate hierarchy in the separation of board of directors and members. Still have to pay e.g. sales tax even if the organization has lost money over the year.

=== B-corp certified for-profit ===

Positives: Possibly more options for how to structure organization and how to operate. Yearly losses can be deducted from taxes owed. Ability for members to be shareholders.

Negatives: May seem less trustworthy to community. May be less trustworthy (can we ensure that the corporation can never be e.g. sold to Google?). No tax-deductible donations. No tax-exemption. Ability for members to be shareholders.

== Membership / peering requirements ==

If we have a central organization, who can be a member? If not, who can peer?

=== Membership ===

The minimum possible is that everyone can be a member just by applying online (possibly we could go even further and state that anyone who claims to be a member is a member).

Going up from that we have options such as:

*Your membership fee is hosting a node.
*Your membership signup fee is buying a node.
*Your membership fee is hosting a node and sharing internet.
*Your membership fee is a monthly dollar amount.
*Your membership requires some amount of work monthly or yearly.

And of course combinations of the above.

=== Peering requirements ===

For both meshes with and without a centralized organization, there can be a peering agreement that you must sign to become part of the mesh. It could be that the agreement is only between you and the people you connect to directly, or it could be that the agreement is between you and the mesh (and all the people who are connected to the mesh).

There is also the option to have no such agreement and simply have instructions for how to connect to the mesh and let everyone sort out how they want to use the mesh on their own.

== Decision ==

We are currently leaning towards a 501c3 with the network being a separate thing.

= Ownership of and access to infrastructure =

== Centrally owned || Distributed ownership ==

Is the hardware owned by the people who host the nodes or are they owned by the central organization.

Who's responsibility is it to pay for new nodes if they break?

Hybrid models are possible, e.g: People buy pre-flashed nodes from the local mesh organization and own their nodes, but they pay a small membership fee (or not), and basically get an unlimited warranty, where the mesh group will replace their router automatically if it stops working.

== Management of nodes ==

Who manages the nodes? In case of firmware updates, who has access to send them to the nodes? Do each individual node-owner have to approve each update? It could be default-approve but give them a notice and a time-frame to opt out of an update. Any decision of individuals to not accept updates from the mesh group could prove very problematic in case of major updates, e.g. changing of mesh routing protocol, but even if no such updates are to occur, the firmware will have to be very specifically designed around the limitation that updates to nodes are not guaranteed to ever occur, if we allow users to manage their own nodes.

== Decision ==

We haven't discussed this very much. I think we should let people own the nodes that they host and let the central organization manage the nodes unless the node-owner wants to manage their own node. We will have to have a clear strategy for who has access to privately owned nodes at any given time, and contracts/agreements about what they are allowed to do to them. We will have to make it very clear to the node-owners what letting us manage the nodes means (that, if obused, this power can be used to monitor their unencrypted traffic and phish ) and how we monitor and prevent abuse from the people in charge (though this is really no different from a normal ISP) [[User:Juul|Juul]] ([[User talk:Juul|talk]])

:There is as well a bit of difference if nodes are just mesh nodes or if they are being used for private SSID as well.

= Sensors / add-ons =

Most routers provide a 3.3 volt serial port that can be used to attach microcontrollers and all manner of sensors. Examples:

*Temperature, humiditiy, pressure
:Ultra-local weather stations.
*Seismic sensors
:See how an earthquake spreads.
*Air quality sensors
:How's the smog today?
*Bluetooth or ZigBee gateways
:Connect low-power devices to the mesh.

= Captive portal / splash page =

A splash page is a powerful way to tell people about the network and show them to e.g. a community portal, but it can be annoying and problematic for a lot of reasons. Here are some different solutions.

== Full captive portal ==

Blocking all traffic until the user clicks a button or logs in is super annoying and breaks a bunch of things, however, if the network has problems with abuse and wants all users to authenticate before use, then this could be necessary.

A really big problem for the common user is that it doesn't work with SSL.

== Block port 80 only ==

This would only show a captive portal on port 80 until the user clicks a button to continue or only for the first connection to port 80.

This is less annoying, but will still break many things and users may wonder why they've been surfing for a while (SSL sites) and then suddenly see the captive portal.

== Block captive portal detection only ==

Find out exactly how the captive portal detection mechanisms for different operating systems work and block this detection only, and only on the first attempt. This can be problematic, since e.g. iOS devices request a specific URL on http://www.apple.com and so required layer 7 inspection to match the packet. Another downside is that not all operating systems support captive portal detection. The following are known to support detection:

*Android v?
*iOS 4.3 (maybe earlier)
*Mac OS 10.8 (maybe earlier)
*Windows 8 (maybe earlier)

To our knowledge, Ubuntu and other popular GNU/Linux systems do not support detection.

:In talking with some other mesh people I learned that intercepting only first request is not useful because it is almost always some background service which tries that (eg. autoupdate) so user never really sees anything.
:Displaying things in OS detected captive portal window might be bad because this window is a special browser window, so user cannot really browse a lot there (no bookmarks for example). On Mac OS X, furthermore, window is automatically closed by OS when it is detected that connectivity is not limited anymore.

== No captive portal ==

With no captive portal, many people will likely use the mesh and never learn about what it is. The SSID can still be a valid URL e.g. freepublicwifi.net and hopefully people who are curious will type it in.

== Decision ==

I will figure out how feasibile it is to block captive portal detection only. [[User:Juul|Juul]] ([[User talk:Juul|talk]])

= Network neutrality =

To what degree do we support and allow the blocking, mangling and prioritization of traffic?

At one extreme are things such as actively blocking certain types of traffic. This could be blocking bittorrent traffic, or netflix, or it could be disallowing any commercial use of the network at all.

= Logging =

To what degree does the mesh log or allow logging of traffic? If there are logs, are they centrally aggregated?

= Encryption =

Are links encrypted between nodes? We could decide to take drastic measure and only allow or only encourage point-to-point encrypted connections. We could only allow connections the internet using a VPN connection directly from the client to one of our exit nodes. These types of measures would drastically reduce the usability of the mesh, since they would require more than just connecting to a wifi access point.

= Authentication =

Some free public wifi networks require authentication (e.g. BART wifi). This makes it easier to deal with abuse but also raises privacy concerns. Authentication can be annoying, though implemented correctly it will be a one-time setup for each device.

== Decision ==

I feel like authentication would just make the network annoying and difficult to use. I say we just make it free and open. [[User:Juul|Juul]] ([[User talk:Juul|talk]])

= Abuse =

How does the mesh define and handle abuse?

Some examples of abuse definitions:

*Unintentionally running a DHCP server on the mesh.
*Using too much of the available bandwidth for too long.
*Using the mesh for illegal activities.
*Targeting other mesh users (e.g. phishing, password sniffing).
*Intentionally attempting to disrupt the functioning of the mesh.

Some of these can be blocked automatically. Some can be detected, and could land people on a captive portal that explains what they did wrong and how to fix it. Dealing with intentional abuse can be tricky if there is no authentication.

== Decision ==

We should block some things that definitely don't belong on the mesh, like rogue DHCP servers, and have an email address for contacting us about abuse. If there are valid use-cases, then moving all abusive MACs/IPs to a special VLAN with a captive portal and limited access could be a way to deal, but it may not be necessary at all. [[User:Juul|Juul]] ([[User talk:Juul|talk]])

= Support =

How much support will we provide and will it be provided by volunteers only or will we have paid support?

= Naming =

Decision: Still discussing. Several people seem to like a more generic and meaning name for the network, and less meaning less generic name for the organization.

== Meaning vs. non-meaning ==

Meaning example: RouteAround.net

Non-meaning: Project Gourami

== Generic vs. non-generic ==

Generic example: Free Public Wifi

Non-generic example: The People's Republic of Wifi

Mesh/Decisions

2013-08-23T06:20:54Z

Mitar: /* Decision */

Each new community mesh project faces a set of decisions. This page contains a discussion of some of these decisions.

= Mesh router as primary access point =

Adding a WPA2-PSK encrypted virtal access point to the router would allow node-owners to use the mesh router either as their primary private access point, or as a secondary access point in places where their existing access point doesn't reach. This could be a nice added feature, but would require some more firmware work.

:The issue with that is that primary access points are often optimally in the center of the house, while mesh nodes should be on the edge of the house.

== Decision ==

We're already been working on this. The web admin interface will be fairly minimal, allowing changing the ssid and password of the private access point, as well as manual tcp/udp port forwarding. The nat-pmp and upnp daemons will also be installed and the gui will provide access to disable/enable them.

= Commercial || non-commercial =

It may seem obvious that a community mesh project should should be non-commercial in nature, however, all societies are different and the cost and availability of hardware and skilled volunteer labour will vary quite a bit. In some places it may be possible to run a mesh based solely on donations and volunteer efforts. In other places it may be necessary to find sustainable income models. Especially in less developed countries it may be more viable to use the mesh as a way for locals to become small business owners that maintain the network and sell access to the community at affordable rates.

Here are some options spanning the range of non-commercial to commercial:

*Donations, volunteers and grants only.
*Sale of merchandise.
*Sale of pre-flashed routers with profit margin.
*Ads for local businesses on splash page.
*Pay to get higher bandwidth (freemium).
*Limited data per day for free. Pay to get more.
*Free for low-income individuals only.
*Free for private individuals and non-profits only.
*Free for node-owners only.
*Free for node-owners and they node-owners can sell access.
*Everyone has to pay.

:What about paying in work? Time-banking?

== Decision ==

I think we should stop right before the freemium model [[User:Juul|Juul]] ([[User talk:Juul|talk]]).

= Internet =

== Internet connected mesh || LAN only ==

One big decision is whether to provide internet access through the mesh. A non-internet-connected mesh would provide little popular appeal outside of disaster scenarios, and so would likely have to be designed specifically with disaster scenarios in mind, unless it is simply a platform for hackers and academics to use and learn from.

=== Decision ===

Our mesh will definitely be internet-connected.

== Sharing of Internet by node-owners ==

Do we let the node-owners share their internet connection with the mesh? If so, how do we prioritize the traffic? Do we let the node-owners decide how much of the bandwidth they share? Do we let them set a data usage cap?

If the node-owners don't use the mesh router as their access point, then there is really no way we can tell how much bandwidth is being used by the node-owner. This means the limit on the mesh-node's internet usage will have to be a hard limit, instead of being able to take advantage of unused internet bandwidth.

=== Decision ===

We let the node-owners choose to share internet or not. We let them select a percentage of available bandwidth that the mesh can always use. Whether or not this is a hard limit will probably have to depend on whether or not they have another access point that they use (or if they ever use wired ethernet).

== Connecting isolated mesh nodes over the internet ==

It's possible to connect isolated segments of the mesh through the node-owner's internet connections. For layer2 mesh protocols at least, this requires a tunnel to one or more servers that act as mesh nodes on the internet. The mesh nodes could also attempt to directly connect to a few other mesh nodes, but that would require more complication such as NAT traversal.

=== Decision ===

I have set up tunneldigger from wlan-slovenia which uses L2TP tunnels for this. Some work is still needed in dealing with MTU correctly.

== Hiding node-owners source IP ==

If someone uses internet provided by the mesh to e.g. download the newest Game Of Thrones episode, and the ISP of some innocent node-owner receives a letter from the U.S. copyright mafia, then at the very least it would be a scary experience likely resulting in the node-owner taking their node offline. In order to provide some buffer we can tunnel all internet traffic through one or more servers or "exit nodes" owned by the mesh group.

=== Decision ===

We definitely want to hide source IPs of home Cable/DSL lines.

= Organizational structure =

== Formal organization || No centralized entity || Separation of organization and network ==

The people involved in running the mesh could establish a formal organization, such as a 501c3 or a LLC, or they could simply have a formal or informal agreement between each-other, e.g. something like a group peering agreement.

The third option is to have both: The network is its own thing and anyone can peer (possibly with the requirement of signing a peering agreement) but there is also a formal organization that provides and coordinates certain services, such as e.g. selling of pre-flashed firmwares, troubleshooting mesh problems, getting funds for extra internet bandwidth for the mesh, developing firmware, spreading the word, etc. In this case, the network and central organization should probably have separate names.

== Non-profit || For profit ==

If there is a central organization, it could be either a for-profit or a non-profit. There are many variations, but some of the most relevant are:

=== 501c3 ===

Positives: Tax-exempt status. Tax-deductibility of donations. Assurance that the organization will not e.g. be bought up Google.

Negatives: Limited political activity (but EFF is a 501c3, so it's not too bad). Structure contains innate hierarchy in the separation of board of directors and members. Still have to pay e.g. sales tax even if the organization has lost money over the year.

=== B-corp certified for-profit ===

Positives: Possibly more options for how to structure organization and how to operate. Yearly losses can be deducted from taxes owed. Ability for members to be shareholders.

Negatives: May seem less trustworthy to community. May be less trustworthy (can we ensure that the corporation can never be e.g. sold to Google?). No tax-deductible donations. No tax-exemption. Ability for members to be shareholders.

== Membership / peering requirements ==

If we have a central organization, who can be a member? If not, who can peer?

=== Membership ===

The minimum possible is that everyone can be a member just by applying online (possibly we could go even further and state that anyone who claims to be a member is a member).

Going up from that we have options such as:

*Your membership fee is hosting a node.
*Your membership signup fee is buying a node.
*Your membership fee is hosting a node and sharing internet.
*Your membership fee is a monthly dollar amount.
*Your membership requires some amount of work monthly or yearly.

And of course combinations of the above.

=== Peering requirements ===

For both meshes with and without a centralized organization, there can be a peering agreement that you must sign to become part of the mesh. It could be that the agreement is only between you and the people you connect to directly, or it could be that the agreement is between you and the mesh (and all the people who are connected to the mesh).

There is also the option to have no such agreement and simply have instructions for how to connect to the mesh and let everyone sort out how they want to use the mesh on their own.

== Decision ==

We are currently leaning towards a 501c3 with the network being a separate thing.

= Ownership of and access to infrastructure =

== Centrally owned || Distributed ownership ==

Is the hardware owned by the people who host the nodes or are they owned by the central organization.

Who's responsibility is it to pay for new nodes if they break?

Hybrid models are possible, e.g: People buy pre-flashed nodes from the local mesh organization and own their nodes, but they pay a small membership fee (or not), and basically get an unlimited warranty, where the mesh group will replace their router automatically if it stops working.

== Management of nodes ==

Who manages the nodes? In case of firmware updates, who has access to send them to the nodes? Do each individual node-owner have to approve each update? It could be default-approve but give them a notice and a time-frame to opt out of an update. Any decision of individuals to not accept updates from the mesh group could prove very problematic in case of major updates, e.g. changing of mesh routing protocol, but even if no such updates are to occur, the firmware will have to be very specifically designed around the limitation that updates to nodes are not guaranteed to ever occur, if we allow users to manage their own nodes.

== Decision ==

We haven't discussed this very much. I think we should let people own the nodes that they host and let the central organization manage the nodes unless the node-owner wants to manage their own node. We will have to have a clear strategy for who has access to privately owned nodes at any given time, and contracts/agreements about what they are allowed to do to them. We will have to make it very clear to the node-owners what letting us manage the nodes means (that, if obused, this power can be used to monitor their unencrypted traffic and phish ) and how we monitor and prevent abuse from the people in charge (though this is really no different from a normal ISP) [[User:Juul|Juul]] ([[User talk:Juul|talk]])

:There is as well a bit of difference if nodes are just mesh nodes or if they are being used for private SSID as well.

= Sensors / add-ons =

Most routers provide a 3.3 volt serial port that can be used to attach microcontrollers and all manner of sensors. Examples:

*Temperature, humiditiy, pressure
:Ultra-local weather stations.
*Seismic sensors
:See how an earthquake spreads.
*Air quality sensors
:How's the smog today?
*Bluetooth or ZigBee gateways
:Connect low-power devices to the mesh.

= Captive portal / splash page =

A splash page is a powerful way to tell people about the network and show them to e.g. a community portal, but it can be annoying and problematic for a lot of reasons. Here are some different solutions.

== Full captive portal ==

Blocking all traffic until the user clicks a button or logs in is super annoying and breaks a bunch of things, however, if the network has problems with abuse and wants all users to authenticate before use, then this could be necessary.

A really big problem for the common user is that it doesn't work with SSL.

== Block port 80 only ==

This would only show a captive portal on port 80 until the user clicks a button to continue or only for the first connection to port 80.

This is less annoying, but will still break many things and users may wonder why they've been surfing for a while (SSL sites) and then suddenly see the captive portal.

== Block captive portal detection only ==

Find out exactly how the captive portal detection mechanisms for different operating systems work and block this detection only, and only on the first attempt. This can be problematic, since e.g. iOS devices request a specific URL on http://www.apple.com and so required layer 7 inspection to match the packet. Another downside is that not all operating systems support captive portal detection. The following are known to support detection:

*Android v?
*iOS 4.3 (maybe earlier)
*Mac OS 10.8 (maybe earlier)
*Windows 8 (maybe earlier)

To our knowledge, Ubuntu and other popular GNU/Linux systems do not support detection.

== No captive portal ==

With no captive portal, many people will likely use the mesh and never learn about what it is. The SSID can still be a valid URL e.g. freepublicwifi.net and hopefully people who are curious will type it in.

== Decision ==

I will figure out how feasibile it is to block captive portal detection only. [[User:Juul|Juul]] ([[User talk:Juul|talk]])

= Network neutrality =

To what degree do we support and allow the blocking, mangling and prioritization of traffic?

At one extreme are things such as actively blocking certain types of traffic. This could be blocking bittorrent traffic, or netflix, or it could be disallowing any commercial use of the network at all.

= Logging =

To what degree does the mesh log or allow logging of traffic? If there are logs, are they centrally aggregated?

= Encryption =

Are links encrypted between nodes? We could decide to take drastic measure and only allow or only encourage point-to-point encrypted connections. We could only allow connections the internet using a VPN connection directly from the client to one of our exit nodes. These types of measures would drastically reduce the usability of the mesh, since they would require more than just connecting to a wifi access point.

= Authentication =

Some free public wifi networks require authentication (e.g. BART wifi). This makes it easier to deal with abuse but also raises privacy concerns. Authentication can be annoying, though implemented correctly it will be a one-time setup for each device.

== Decision ==

I feel like authentication would just make the network annoying and difficult to use. I say we just make it free and open. [[User:Juul|Juul]] ([[User talk:Juul|talk]])

= Abuse =

How does the mesh define and handle abuse?

Some examples of abuse definitions:

*Unintentionally running a DHCP server on the mesh.
*Using too much of the available bandwidth for too long.
*Using the mesh for illegal activities.
*Targeting other mesh users (e.g. phishing, password sniffing).
*Intentionally attempting to disrupt the functioning of the mesh.

Some of these can be blocked automatically. Some can be detected, and could land people on a captive portal that explains what they did wrong and how to fix it. Dealing with intentional abuse can be tricky if there is no authentication.

== Decision ==

We should block some things that definitely don't belong on the mesh, like rogue DHCP servers, and have an email address for contacting us about abuse. If there are valid use-cases, then moving all abusive MACs/IPs to a special VLAN with a captive portal and limited access could be a way to deal, but it may not be necessary at all. [[User:Juul|Juul]] ([[User talk:Juul|talk]])

= Support =

How much support will we provide and will it be provided by volunteers only or will we have paid support?

= Naming =

Decision: Still discussing. Several people seem to like a more generic and meaning name for the network, and less meaning less generic name for the organization.

== Meaning vs. non-meaning ==

Meaning example: RouteAround.net

Non-meaning: Project Gourami

== Generic vs. non-generic ==

Generic example: Free Public Wifi

Non-generic example: The People's Republic of Wifi

Mesh/Decisions

2013-08-23T06:16:47Z

Mitar: /* Commercial || non-commercial */

Each new community mesh project faces a set of decisions. This page contains a discussion of some of these decisions.

= Mesh router as primary access point =

Adding a WPA2-PSK encrypted virtal access point to the router would allow node-owners to use the mesh router either as their primary private access point, or as a secondary access point in places where their existing access point doesn't reach. This could be a nice added feature, but would require some more firmware work.

:The issue with that is that primary access points are often optimally in the center of the house, while mesh nodes should be on the edge of the house.

== Decision ==

We're already been working on this. The web admin interface will be fairly minimal, allowing changing the ssid and password of the private access point, as well as manual tcp/udp port forwarding. The nat-pmp and upnp daemons will also be installed and the gui will provide access to disable/enable them.

= Commercial || non-commercial =

It may seem obvious that a community mesh project should should be non-commercial in nature, however, all societies are different and the cost and availability of hardware and skilled volunteer labour will vary quite a bit. In some places it may be possible to run a mesh based solely on donations and volunteer efforts. In other places it may be necessary to find sustainable income models. Especially in less developed countries it may be more viable to use the mesh as a way for locals to become small business owners that maintain the network and sell access to the community at affordable rates.

Here are some options spanning the range of non-commercial to commercial:

*Donations, volunteers and grants only.
*Sale of merchandise.
*Sale of pre-flashed routers with profit margin.
*Ads for local businesses on splash page.
*Pay to get higher bandwidth (freemium).
*Limited data per day for free. Pay to get more.
*Free for low-income individuals only.
*Free for private individuals and non-profits only.
*Free for node-owners only.
*Free for node-owners and they node-owners can sell access.
*Everyone has to pay.

:What about paying in work? Time-banking?

== Decision ==

I think we should stop right before the freemium model [[User:Juul|Juul]] ([[User talk:Juul|talk]]).

= Internet =

== Internet connected mesh || LAN only ==

One big decision is whether to provide internet access through the mesh. A non-internet-connected mesh would provide little popular appeal outside of disaster scenarios, and so would likely have to be designed specifically with disaster scenarios in mind, unless it is simply a platform for hackers and academics to use and learn from.

=== Decision ===

Our mesh will definitely be internet-connected.

== Sharing of Internet by node-owners ==

Do we let the node-owners share their internet connection with the mesh? If so, how do we prioritize the traffic? Do we let the node-owners decide how much of the bandwidth they share? Do we let them set a data usage cap?

If the node-owners don't use the mesh router as their access point, then there is really no way we can tell how much bandwidth is being used by the node-owner. This means the limit on the mesh-node's internet usage will have to be a hard limit, instead of being able to take advantage of unused internet bandwidth.

=== Decision ===

We let the node-owners choose to share internet or not. We let them select a percentage of available bandwidth that the mesh can always use. Whether or not this is a hard limit will probably have to depend on whether or not they have another access point that they use (or if they ever use wired ethernet).

== Connecting isolated mesh nodes over the internet ==

It's possible to connect isolated segments of the mesh through the node-owner's internet connections. For layer2 mesh protocols at least, this requires a tunnel to one or more servers that act as mesh nodes on the internet. The mesh nodes could also attempt to directly connect to a few other mesh nodes, but that would require more complication such as NAT traversal.

=== Decision ===

I have set up tunneldigger from wlan-slovenia which uses L2TP tunnels for this. Some work is still needed in dealing with MTU correctly.

== Hiding node-owners source IP ==

If someone uses internet provided by the mesh to e.g. download the newest Game Of Thrones episode, and the ISP of some innocent node-owner receives a letter from the U.S. copyright mafia, then at the very least it would be a scary experience likely resulting in the node-owner taking their node offline. In order to provide some buffer we can tunnel all internet traffic through one or more servers or "exit nodes" owned by the mesh group.

=== Decision ===

We definitely want to hide source IPs of home Cable/DSL lines.

= Organizational structure =

== Formal organization || No centralized entity || Separation of organization and network ==

The people involved in running the mesh could establish a formal organization, such as a 501c3 or a LLC, or they could simply have a formal or informal agreement between each-other, e.g. something like a group peering agreement.

The third option is to have both: The network is its own thing and anyone can peer (possibly with the requirement of signing a peering agreement) but there is also a formal organization that provides and coordinates certain services, such as e.g. selling of pre-flashed firmwares, troubleshooting mesh problems, getting funds for extra internet bandwidth for the mesh, developing firmware, spreading the word, etc. In this case, the network and central organization should probably have separate names.

== Non-profit || For profit ==

If there is a central organization, it could be either a for-profit or a non-profit. There are many variations, but some of the most relevant are:

=== 501c3 ===

Positives: Tax-exempt status. Tax-deductibility of donations. Assurance that the organization will not e.g. be bought up Google.

Negatives: Limited political activity (but EFF is a 501c3, so it's not too bad). Structure contains innate hierarchy in the separation of board of directors and members. Still have to pay e.g. sales tax even if the organization has lost money over the year.

=== B-corp certified for-profit ===

Positives: Possibly more options for how to structure organization and how to operate. Yearly losses can be deducted from taxes owed. Ability for members to be shareholders.

Negatives: May seem less trustworthy to community. May be less trustworthy (can we ensure that the corporation can never be e.g. sold to Google?). No tax-deductible donations. No tax-exemption. Ability for members to be shareholders.

== Membership / peering requirements ==

If we have a central organization, who can be a member? If not, who can peer?

=== Membership ===

The minimum possible is that everyone can be a member just by applying online (possibly we could go even further and state that anyone who claims to be a member is a member).

Going up from that we have options such as:

*Your membership fee is hosting a node.
*Your membership signup fee is buying a node.
*Your membership fee is hosting a node and sharing internet.
*Your membership fee is a monthly dollar amount.
*Your membership requires some amount of work monthly or yearly.

And of course combinations of the above.

=== Peering requirements ===

For both meshes with and without a centralized organization, there can be a peering agreement that you must sign to become part of the mesh. It could be that the agreement is only between you and the people you connect to directly, or it could be that the agreement is between you and the mesh (and all the people who are connected to the mesh).

There is also the option to have no such agreement and simply have instructions for how to connect to the mesh and let everyone sort out how they want to use the mesh on their own.

== Decision ==

We are currently leaning towards a 501c3 with the network being a separate thing.

= Ownership of and access to infrastructure =

== Centrally owned || Distributed ownership ==

Is the hardware owned by the people who host the nodes or are they owned by the central organization.

Who's responsibility is it to pay for new nodes if they break?

Hybrid models are possible, e.g: People buy pre-flashed nodes from the local mesh organization and own their nodes, but they pay a small membership fee (or not), and basically get an unlimited warranty, where the mesh group will replace their router automatically if it stops working.

== Management of nodes ==

Who manages the nodes? In case of firmware updates, who has access to send them to the nodes? Do each individual node-owner have to approve each update? It could be default-approve but give them a notice and a time-frame to opt out of an update. Any decision of individuals to not accept updates from the mesh group could prove very problematic in case of major updates, e.g. changing of mesh routing protocol, but even if no such updates are to occur, the firmware will have to be very specifically designed around the limitation that updates to nodes are not guaranteed to ever occur, if we allow users to manage their own nodes.

== Decision ==

We haven't discussed this very much. I think we should let people own the nodes that they host and let the central organization manage the nodes unless the node-owner wants to manage their own node. We will have to have a clear strategy for who has access to privately owned nodes at any given time, and contracts/agreements about what they are allowed to do to them. We will have to make it very clear to the node-owners what letting us manage the nodes means (that, if obused, this power can be used to monitor their unencrypted traffic and phish ) and how we monitor and prevent abuse from the people in charge (though this is really no different from a normal ISP) [[User:Juul|Juul]] ([[User talk:Juul|talk]])

= Sensors / add-ons =

Most routers provide a 3.3 volt serial port that can be used to attach microcontrollers and all manner of sensors. Examples:

*Temperature, humiditiy, pressure
:Ultra-local weather stations.
*Seismic sensors
:See how an earthquake spreads.
*Air quality sensors
:How's the smog today?
*Bluetooth or ZigBee gateways
:Connect low-power devices to the mesh.

= Captive portal / splash page =

A splash page is a powerful way to tell people about the network and show them to e.g. a community portal, but it can be annoying and problematic for a lot of reasons. Here are some different solutions.

== Full captive portal ==

Blocking all traffic until the user clicks a button or logs in is super annoying and breaks a bunch of things, however, if the network has problems with abuse and wants all users to authenticate before use, then this could be necessary.

A really big problem for the common user is that it doesn't work with SSL.

== Block port 80 only ==

This would only show a captive portal on port 80 until the user clicks a button to continue or only for the first connection to port 80.

This is less annoying, but will still break many things and users may wonder why they've been surfing for a while (SSL sites) and then suddenly see the captive portal.

== Block captive portal detection only ==

Find out exactly how the captive portal detection mechanisms for different operating systems work and block this detection only, and only on the first attempt. This can be problematic, since e.g. iOS devices request a specific URL on http://www.apple.com and so required layer 7 inspection to match the packet. Another downside is that not all operating systems support captive portal detection. The following are known to support detection:

*Android v?
*iOS 4.3 (maybe earlier)
*Mac OS 10.8 (maybe earlier)
*Windows 8 (maybe earlier)

To our knowledge, Ubuntu and other popular GNU/Linux systems do not support detection.

== No captive portal ==

With no captive portal, many people will likely use the mesh and never learn about what it is. The SSID can still be a valid URL e.g. freepublicwifi.net and hopefully people who are curious will type it in.

== Decision ==

I will figure out how feasibile it is to block captive portal detection only. [[User:Juul|Juul]] ([[User talk:Juul|talk]])

= Network neutrality =

To what degree do we support and allow the blocking, mangling and prioritization of traffic?

At one extreme are things such as actively blocking certain types of traffic. This could be blocking bittorrent traffic, or netflix, or it could be disallowing any commercial use of the network at all.

= Logging =

To what degree does the mesh log or allow logging of traffic? If there are logs, are they centrally aggregated?

= Encryption =

Are links encrypted between nodes? We could decide to take drastic measure and only allow or only encourage point-to-point encrypted connections. We could only allow connections the internet using a VPN connection directly from the client to one of our exit nodes. These types of measures would drastically reduce the usability of the mesh, since they would require more than just connecting to a wifi access point.

= Authentication =

Some free public wifi networks require authentication (e.g. BART wifi). This makes it easier to deal with abuse but also raises privacy concerns. Authentication can be annoying, though implemented correctly it will be a one-time setup for each device.

== Decision ==

I feel like authentication would just make the network annoying and difficult to use. I say we just make it free and open. [[User:Juul|Juul]] ([[User talk:Juul|talk]])

= Abuse =

How does the mesh define and handle abuse?

Some examples of abuse definitions:

*Unintentionally running a DHCP server on the mesh.
*Using too much of the available bandwidth for too long.
*Using the mesh for illegal activities.
*Targeting other mesh users (e.g. phishing, password sniffing).
*Intentionally attempting to disrupt the functioning of the mesh.

Some of these can be blocked automatically. Some can be detected, and could land people on a captive portal that explains what they did wrong and how to fix it. Dealing with intentional abuse can be tricky if there is no authentication.

== Decision ==

We should block some things that definitely don't belong on the mesh, like rogue DHCP servers, and have an email address for contacting us about abuse. If there are valid use-cases, then moving all abusive MACs/IPs to a special VLAN with a captive portal and limited access could be a way to deal, but it may not be necessary at all. [[User:Juul|Juul]] ([[User talk:Juul|talk]])

= Support =

How much support will we provide and will it be provided by volunteers only or will we have paid support?

= Naming =

Decision: Still discussing. Several people seem to like a more generic and meaning name for the network, and less meaning less generic name for the organization.

== Meaning vs. non-meaning ==

Meaning example: RouteAround.net

Non-meaning: Project Gourami

== Generic vs. non-generic ==

Generic example: Free Public Wifi

Non-generic example: The People's Republic of Wifi

Mesh/Decisions

2013-08-23T06:15:20Z

Mitar: /* Mesh router as primary access point */

Each new community mesh project faces a set of decisions. This page contains a discussion of some of these decisions.

= Mesh router as primary access point =

Adding a WPA2-PSK encrypted virtal access point to the router would allow node-owners to use the mesh router either as their primary private access point, or as a secondary access point in places where their existing access point doesn't reach. This could be a nice added feature, but would require some more firmware work.

:The issue with that is that primary access points are often optimally in the center of the house, while mesh nodes should be on the edge of the house.

== Decision ==

We're already been working on this. The web admin interface will be fairly minimal, allowing changing the ssid and password of the private access point, as well as manual tcp/udp port forwarding. The nat-pmp and upnp daemons will also be installed and the gui will provide access to disable/enable them.

= Commercial || non-commercial =

It may seem obvious that a community mesh project should should be non-commercial in nature, however, all societies are different and the cost and availability of hardware and skilled volunteer labour will vary quite a bit. In some places it may be possible to run a mesh based solely on donations and volunteer efforts. In other places it may be necessary to find sustainable income models. Especially in less developed countries it may be more viable to use the mesh as a way for locals to become small business owners that maintain the network and sell access to the community at affordable rates.

Here are some options spanning the range of non-commercial to commercial:

*Donations, volunteers and grants only.
*Sale of merchandise.
*Sale of pre-flashed routers with profit margin.
*Ads for local businesses on splash page.
*Pay to get higher bandwidth (freemium).
*Limited data per day for free. Pay to get more.
*Free for low-income individuals only.
*Free for private individuals and non-profits only.
*Free for node-owners only.
*Free for node-owners and they node-owners can sell access.
*Everyone has to pay.

== Decision ==

I think we should stop right before the freemium model [[User:Juul|Juul]] ([[User talk:Juul|talk]]).

= Internet =

== Internet connected mesh || LAN only ==

One big decision is whether to provide internet access through the mesh. A non-internet-connected mesh would provide little popular appeal outside of disaster scenarios, and so would likely have to be designed specifically with disaster scenarios in mind, unless it is simply a platform for hackers and academics to use and learn from.

=== Decision ===

Our mesh will definitely be internet-connected.

== Sharing of Internet by node-owners ==

Do we let the node-owners share their internet connection with the mesh? If so, how do we prioritize the traffic? Do we let the node-owners decide how much of the bandwidth they share? Do we let them set a data usage cap?

If the node-owners don't use the mesh router as their access point, then there is really no way we can tell how much bandwidth is being used by the node-owner. This means the limit on the mesh-node's internet usage will have to be a hard limit, instead of being able to take advantage of unused internet bandwidth.

=== Decision ===

We let the node-owners choose to share internet or not. We let them select a percentage of available bandwidth that the mesh can always use. Whether or not this is a hard limit will probably have to depend on whether or not they have another access point that they use (or if they ever use wired ethernet).

== Connecting isolated mesh nodes over the internet ==

It's possible to connect isolated segments of the mesh through the node-owner's internet connections. For layer2 mesh protocols at least, this requires a tunnel to one or more servers that act as mesh nodes on the internet. The mesh nodes could also attempt to directly connect to a few other mesh nodes, but that would require more complication such as NAT traversal.

=== Decision ===

I have set up tunneldigger from wlan-slovenia which uses L2TP tunnels for this. Some work is still needed in dealing with MTU correctly.

== Hiding node-owners source IP ==

If someone uses internet provided by the mesh to e.g. download the newest Game Of Thrones episode, and the ISP of some innocent node-owner receives a letter from the U.S. copyright mafia, then at the very least it would be a scary experience likely resulting in the node-owner taking their node offline. In order to provide some buffer we can tunnel all internet traffic through one or more servers or "exit nodes" owned by the mesh group.

=== Decision ===

We definitely want to hide source IPs of home Cable/DSL lines.

= Organizational structure =

== Formal organization || No centralized entity || Separation of organization and network ==

The people involved in running the mesh could establish a formal organization, such as a 501c3 or a LLC, or they could simply have a formal or informal agreement between each-other, e.g. something like a group peering agreement.

The third option is to have both: The network is its own thing and anyone can peer (possibly with the requirement of signing a peering agreement) but there is also a formal organization that provides and coordinates certain services, such as e.g. selling of pre-flashed firmwares, troubleshooting mesh problems, getting funds for extra internet bandwidth for the mesh, developing firmware, spreading the word, etc. In this case, the network and central organization should probably have separate names.

== Non-profit || For profit ==

If there is a central organization, it could be either a for-profit or a non-profit. There are many variations, but some of the most relevant are:

=== 501c3 ===

Positives: Tax-exempt status. Tax-deductibility of donations. Assurance that the organization will not e.g. be bought up Google.

Negatives: Limited political activity (but EFF is a 501c3, so it's not too bad). Structure contains innate hierarchy in the separation of board of directors and members. Still have to pay e.g. sales tax even if the organization has lost money over the year.

=== B-corp certified for-profit ===

Positives: Possibly more options for how to structure organization and how to operate. Yearly losses can be deducted from taxes owed. Ability for members to be shareholders.

Negatives: May seem less trustworthy to community. May be less trustworthy (can we ensure that the corporation can never be e.g. sold to Google?). No tax-deductible donations. No tax-exemption. Ability for members to be shareholders.

== Membership / peering requirements ==

If we have a central organization, who can be a member? If not, who can peer?

=== Membership ===

The minimum possible is that everyone can be a member just by applying online (possibly we could go even further and state that anyone who claims to be a member is a member).

Going up from that we have options such as:

*Your membership fee is hosting a node.
*Your membership signup fee is buying a node.
*Your membership fee is hosting a node and sharing internet.
*Your membership fee is a monthly dollar amount.
*Your membership requires some amount of work monthly or yearly.

And of course combinations of the above.

=== Peering requirements ===

For both meshes with and without a centralized organization, there can be a peering agreement that you must sign to become part of the mesh. It could be that the agreement is only between you and the people you connect to directly, or it could be that the agreement is between you and the mesh (and all the people who are connected to the mesh).

There is also the option to have no such agreement and simply have instructions for how to connect to the mesh and let everyone sort out how they want to use the mesh on their own.

== Decision ==

We are currently leaning towards a 501c3 with the network being a separate thing.

= Ownership of and access to infrastructure =

== Centrally owned || Distributed ownership ==

Is the hardware owned by the people who host the nodes or are they owned by the central organization.

Who's responsibility is it to pay for new nodes if they break?

Hybrid models are possible, e.g: People buy pre-flashed nodes from the local mesh organization and own their nodes, but they pay a small membership fee (or not), and basically get an unlimited warranty, where the mesh group will replace their router automatically if it stops working.

== Management of nodes ==

Who manages the nodes? In case of firmware updates, who has access to send them to the nodes? Do each individual node-owner have to approve each update? It could be default-approve but give them a notice and a time-frame to opt out of an update. Any decision of individuals to not accept updates from the mesh group could prove very problematic in case of major updates, e.g. changing of mesh routing protocol, but even if no such updates are to occur, the firmware will have to be very specifically designed around the limitation that updates to nodes are not guaranteed to ever occur, if we allow users to manage their own nodes.

== Decision ==

We haven't discussed this very much. I think we should let people own the nodes that they host and let the central organization manage the nodes unless the node-owner wants to manage their own node. We will have to have a clear strategy for who has access to privately owned nodes at any given time, and contracts/agreements about what they are allowed to do to them. We will have to make it very clear to the node-owners what letting us manage the nodes means (that, if obused, this power can be used to monitor their unencrypted traffic and phish ) and how we monitor and prevent abuse from the people in charge (though this is really no different from a normal ISP) [[User:Juul|Juul]] ([[User talk:Juul|talk]])

= Sensors / add-ons =

Most routers provide a 3.3 volt serial port that can be used to attach microcontrollers and all manner of sensors. Examples:

*Temperature, humiditiy, pressure
:Ultra-local weather stations.
*Seismic sensors
:See how an earthquake spreads.
*Air quality sensors
:How's the smog today?
*Bluetooth or ZigBee gateways
:Connect low-power devices to the mesh.

= Captive portal / splash page =

A splash page is a powerful way to tell people about the network and show them to e.g. a community portal, but it can be annoying and problematic for a lot of reasons. Here are some different solutions.

== Full captive portal ==

Blocking all traffic until the user clicks a button or logs in is super annoying and breaks a bunch of things, however, if the network has problems with abuse and wants all users to authenticate before use, then this could be necessary.

A really big problem for the common user is that it doesn't work with SSL.

== Block port 80 only ==

This would only show a captive portal on port 80 until the user clicks a button to continue or only for the first connection to port 80.

This is less annoying, but will still break many things and users may wonder why they've been surfing for a while (SSL sites) and then suddenly see the captive portal.

== Block captive portal detection only ==

Find out exactly how the captive portal detection mechanisms for different operating systems work and block this detection only, and only on the first attempt. This can be problematic, since e.g. iOS devices request a specific URL on http://www.apple.com and so required layer 7 inspection to match the packet. Another downside is that not all operating systems support captive portal detection. The following are known to support detection:

*Android v?
*iOS 4.3 (maybe earlier)
*Mac OS 10.8 (maybe earlier)
*Windows 8 (maybe earlier)

To our knowledge, Ubuntu and other popular GNU/Linux systems do not support detection.

== No captive portal ==

With no captive portal, many people will likely use the mesh and never learn about what it is. The SSID can still be a valid URL e.g. freepublicwifi.net and hopefully people who are curious will type it in.

== Decision ==

I will figure out how feasibile it is to block captive portal detection only. [[User:Juul|Juul]] ([[User talk:Juul|talk]])

= Network neutrality =

To what degree do we support and allow the blocking, mangling and prioritization of traffic?

At one extreme are things such as actively blocking certain types of traffic. This could be blocking bittorrent traffic, or netflix, or it could be disallowing any commercial use of the network at all.

= Logging =

To what degree does the mesh log or allow logging of traffic? If there are logs, are they centrally aggregated?

= Encryption =

Are links encrypted between nodes? We could decide to take drastic measure and only allow or only encourage point-to-point encrypted connections. We could only allow connections the internet using a VPN connection directly from the client to one of our exit nodes. These types of measures would drastically reduce the usability of the mesh, since they would require more than just connecting to a wifi access point.

= Authentication =

Some free public wifi networks require authentication (e.g. BART wifi). This makes it easier to deal with abuse but also raises privacy concerns. Authentication can be annoying, though implemented correctly it will be a one-time setup for each device.

== Decision ==

I feel like authentication would just make the network annoying and difficult to use. I say we just make it free and open. [[User:Juul|Juul]] ([[User talk:Juul|talk]])

= Abuse =

How does the mesh define and handle abuse?

Some examples of abuse definitions:

*Unintentionally running a DHCP server on the mesh.
*Using too much of the available bandwidth for too long.
*Using the mesh for illegal activities.
*Targeting other mesh users (e.g. phishing, password sniffing).
*Intentionally attempting to disrupt the functioning of the mesh.

Some of these can be blocked automatically. Some can be detected, and could land people on a captive portal that explains what they did wrong and how to fix it. Dealing with intentional abuse can be tricky if there is no authentication.

== Decision ==

We should block some things that definitely don't belong on the mesh, like rogue DHCP servers, and have an email address for contacting us about abuse. If there are valid use-cases, then moving all abusive MACs/IPs to a special VLAN with a captive portal and limited access could be a way to deal, but it may not be necessary at all. [[User:Juul|Juul]] ([[User talk:Juul|talk]])

= Support =

How much support will we provide and will it be provided by volunteers only or will we have paid support?

= Naming =

Decision: Still discussing. Several people seem to like a more generic and meaning name for the network, and less meaning less generic name for the organization.

== Meaning vs. non-meaning ==

Meaning example: RouteAround.net

Non-meaning: Project Gourami

== Generic vs. non-generic ==

Generic example: Free Public Wifi

Non-generic example: The People's Republic of Wifi

Mesh/Firmware/Splash page

2013-08-23T06:10:40Z

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

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.

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.

= 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 [http://www.igate.com/iblog/index.php/android-v4-2-2-updates/ appears to have changed in 4.2.2].

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 ==

Request is made to "http://www.apple.com/library/test/success.html".

== 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 to the resulting IP:

<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, again to the www.apple.com IP:

<pre>
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>

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 [http://blog.superuser.com/2011/05/16/windows-7-network-awareness/ 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.

== 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:

<pre>
184.85.61.15 www.apple.com
</pre>

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:

<pre>
iptables -t nat -A PREROUTING -i bat0 -p tcp -d 184.85.61.15 --dport 80 -j REDIRECT --to-port 3128
</pre>

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:

<pre>
acl mesh src 10.0.0.0/8
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl Safe_ports port 80
acl CONNECT method CONNECT
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access allow localhost
http_access allow mesh
http_access deny all
http_port 3128 transparent
coredump_dir /var/spool/squid3
# program to run to re-write urls of incoming requests
url_rewrite_program /etc/squid3/rewrite.pl
# The number of redirector processes to spawn
url_rewrite_children 10
# Bypass rewrite if all rewrite processes are busy
url_rewrite_bypass on
# This is almost certainly not needed
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
</pre>

We should see if we can use the squid ''url_rewrite_access'' directive to ensure that the rewrite.pl program is only run for the specific queries that need rewriting.

The rewrite.pl program simply replies to the captive portal probe queries with the replies from a local apache server. Here is the code of /etc/squid3/rewrite.pl:

<pre>
#!/usr/bin/perl

$splash_response = "http://localhost/splash.html\n";

$|=1;
while (<>) {
chomp;
@line = split;
$url = $line[0];
if ($url =~ /^http:\/\/www\.apple\.com\/library\/test\/success\.html/) {

print $splash_response;

} elsif ($url =~ /^http:\/\/www\.apple\.com\/$/) {

print $splash_response;

} else {
print $url . "\n";
}
}
</pre>

For versions 3.4 of squid and above, the program should look like this instead (reference [http://www.squid-cache.org/Versions/v3/3.1/cfgman/url_rewrite_program.html v3.1 docs] and [http://www.squid-cache.org/Versions/v3/3.4/cfgman/url_rewrite_program.html v3.4 docs]):

<pre>
#!/usr/bin/perl

$splash_response = "OK rewrite-url=http://localhost/splash.html\n";

$|=1;
while (<>) {
chomp;
@line = split;
$url = $line[0];
if ($url =~ /^http:\/\/www\.apple\.com\/library\/test\/success\.html/) {

print $splash_response;

} elsif ($url =~ /^http:\/\/www\.apple\.com\/$/) {

print $splash_response;

} else {
print "ERR\n";
}
}
</pre>

An apache 2 with standard configuration is running and in /var/www/splash.html has the following file:

<pre>
<!DOCTYPE html>
<html lang="en">
<head>
<meta CHARSET=utf8mb4"utf-8">
<title>peopleswifi.org</title>
</head>
<body>
<h1>Welcome to People's Wifi</h1>
<p>
Click anywhere to continue!
</p>
</body>
</html>
</pre>

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?

:Will not clients have global IPs for whole mesh?

== 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:

# Periodically looks up the IP for the different servers
# Adds the result as an entry in /etc/hosts
# 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.

Mesh/Firmware/Splash page

2013-08-23T06:08:15Z

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

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.

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.

= 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 [http://www.igate.com/iblog/index.php/android-v4-2-2-updates/ appears to have changed in 4.2.2].

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 ==

Request is made to "http://www.apple.com/library/test/success.html".

== 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 to the resulting IP:

<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, again to the www.apple.com IP:

<pre>
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>

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 [http://blog.superuser.com/2011/05/16/windows-7-network-awareness/ 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.

== 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:

<pre>
184.85.61.15 www.apple.com
</pre>

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:

<pre>
iptables -t nat -A PREROUTING -i bat0 -p tcp -d 184.85.61.15 --dport 80 -j REDIRECT --to-port 3128
</pre>

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.

Squid 3.1 configuration:

<pre>
acl mesh src 10.0.0.0/8
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl Safe_ports port 80
acl CONNECT method CONNECT
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access allow localhost
http_access allow mesh
http_access deny all
http_port 3128 transparent
coredump_dir /var/spool/squid3
# program to run to re-write urls of incoming requests
url_rewrite_program /etc/squid3/rewrite.pl
# The number of redirector processes to spawn
url_rewrite_children 10
# Bypass rewrite if all rewrite processes are busy
url_rewrite_bypass on
# This is almost certainly not needed
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
</pre>

We should see if we can use the squid ''url_rewrite_access'' directive to ensure that the rewrite.pl program is only run for the specific queries that need rewriting.

The rewrite.pl program simply replies to the captive portal probe queries with the replies from a local apache server. Here is the code of /etc/squid3/rewrite.pl:

<pre>
#!/usr/bin/perl

$splash_response = "http://localhost/splash.html\n";

$|=1;
while (<>) {
chomp;
@line = split;
$url = $line[0];
if ($url =~ /^http:\/\/www\.apple\.com\/library\/test\/success\.html/) {

print $splash_response;

} elsif ($url =~ /^http:\/\/www\.apple\.com\/$/) {

print $splash_response;

} else {
print $url . "\n";
}
}
</pre>

For versions 3.4 of squid and above, the program should look like this instead (reference [http://www.squid-cache.org/Versions/v3/3.1/cfgman/url_rewrite_program.html v3.1 docs] and [http://www.squid-cache.org/Versions/v3/3.4/cfgman/url_rewrite_program.html v3.4 docs]):

<pre>
#!/usr/bin/perl

$splash_response = "OK rewrite-url=http://localhost/splash.html\n";

$|=1;
while (<>) {
chomp;
@line = split;
$url = $line[0];
if ($url =~ /^http:\/\/www\.apple\.com\/library\/test\/success\.html/) {

print $splash_response;

} elsif ($url =~ /^http:\/\/www\.apple\.com\/$/) {

print $splash_response;

} else {
print "ERR\n";
}
}
</pre>

An apache 2 with standard configuration is running and in /var/www/splash.html has the following file:

<pre>
<!DOCTYPE html>
<html lang="en">
<head>
<meta CHARSET=utf8mb4"utf-8">
<title>peopleswifi.org</title>
</head>
<body>
<h1>Welcome to People's Wifi</h1>
<p>
Click anywhere to continue!
</p>
</body>
</html>
</pre>

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?

== 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:

# Periodically looks up the IP for the different servers
# Adds the result as an entry in /etc/hosts
# 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.

Mesh/Firmware/Splash page

2013-08-23T06:06:20Z

Mitar: How Mac OS X check is made

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.

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.

= 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 [http://www.igate.com/iblog/index.php/android-v4-2-2-updates/ appears to have changed in 4.2.2].

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 ==

Request is made to "http://www.apple.com/library/test/success.html".

== 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 to the resulting IP:

<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, again to the www.apple.com IP:

<pre>
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>

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 [http://blog.superuser.com/2011/05/16/windows-7-network-awareness/ 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.

== 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:

<pre>
184.85.61.15 www.apple.com
</pre>

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.

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

<pre>
iptables -t nat -A PREROUTING -i bat0 -p tcp -d 184.85.61.15 --dport 80 -j REDIRECT --to-port 3128
</pre>

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.

Squid 3.1 configuration:

<pre>
acl mesh src 10.0.0.0/8
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl Safe_ports port 80
acl CONNECT method CONNECT
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access allow localhost
http_access allow mesh
http_access deny all
http_port 3128 transparent
coredump_dir /var/spool/squid3
# program to run to re-write urls of incoming requests
url_rewrite_program /etc/squid3/rewrite.pl
# The number of redirector processes to spawn
url_rewrite_children 10
# Bypass rewrite if all rewrite processes are busy
url_rewrite_bypass on
# This is almost certainly not needed
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
</pre>

We should see if we can use the squid ''url_rewrite_access'' directive to ensure that the rewrite.pl program is only run for the specific queries that need rewriting.

The rewrite.pl program simply replies to the captive portal probe queries with the replies from a local apache server. Here is the code of /etc/squid3/rewrite.pl:

<pre>
#!/usr/bin/perl

$splash_response = "http://localhost/splash.html\n";

$|=1;
while (<>) {
chomp;
@line = split;
$url = $line[0];
if ($url =~ /^http:\/\/www\.apple\.com\/library\/test\/success\.html/) {

print $splash_response;

} elsif ($url =~ /^http:\/\/www\.apple\.com\/$/) {

print $splash_response;

} else {
print $url . "\n";
}
}
</pre>

For versions 3.4 of squid and above, the program should look like this instead (reference [http://www.squid-cache.org/Versions/v3/3.1/cfgman/url_rewrite_program.html v3.1 docs] and [http://www.squid-cache.org/Versions/v3/3.4/cfgman/url_rewrite_program.html v3.4 docs]):

<pre>
#!/usr/bin/perl

$splash_response = "OK rewrite-url=http://localhost/splash.html\n";

$|=1;
while (<>) {
chomp;
@line = split;
$url = $line[0];
if ($url =~ /^http:\/\/www\.apple\.com\/library\/test\/success\.html/) {

print $splash_response;

} elsif ($url =~ /^http:\/\/www\.apple\.com\/$/) {

print $splash_response;

} else {
print "ERR\n";
}
}
</pre>

An apache 2 with standard configuration is running and in /var/www/splash.html has the following file:

<pre>
<!DOCTYPE html>
<html lang="en">
<head>
<meta CHARSET=utf8mb4"utf-8">
<title>peopleswifi.org</title>
</head>
<body>
<h1>Welcome to People's Wifi</h1>
<p>
Click anywhere to continue!
</p>
</body>
</html>
</pre>

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?

== 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:

# Periodically looks up the IP for the different servers
# Adds the result as an entry in /etc/hosts
# 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.

Mesh/Challenges

2013-08-23T06:01:57Z

Mitar: Comment about trust

'''Security'''
It's possible that malicious actors could install malicious software on mesh nodes they control such as [http://www.thoughtcrime.org/software/sslstrip/ sslstrip] via [https://github.com/RMerl/asuswrt-merlin/wiki/Entware Entware]. This would allow them to capture sensitive information from less savvy users.

Countermeasures might include regularly re-flashing nodes, not allowing nodes with changed root passwords, whitelisting applications?

It is a feature, not a bug. People should use end-to-end encryption with [https://www.eff.org/https-everywhere HTTPS Everywhere] and not relay on security of the network. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 19:58, 9 August 2013 (PDT)

Hm. Yes, though some questions remain: Are we putting people in a situation where their lack of education about security (no fault of their own) and lack of p2p encryption in their software tools (definitely no fault of their own) will put them at risk? Certainly the risk is no greater than the risk of connecting to any other unknown public wifi access point. However, may people expect a higher level of security from an "official" organization? Second, how can we mitigate the security concerns? I suggest the following approaches:

# Provide instructions on how to create secure tunnels to one of our exit nodes.
# Dedicate some resources to help develop better and easier tools for p2p crypto.
# Provide training for how to use p2p tools, both online and offline.

[[User:Juul|Juul]] ([[User talk:Juul|talk]]) 02:38, 13 August 2013 (PDT)

: Why would they trust our exit nodes? Why should they? And it is not necessary to teach them P2P crypto. Just end-to-end HTTPS is probably enough. So some browser extensions which assure that they use HTTPS and that they detect man-in-the-middle attacks.

Mesh/Firmware

2013-08-23T05:59:34Z

Mitar: /* Web admin interface */

Documentation for the sudo mesh firmware.

= Firmware generation features =

It should be easy to generate a new firmware with the following custom config:

*Location and ownership information.
:Contact info should be saved in a secure database but maybe not on the node itself?
*Randomly generated passwords set for wpa2, admin interface and ssh.
:The SSH password should be stored securely and a couple of stickers with the wpa2 and admin password should be printed for the user.
*Web interface
*ssh key generation

[http://meshkit.freifunk.net/ Freifunk Meshkit] is pretty neat!

[https://github.com/sudomesh/openwrt-firmware Sudomesh Firmware Github Repo]

Status:

= Stuff the firmware should have =

<big>Ranked from most to least important</big>

== InternetIsDownRedirect ==

When the node doesn't have internet access, it will redirect traffic to our mesh hosted [[Mesh/Firmware#Splash_page|Splash Page]].

We need something hosted on the node that can check if it has access to the internet. There's a bit of an issue where certain OSes won't connect to APs that don't have internet access. [[User:Juul|Juul]] will look into building a hack that properly manages these requests and redirects them to our node-hosted site.

InternetIsDownRedirect may also have to fake the expected captive portal detection responses? We need to figure out if android/iOS/Mac/Windows will connect to a wifi that does not have internet access.

Status: Implemented except for OS-specific captive portal requests.

== Splash page ==

We can capture OS specific probes in order to specifically redirect captive portal requests without affecting any other network traffic.

Features:

* Brief info on the mesh
* Link to our website?

Status:

[[User:Juul|Juul]] is in the process of implementing. He needs help with:
* Finding out captive portal request protocols for different OSes. He's covered Iphone, but needs information on other hardware
* We need UX/UI designers!
* Co-located server ($$)

== SSH server ==

The SSH server should be contactable from any interface. It should initially allow root access using a random generated password that the mesh group has and that the node owner can get and change if they are so inclined.

Status: Need Key generation feature. Otherwise Implemented in openwrt. See firmware generation above.

== BATMAN-adv ==

We'll use this as the mesh protocol.

Status: Implemented

== Multiple virtual network interfaces with their own SSIDs ==

*One ad-hock mode, unencrypted interface for the mesh nodes, e.g. sudomesh-backchannel
*One access point mode, unencrypted interface, for non-mesh devices to connect to the mesh, e.g. sudomesh.
*One access point mode, private interface with WPA2, for the people who own the nodes. [optional]

Traffic on the private interface should be completely separated from traffic on the non-private interfaces unless a client connected to the private interface requests an IP on the mesh.

Maybe the last one is optional because some people may not need that feature (they already have another access point and they want to keep it), but then how do people administrate the router?

In order to serve a secure web admin config to home users, we'll probably always serve 3 APs with one private WPA encrypted home link so that users can access their admin page.

Status: Implemented

== Web admin interface ==

Development information should be put in [[Mesh/Firmware/Web_Admin_Development|Web Admin Dev]]. This section can remain a wish-list.

A very simple one-page interface. It should do at least the following:

*Set location, name, description.
:But do you want to know the location centrally as well so that you can display nodes on the map? Will people enter this information twice or will you pull this information from nodes and then display on the map? Same for name and description. I would suggest that information is stored only once. In your case on the node itself. So probably you can then pull this information through nodewatcher scripts on nodes and then display nodes the map. Just really should not require people to enter or maintain information on two places because it desyncs very fast. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:20, 24 July 2013 (PDT)
*Let people select how much bandwidth they share.
:They always share 100% when they're not using the connection themselves.
::This works if people are using their private SSIDs on the node. But if the node is connected to their existing home network you might not easily configure such sharing. But maybe there is a way to detect that host network is free and can limits can be increased. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:20, 24 July 2013 (PDT)
:Do any ISPs have bandwidth caps around here? If so, let people specify how many MB to share per month.
:Maybe also a button for temporary increase limits (make them more restrictive) which are then after some time automatically restored.
*Let people change the admin password and the private wifi wpa2 password.
:Probably private SSID as well.
*Donate / "buy routers as presents for your friends"-button.
:One idea we had (but this is probably better for splash screen) is "adopt a node". Where a neighbor who uses a node a lot and depends on the node can donate some money to keep it up, but can then give a nickname or avatar to the node. Or something. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:20, 24 July 2013 (PDT)

Status: [[User:Maxb|Maxb]] is implementing. Git repo to come soon!

== Watchdog script ==

Node tests itself to see if it has connectivity, etc and resets itself if necessary.

OpenWrt has a hardware watchdog - we're not totally sure if it works. Anyone interested in doing some field testing??

Status: Needs people to hack on

== QoS / bandwidth shaping ==

To support letting node owners select how much bandwidth they share.

Status: [[User:Juul|Juul]] is hacking on.

== Internet VPN ==

The firmware should tunnel all Internet traffic from the mesh through a VPN server, unless this feature is specifically disabled.

This should not be a single VPN server, as that would be a single point of failure.

I suggest to use [http://wlan-si.net/blog/2012/10/29/tunneldigger-the-new-vpn-solution/ TunnelDigger]. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 21:50, 11 July 2013 (PDT)

[[Mesh/Network_topology|Network Topology]]

Status: [[User:Juul|Juul]] is implementing.

== Mesh VPN ==

If the mesh does not see any other nodes (and maybe even if it does?), and it has internet, then it should connect to another node or two over VPN. The easy solution is to use the same VPN servers as for the internet.

[[Mesh/Network_topology|Network Topology]]

Status: Implemented

== DHCP and batman-adv gateway mode ==

Nodes with an internet connection should run DHCP and [http://www.open-mesh.org/projects/batman-adv/wiki/Gateways batman-adv gateway mode]. We want to detect if the node can connect to a relay in which case it should configure as a batman-adv gateway server node. Otherwise they should configure as batman-adv gateway clients.

Staus: Needs hacking.

== Location and status reporting ==

Something that reports location and status when polled.

We developed this format and easy to publish status data from nodes for our [http://dev.wlan-si.net/wiki/Nodewatcher/NodeTelemetryProvider nodewatcher]. OpenWrt packages are [https://github.com/wlanslovenija/firmware-packages-opkg/tree/master/util here]. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:02, 11 July 2013 (PDT)

Nice to have:

*Status info: How many nodes is your node connected to. Is the internet link working.
*An "I don't know what my internet bandwidth is, test it for me"-function.
*Usage statistics (so people can see how many people they helped get internet!)
:This is the most important thing! [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:20, 24 July 2013 (PDT)
:You should add as well graphs on how much bandwidth was consumed by the node. This is useful when hosts see that their Internet is slow and believe that it was because of the node. Then they can check and see if it is really node (which often is not) or maybe just ISP has problems. Important because people like to attribute issues they have to nodes they don't understand. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:20, 24 July 2013 (PDT)
*Let people put up a bit of info about their node / house / co-op, on a simple web page that people can access only if they're connected to that node. It could be shown as part of the splash page.

Status: Waiting for nodewatcher project to finish

== IPv6 support ==

We should have IPv6 support, but I am ok with launching the mesh with only IPv4 and adding in IPv6 later. ([[User:Juul|Juul]] ([[User talk:Juul|talk]]))

= Stuff the firmware could have =

== DNS server ==

Each node could run its own (caching) DNS server. Doing this would allow people to access the admin interface for their node by going to e.g. http://me.mesh/ from the private interface.

== Caching web proxy ==

We could use [http://www.pps.univ-paris-diderot.fr/~jch/software/polipo/ Polipo] to improve people's browsing experience. Not sure how much cpu and memory this would need. We may not be able to run it on the routers with less than 32 MB ram (e.g. the Bullet 2 HPs).

== Block ads and tracking ==

We could use e.g. [http://www.pps.univ-paris-diderot.fr/~jch/software/polipo/ Polipo] with the sources from both adblock plus and ghostery. If we implement this, it should be an optional (default off) feature that you can select on the splash page, with a "remember this" that remembers either using a cookie or using your MAC (but then we'd be logging people's MAC addresses :-S). The block should probably be time-limited (e.g. 30 days).

= Compatible devices =

We should have ready-made images for:

*One really cheap indoor router (with 3G usb stick support?) like [http://wiki.openwrt.org/toh/tp-link/tl-wr703n TP-Link TL-WR703N]
*One nice high-speed indoor router (300 mbps 802.11n)
*Ubiquiti hardware. Most of the AirMAX stuff.

Mesh/MeshApps

2013-08-23T05:57:58Z

Mitar: /* Short List of Apps */

What sort of local apps would we like to integrate with the mesh? Such applications need to function on decentralized platforms, and ideally

=Short List of Apps=
*Bulletin Board / Hyperlocal Craigslist
*General Local Map (eg; http://tidepools.co)
**Food Mapping (eg; http://ediblecities.org/)
**Community Asset Mapping (eg; [http://thepyre.org/wiki/Mycelia Mycelia])
*Local Wiki (eg; http://oaklandwiki.org)
*Communication (eg; chat room, decentralized Twitter)
*Sensor Data (eg; Temperature, Seismic activity, air pollution)
*Location-aware social network (eg; http://dev.wlan-si.net/wiki/PiplMesh)

=Personas=
*Curator [ Individual who cares about data being right and available for the community ]
*Analyzer [ Wants to visualize data in context, overlays of data, how data changes ]
*Organizer/Activist [ wants to organize people around an issue, actionable outputs ]
*Consumer [ gets info from the system, but doesnâ€™t give back ]
*Broadcaster/Reporter [ radio, streams, news, users/organizations who push into the system a lot ]

=Use Cases=
==Leisure, Treasure Hunt, Animal Spotting, History / Science Plotting , Art/Design/Drawing, Mapping Secret/Weird stuff, Expression, Emotion==
*Jordan is a 36-year old scientist and queer activist. Occasionally, he travels north to a 'radical fairy' retreat center on over 80 acres of land. He's undertaking a project to map out the diverse and undocumented biology and wildlife in this sacred area. For this, he would like a tool that would enable him to automatically map the coordinates, attach a picture, and include a comment about what it is, as well as the ability to add to social media (Facebook & Twitter).

==Bulletin Board / Local Information sharing (jobs, events, etc) (people to people)==
*Martin is a 35-year old Latino man who runs a website for displaying new job postings and opportunities for diverse, underserved populations in Oakland (eg; youth, veterans, and formerly incarcerated). Martin would like to easily transpose this data onto a searchable map that he could populate daily with new opportunities and programs.

==Sensors: hardware-based [inputs & outputs]==
*Naomi is a Midweatern 30-year old environmental activist concerned about the impact of fracking on the quality of water in her county. She's organizing a campaign to encourage fellow concerned homeowners to monitor changes and contaminants in air and water quality, seismic activity, radiation, and other potential environmental impacts of fracking.

==Evidence Based Citizenship (crowdsourced data/reporting for an institution to solve, neighborhood to be aware of) (people to institutions)==
*Alyssa is a 35-year old African-American woman working for the city government. Passionate about diversifying and expanding civic participation, she's been participating with Open Oakland to make civic data more accessible. She's working on an educational campaign for creating short videos explaining civic issues and how local government works.

==Political Crisis Readiness (people to people, against institutions)==

=Contexts=
==Community Asset Mapping / Archiving==
*Kiara is a 34-year-old African-American community organizer and activist interested in mapping the various organizations addressing digital divide issues, as well as available resources such as public computers, free training and education, and free wifi spots.
*Molly is a 26 year old community organizer working on Oakland Wiki, a website editable by anyone and dedicated to everything Oakland. She recently announced the launch of an oral history project, the end product of which would ideally be mapped onto specific areas and landmarks.

==Community Hub (communications / sensors / input + output APIs )==
*Ali is a 28-year old Iraqi-American and works to catalyze community organizations in the Middle East. He is currently collecting stories from hackerspaces in the form of comics, as well as a 'Sister Spaces' project to partner hackerspaces for sharing insights and infrastructure challenges.
*Luke is a 33-year-old Australian data and open government geek. Among the mappable projects he's working on with Open Oakland are storm drains (the Adopt-A-Drain project), crime data, vacant and blighted properties, and organizations and resources addressing the digital divide.

==Organizing Tool (activists, security matters)==
*Mateo is a 32-year old Latino father living in the San Antonio neighborhood in Oakland, CA. He is interested in the capabilities of a mesh network for streaming Creative Commons-licensed content to his neighbors (possibly using an Asterisk server) and providing a means for connecting the community both digitally and physically through an online neighborhood bulletin board. He has a strong interest in reaching out to local businesses with an 'everybody wins' model of free wifi through a mesh, with a map-based splash page for communicating with others in the network.

==Crisis Readiness==
*Jen is a 30-year-old Asian-American technologist and community organizer in East Oakland. Passionate about DIY education and grassroots community-building, she's interested in mapping DIY communities as well as available resources for crisis readiness (such as relief centers, tools, food, water and shelter).
*Alexis is a 29-year old African-American technologist interested in the potential for mesh networking to expand internet access in underserved areas and creating a resilient communications network for crisis readiness. She is especially passionate about issues surrounding access to technology, and would like to see underserved communities participating in putting themselves on the map.

==Play, games, fun uses==

Mesh/Legal

2013-08-23T05:56:54Z

Mitar: Added about peering agreement

= Organization structure =

The mesh organization will be a 501(c)3 but will not own the mesh routers. The mesh hardware will be owned by the community that makes up the mesh.

= Exit nodes =

The exit nodes will be owned by the 501(c)3.

With regards to running exit nodes, Noisebridge, another 501(c)3, already runs a Tor exit node which should be legally similar to a mesh exit node.

Some links of interest:

*[https://www.noisebridge.net/wiki/Noisebridge_Tor NoiseTor wiki page]
*[http://tor.noisebridge.net/ NoiseTor website]
*[https://www.noisebridge.net/wiki/Tor_FAQ NoiseTor FAQ]
*[https://www.torproject.org/eff/tor-legal-faq.html Tor Project's Legal FAQ]
*[https://www.torproject.org/docs/faq-abuse.html.en Tor Project's Abuse FAQ]
*[https://www.torproject.org/eff/tor-dmca-response.html.en Tor Project's DMCA Response Template]
*[https://www.noisebridge.net/wiki/Noisebridge_Tor/FBI NoiseTor how to deal with the FBI]
*[https://www.torproject.org/eff/tor-legal-faq.html EFF's Tor legal FAQ]
*[https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs EFF's list of Good ISPs]

= Peering agreement =

If nodes are not owned by an organization, then some other way of agreement of how nodes should be operated should be made. One approach is to see each node as being peered with others and create agreements about how the rules the traffic should go over those links. Another is to extend such agreement into a license and also add rules about how the nodes themselves should behave.

*[http://interop.wlan-si.net/wiki/Legal/Licenses List of current existing agreements/licenses]

Mesh/Network topology

2013-08-23T05:48:35Z

Mitar: Comments about exit nodes.

= wifi topology =

We use 2.4 ghz 802.11g or 802.11n wifi gear with omni or semi-directional antennas to provide connectivity to devices such as laptops and smartphones at street level and within buildings. We are currently using mostly Ubiquiti Picostation 2 HP and Ubiquiti Bullet 2 HP routers for the outdoors. For the indoors we will likely use TP-Link TL-WR703N routers.

A high-speed wireless backbone for the mesh will be provided by 5 ghz 802.11n hardware, usually with point to point or point to multipoint connections mounted in high places such as on rooftops, flagpoles or antenna towers. We currently have a variety of Ubiquiti M5 routers such as airgrids, nanobridges, nanostations and a rocket.

All of the outdoor gear will be Power over Ethernet (PoE), requiring only a single cable for network and power connectivity.

= mesh topology =

All routers run the batman-adv mesh routing protocol. This is a layer 2 protocol (operating at the ethernet layer). The street-level 2.4 ghz routers should ideally be able to function in the event that e.g. an earthquake takes out all of the point to point and point to multipoint rooftop nodes (more alignment sensitive) and the mesh should remain functional, though it could become segmented.

The relays (see the internet connectivity section) also run batman-adv, so mesh traffic can flow from one part of the mesh, through the internet, through a relay, and into another part of the mesh if some of the mesh nodes are connected to the internet.

= internet connectivity =

There are four primary types of devices in the mesh:

*Clients: E.g. smart phones or laptops connected to the mesh.
:These do not run the meshing protocol.
*Mesh nodes: Wifi routers running OpenWRT.
:Some are rooftop backbone nodes and some are street-level or in-home nodes.
*Relays: Professionally hosted servers that relay mesh traffic over the internet.
:These run the meshing protocol. Mesh nodes are connected with L2TP tunnels to them.
*Exit nodes: Co-located servers that appear as the source IP for packets from mesh to internet.
:Both relays and exit nodes serve as a layer of protection between people sharing their internet connections with the mesh.

Some mesh routers will be hosted in homes that already have internet connections. If an internet connection is available, a mesh router will open an L2TP tunnel (using the tunneldigger software) to several relay nodes over the internet connection. A relay could be e.g. a VPS without a bandwidth cap. The relays all run batman-adv and function as part of the mesh through the L2TP tunnels to the mesh nodes. Each relay will have a connection to an exit nodes. The relays allow segments of the mesh that are not connected with wifi to be connected over the internet.

Each relay is connected to one exit node (tunnel type not yet decided). It does NAT (IP Masquerading) on traffic coming from the mesh and headed for the internet. All traffic coming from the mesh and going to the wider internet goes through an exit node. The source IP of data coming from the mesh thus appears as the IP of one of the exit nodes. This provides a layer of protection such that e.g. abuse complaints will be sent to the mesh organization instead of the individuals who donate some of their internet bandwidth to the mesh.
:Until network has an AS, only one exit node should be made and multiple relay nodes should connect to that exit node (Tunneldigger software can be reused for that). Otherwise clients can have issues when routing protocol decides to move from one exit node to another. But it is true that batman-adv has some protection against that, so that once a client decides for a gateway, it should be more or less sticky, no?
:It is important that nodes are connecting to relays and relays to exit nodes and that no IPs of those connecting to relays and exit nodes is stored.

Mesh/Firmware/Generating

2013-08-14T02:00:48Z

Mitar:

= wlan slovenija =

wlan slovenija has a firmware generator tool. Here are some links:

*[https://github.com/wlanslovenija/nodewatcher/blob/master/generator/config_generator.py config_generator.py: the core code for the generator]
*[https://github.com/wlanslovenija/nodewatcher/blob/master/generator/build_image.py build_image.py: the command line tool that uses config_generator.py]

Some relevant code from config_generator.py:

<pre>
buildString = 'make image FILES="../files" PROFILE="%s" PACKAGES="policy-routing olsrd uhttpd tc nodewatcher-core nodewatcher-clients ntpclient hostapd -ppp -ppp-mod-pppoe -wpad-mini kmod-l2tp kmod-l2tp-ip kmod-l2tp-eth tunneldigger wireless-tools qos-scripts %s"' % (profile_map[self.portLayout], pkgs)
os.chdir(path)
os.system(buildString)
</pre>

The whole ''nodewatcher'' system is in fact a web interface to the image generator (this is how it all started, historically, as a web interface + IP allocation, and then we added network monitoring, node telemetry and so on).

*[http://nodes.wlan-si.net/ live version]

= freifunk =

Freifunk has a web app called meshkit for generating images.

*[http://meshkit.freifunk.net/ live web app]
*[https://github.com/freifunk/meshkit source code]

Meshkit takes a strange approach. From the readme file:

<pre>
Meshkit itself just writes a uci config file and stores it in
/etc/config/meshkwizard in the resulting firmware image. The actual
configuration is done by meshwizard, which uses community profiles
and the settings from meshkit to configure the device at first boot after
the device has been flashed.
</pre>

While I understand why community profiles would be a good idea, it seems odd that the configuration would happen on the device. Why not generate all of the required configuration before generating the image? That way you save a bit of space and an extra reboot of the device.

After looking at the code, I am not inclined to use it. Lots of freifunk-specific stuff. Few comments. In the end, all it does that we really care about is take a few values from the web app, write some config files for openwrt and run "make image" with some parameters. It does have a system for queuing builds, which is nice. Honestly, I think we're going to be better off making our own system

Mesh/Challenges

2013-08-10T02:58:17Z

Mitar:

Mesh/Firmware

2013-07-25T05:21:19Z

Mitar: /* Web admin interface */

Mesh/Firmware

2013-07-25T05:20:37Z

Mitar: Some suggestions/comments for web interface

Mesh/Firmware

2013-07-12T05:02:34Z

Mitar: Added nodewatcher status publishing.

Mesh/Firmware

2013-07-12T04:50:18Z

Mitar: Added TunnelDigger link.

Mesh/Other mesh projects

2013-07-04T20:10:33Z

Mitar: Added Slovenia

The goal of this page is to list existing meshes, active mesh groups and failed community wireless groups so that we can learn from their failures and successes and possibly their source code and configuration parameters.

Project meshnet has a [https://wiki.projectmeshnet.org/List_of_Mesh_Locals list of wireless mesh projects].

Wikipedia has a [http://en.wikipedia.org/wiki/List_of_wireless_community_networks_by_region list of wireless community networks by region].

= Active meshes =

== [http://buenosaireslibre.org/ Buenos Aires Libre] - Argentina ==

*Location: Buenos Aires, Argentina
*Size: 200 active nodes (but 720 total)
*Protocol:
*[http://mapa.buenosaireslibre.org/ Map]
*Status: Likely in decline.
:Few of total nodes active. General meeting still being held (probably yearly), yet no-one signed up for general meeting attendance three days before it was to be held.

== [http://www.bogota-mesh.org/ Bogota Mesh] - Columbia ==

*Location: Bogota, Columbia
*Size: 30 nodes. Not sure how many active.
*Protocol: B.A.T.M.A.N. (not sure if -adv or -exp or normal).
*[http://www.bogota-mesh.org/en/node/36 Map]

== [http://ninux.org Ninux] - Italy ==

*Location: Italy. Many cities.
*Size: About 200 nodes.
*Protocol: OLSR
*[http://map.ninux.org/ Map]

== Freifunk - Germany ==

*Location: Germany. Several cities.
*Size: Over 600 nodes in Berlin and over 400 nodes in Leipzig [http://www.olsr.org/?q=about according to the OSLR about page].
*Protocol: Mostly OLSR, but some cities use batman-adv.
*Map: [http://map.berlin.freifunk.net/ Berlin]
*Note: Not one big mesh, but several meshes in several cities.

Freifunk is actually both an organization, a firmware and a whole set of meshes, some of them interlinked, mostly in Germany. We have a [[Mesh/Freifunk|whole page about the project]].

== AWMN - Greece ==

*Location: Athens, Greece
*Size: Over 2400 nodes (according to their map, mid-2013).
*Protocol: OLSR (according to [http://www.olsr.org/?q=about the OSLR about page].
*[http://wind.awmn.net/?page=nodes Map]]

== Funkfeuer - Austria ==

*Location: Austria. Several cities.
*Size: ?
*Map: [https://map.funkfeuer.at/wien/ Vienna]

== wlan slovenija - Slovenia ==

*Location: Slovenia
*Size: 200 active nodes
*Protocol: OLSR
*Map: [https://nodes.wlan-si.net/network/map/ Slovenia]
*[http://wlan-si.net/en/ Website]
*[http://dev.wlan-si.net/ Technology wiki]

= Community Wireless Projects (not mesh) =

== [http://www.myrtletown.net/wifi.php myrtletown.net] - California ==

*Location: Murtletown, California
*Size: 1 WRT54GS router with a 1 watt amplifier on a tall mast.
:Actually covers a good part of the tiny town!
*[http://www.myrtletown.net/pics/myrtletown_wifi_coverage_map_r2.jpg Map]

= Planned Meshes =

== [http://nightwing.lugro-mesh.org.ar/en/ LUGRo-Mesh] - Argentina ==

*Location: Rosario, Argentina
*Size: 0 nodes so far
*Protocol: B.A.T.M.A.N. Experimental (bmx)
*Firmware: [http://nightwing.lugro-mesh.org.ar/en/ Nightwing] their own distro.

= Active non-mesh community wireless projects =

== Guifi - Spain ==

*Location: Spain
*Size: Over 21,000 active nodes. Mostly in Barcelona.
*[http://guifi.net/en Website]
*Note: Not sure if this is a mesh, but it seems to be huge!
:Collaborating with [http://thefnf.org/ The Free Network Foundation] to establish guifi.us: ''A self-service and full-service network planning, provisioning, and funding tool''.

= Inactive / failed local networks =

== [http://en.wikipedia.org/wiki/Roofnet Roofnet] - Massachussets ==

*Location: MIT and surrounding area, Massachussets.
*Protocol: [http://en.wikipedia.org/wiki/ExOR_%28wireless_network_protocol%29 ExOR]
*Status: Website spews errors and was lasted updated in 2006.

Roofnet turned into Meraki which used to be awesome, but became less awesome and eventually was bought by Cisco.

== [http://www.netequality.org/ NetEquality] - Portland ==

*Location: Low-income housing communities in Portland.
*Protocol: Not a mesh.
*Status: May still be active, but front page lists a 2007 article as recent.

== [http://en.wikipedia.org/wiki/Champaign-Urbana_Community_Wireless_Network CUWiN] - Illinois ==

*Location: Champaign-Urbana, Illinois
*Status: Website down.
*Funding: Received ~$870,000 from 2003 to 2006

=== Funding overview ===

* December, 2003: Received a $200,000 grant from the [http://en.wikipedia.org/wiki/Open_Society_Institute Open Society Institute]
* July, 2004: Received a $50,000 grant from the [http://www.thresholdfoundation.org/ Threshold Foundation]
* December, 2005: Received $118,000 grant from the [http://en.wikipedia.org/wiki/Open_Society_Institute Open Society Institute]
* July, 2006: Received a $500,000 grant from the National Science Foundation

== Archive.org's SFLAN - San Francisco ==

*[http://archive.org/web/sflan.php Website]
*Note: Not 100% sure this is inactive.

== NoCat - Sebastopol, CA ==

''NoCat's goal is to bring you Infinite Bandwidth Everywhere for Free.''

*Last news article was posted in February 2006.
*Website went down some time in late 2012.
*[http://web.archive.org/web/20121110234219/http://nocat.net/ nocat.net on archive.org]
*Seems like it wasn't a mesh

One of the main organizers, Rob Flickenger, wrote the O'Reilly book [http://shop.oreilly.com/product/9780596002046.do Building Wireless Community Networks] (published 2001). We should find him and ask him why it failed. His website is http://hackerfriendly.com