Mesh/Decisions

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 implemented this. The web admin interface is fairly minimal, allowing changing the ssid and password of the private access point. We have solved the issue mentioned above (primary access point best located in center of house) by having optional extender-nodes. Node-owners can also just buy two nodes and put them in different locations.

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 Juul (talk). We are still discussing this.

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. It if wasn't then it would likely remain a curiosity for tech geeks and at best be useful in a disaster scenario unless someone can come up with a mesh service that's alluring enough to warrant disconnect from the internet and connecting to non-internet-enabled wifi (maybe really good pirate file sharing servers).

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) 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. 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. 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. 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