Difference between revisions of "Mesh"

From Sudo Room
Jump to navigation Jump to search
Line 100: Line 100:
*[[Mesh/Commotion]]
*[[Mesh/Commotion]]


=Technical=
= Technical overview =
==Building a backbone of point-to-point line of sight rooftop wifi mesh nodes to bootstrap the reach of the network==
 
*The mesh right now has very few nodes that are directly connected (as opposed to connected over the Internet), which makes the usefulness of the mesh questionable in disaster and extreme censorship scenarios.
The mesh is made up mostly of wifi routers using Atheros chipsets and running [https://github.com/sudomesh/sudowrt-firmware our own firmware] based on [http://openwrt.org/ OpenWRT], [http://www.open-mesh.org/projects/batman-adv/wiki/ B.A.T.M.A.N. Advanced] and wlan slovenja's [https://github.com/sudomesh/tunneldigger tunneldigger]. We're using 2.4 GHz routers for indoor and street-level coverage and 5 GHz 802.11n routers for high-bandwidth and long distance roof to roof links. Most of our outdoor equipment is from Ubiquiti. We refer to the wifi routers as mesh nodes, or simply nodes.
*We've been focusing on finding a simple and inexpensive solution for point to point rooftop nodes in order to create a far reaching backbone of high-bandwidth interconnected nodes. Currently we're testing a solution using recycled small satellite dishes with cheap usb wifi adapters mounted and weatherproofed at the dish's point of focus. Inexpensive computers such as a raspberry pi can then, when hooked up to one or more of these nodes, connect rooftops more than a mile apart. Finding people willing to host rooftop equipment and others willing to donate unused satellite dishes has become another way we engage with the local community.
 
   
Node-owners can choose to connect the nodes to their existing LAN using ethernet. If they have Internet access, they can share a portion of it with the mesh. The amount of bandwidth shared is limited with 'tc'. It is chosen at node-configuration time and can be changed using the simple built-in web admin interface.
==Mesh coverage of local areas from connected nodes using powerful omnidirectional wifi equipment==
 
*510pen currently uses a variety of mesh routers from open-mesh.com. Some of them have good coverage, but they are all currently mounted indoors, which inhibits street coverage and mesh links between blocks.
== Wifi networks and IP assignment ==
*Better outdoor omnidirectional routers need to be purchased, tested and installed.
 
   
The nodes each run three wifi networks (three SSIDs on the same physical wifi interface):
==Low bandwidth disaster recovery mesh==
 
*The likeliest disaster scenario in the bay area is a major earthquake. Such an event is likely to disrupt many wifi nodes, and especially finely tuned point to point links.
* peoplesopen.net is an open access point. Most people will use the network by connecting to this.
*We're building a separate mesh using low-bandwidth, long range radio communication that will run something like a decentralized twitter, where short text messages can be shared and synchronized as radio links are available.
* pplsopen.net-node2node is an ad-hoc network that the nodes use to mesh with each other
*To implement this, we're using $12 off the shelf tv tuners that can be used as receive-only general-purpose digital radios. Transmission is stil being worked out, but the current idea is that receive-hardware is cheap enough that 2 gig bootable usb sticks, tv tuners and very simple home-made antennas can be distributed both before and after a disaster, and that these will allow people to set up local stations where updates about local resources such as shelters, food and power can be accessed, while stations capable of transmitting new messages will be fewer (possibly requiring more expensive hardware) but will announce their locations such that anyone can walk to a local transmit station if they want to send a message out on the mesh.
* A private wifi network is named by the node owner (or a name is generated) and uses WPA2-PSK.
 
If a node-owner is sharing internet, then the node will create a layer 2 (L2TP) tunnel to a VPN server on the Internet using tunneldigger. batman-adv will connect over this tunnel to other nodes on the mesh, so the mesh can route traffic over the internet if no wifi path to another node is available (e.g. other nodes are physically too far away). When people connect to the peoplesopen.net access point and try to access the Internet, the traffic will flow through the VPN, and the source IP of requests will appear to be the VPN with the sudo mesh organization listed as the abuse contact.
 
The nodes run DHCP servers and each have a /24 IPv4 subnet in the 10.0.0.0/8 range that is statically assigned by coordination between mesh groups and individuals hosting and administrating their own nodes on People's Open Network (currently only the sudo mesh organization). If a user connects to the peoplesopen.net access point on a node that isn't sharing internet, then batman-adv intercepts the DHCP request and forwards the request to another node on the network that has Internet connectivity (see the gw_mode option for batman-adv).
 
The private network does not limit bandwidth and provides access to both direct access to the Internet (if the node owner has hooked the node up to the Internet) and access to the mesh. Each node's private network runs on 172.30.0.0/16 and uses NAT between the private network and the mesh. It does not accept any new incoming connections from the mesh onto the 172.30.0.0/16 subnet.
 
== Node flashing and configuration ==
 
One of our medium-term goals is to be able to sell nodes on our website and minimize the amount of work required to re-flash/configure the nodes and provide documentation for the user. To facilitate this, our current process for new nodes is:
 
* A new node is flashed either automatically (using e.g. [https://github.com/sudomesh/ubiquiti-flasher ubiquiti-flasher] or [https://github.com/sudomesh/merakiflasher merakiflasher]) or manually with the [https://github.com/sudomesh/sudowrt-firmware sudowrt] firmware.
* The node is plugged into a server running our [https://github.com/sudomesh/node-configurator node-configurator] software.
* A sudo mesh volunteer pulls up https://nodeconf.local and uses a web interface to fill out contact info for the node owner, initial bandwidth sharing limits and private wifi SSID.
* The node-configurator generates SSH keys, SSH root password, web admin password and private wifi password, then it configures the node, saves the info in the [https://github.com/sudomesh/node-database node database] and shuts down the node.
* The node-configurator automatically [https://github.com/sudomesh/ql570 prints a sticker] containing some basic info including wifi and web admin passwords.
* The sudo mesh volunteer attaches the sticker to the nodes power supply and puts the node back in the box with a set of instructions for how to install and use the node.
* The node is shipped to the new node owner!
 
The node-configurator has both a [https://github.com/sudomesh/node-configurator server] and a [https://github.com/sudomesh/node-configurator-client client] component. The newly flashed sudowrt nodes automatically run the node-configurator client when they boot, and the client uses DNS-SD and mDNS to find node-configurator servers on the local network. The node then connects to the server using SSL and the server is ready to configure the node. The node-configurator server talks to Avahi using DBUS to announce itself using DNS-SD. The server is written in Python using Twisted and the client is written in Lua using luasec, and uses the [https://github.com/sudomesh/mdnssd-min mdnssd-min] utility to provide DNS-SD and mDNS.
 
The node-configurator includes a webserver and management web app. The web app talks to the server and connected nodes using websockets.
 
== Node management ==
 
All nodes set up by sudo mesh automatically allow root access using an SSH key held by a few trusted sudo mesh organizers. This is to allow us to update the firmware and troubleshoot network issues. We inform node-owners of this fact and tell them how to prevent sudo mesh from accessing their nodes, but also indicate that they should be ready to manage their own node if they choose to do this.
 
We don't yet have a solution for node monitoring but we're expecting to use the new version of wlan slovenja's nodewatcher software.
 
We don't yet have an automatic update solution in place, but it will work similarly to the node-configurator:
 
* Any number of node-updater servers announce themselves on the mesh and whether or not an update is available.
* The nodes run a future version of mdnssd-min as a daemon that keeps a currently list of node-updaters.
* Once every N hours +/- a random factor, if any node-updaters have updates available, all nodes connect to a randomly chosen node-updater and request an update.
* The node-updaters send the nodes an ipk file with the update and the nodes check the signature and install it if it's signed by a trusted authority.
 
== Minimum hardware specs ==
 
The sudowrt firmware minimally needs:
 
* Atheros chipset
* 32 MB ram
* 8 MB flash
**(or 4 MB flash and a USB port with a USB drive attached)
 
The firmware is currently only tested to be working on the older Atheros chipset (OpenWRT "atheros" architecture) but we're working on getting the newer Atheros chipsets working (OpenWRT "ar71xx" architecture).
 
We don't support less than 32 MB of ram because OpenWRT itself doesn't support less than 32 MB of ram as of the 12.09 "Attitude Adjustment" release.
 
We could probably squeeze the firmware into 4 MB flash, but we've decided it's not worth the trouble, and using jffs instead of squashfs simplifies some things.
 
== Internet bandwidth ==
 
We encourage node-owners to share their internet with the mesh, but on top of that we are talking to local non-profit organizations and ISPs about getting access to more cheap and free bandwidth.


=Social=
=Social=

Revision as of 21:01, 21 February 2014

Oct 25: Launched PeoplesOpen.net our public project page!  

We are a group of volunteers building a community mesh network in Oakland, California.

A mesh network is, in essence, free as in freedom alternative internet. Using low-cost routers (often donated or recycled) mounted on rooftops, we're currently building the backbone of the mesh throughout downtown Oakland, from West Oakland to the Fruitvale BART and beyond!

Mesh networks are awesome because they don't depend on the existing centralized Internet Service Providers to function. Though they can be connected to the Internet as we know it now, a mesh network provides a decentralized mode of communication with our local community. We view mesh networks as a means of connecting to our neighbors, supporting local businesses, and enabling grassroots community collaboration. In the event of disaster or government censorship, an active mesh network is a resilient means of communication and sharing of information.

 

Dishes in Action
Quick Links (see below for more details)
Documentation Technical Outreach Operations Research External Links
Install Instructions Overview FAQ Minutes User Research peoplesopen.net
Net Topology Hardware Blog To-Do's SF Bay Area network map
Presentations Power How to Help Legal Interviews code on github
History Security Wishlist Inventory Other Meshes DisasterRadio
Press Backup Website Meetings Software Tools BuildYourOwnInter.Net
Firmware Hosting Propaganda Funding Local Services
Mounting Decisions Self-Education
Next gen

 

 

Meetup Info

  • Join the Mailing List!
  • We have weekly hack nights on Thursdays, 7:30-10pm at Sudo Room. The first three Thursdays of the month are work nights - so come by and jump in! General meetings for discussion and planning are Last Thursdays of every month. We plan to have local focus groups in the near future - watch this space or join the mailing list for details.
  • Find us on IRC: #peoplesopen.net on Freenode IRC
  • We generally take meeting notes at: https://pad.riseup.net/p/sudomesh

Crowdfunding campaign

In July 2013, we successfully concluded our bootstrap crowdfunding campaign on WePay to buy the first 100 wifi routers for the mesh! Thanks to all who supported with a donation. See Mesh/Purchases for details on how much was raised, who contributed, and what we've procured thus far with the funds!

Here are some other ways you can help out:

  • Support us with a small weekly donation on Gittip.
  • Send bitcoins to our wallet address: 12RxU4DpLpdWcmEBn7Tj325CCXBwt5i9Hc
  • Come to our work meetings in Oakland! (listed above).
  • Form a project and/or a neighborhood working group to create new and locally-relevant ways of plugging into the mesh.

Mesh pages

  • Mesh/ToDos - Tangible To Dos! Add some on, take some on!
  • Mesh/Wishlist - List of hardware we'd love to experiment with!

Design

  • Map - of potential nodes.
  • Mesh/Website - Notes and documentation for the design of peoplesopen.net and meshthepla.net.
  • Mesh/MeshApps - Local applications to run on the mesh!
  • Mesh/Swag - Research on custom-printed t-shirts and other swag.
  • Mesh/Stickers - Sticker design
  • Ascii Art - for linux logins

Technical Documentation

Operational

Background Research

Firmwares / groups

Technical overview

The mesh is made up mostly of wifi routers using Atheros chipsets and running our own firmware based on OpenWRT, B.A.T.M.A.N. Advanced and wlan slovenja's tunneldigger. We're using 2.4 GHz routers for indoor and street-level coverage and 5 GHz 802.11n routers for high-bandwidth and long distance roof to roof links. Most of our outdoor equipment is from Ubiquiti. We refer to the wifi routers as mesh nodes, or simply nodes.

Node-owners can choose to connect the nodes to their existing LAN using ethernet. If they have Internet access, they can share a portion of it with the mesh. The amount of bandwidth shared is limited with 'tc'. It is chosen at node-configuration time and can be changed using the simple built-in web admin interface.

Wifi networks and IP assignment

The nodes each run three wifi networks (three SSIDs on the same physical wifi interface):

  • peoplesopen.net is an open access point. Most people will use the network by connecting to this.
  • pplsopen.net-node2node is an ad-hoc network that the nodes use to mesh with each other
  • A private wifi network is named by the node owner (or a name is generated) and uses WPA2-PSK.

If a node-owner is sharing internet, then the node will create a layer 2 (L2TP) tunnel to a VPN server on the Internet using tunneldigger. batman-adv will connect over this tunnel to other nodes on the mesh, so the mesh can route traffic over the internet if no wifi path to another node is available (e.g. other nodes are physically too far away). When people connect to the peoplesopen.net access point and try to access the Internet, the traffic will flow through the VPN, and the source IP of requests will appear to be the VPN with the sudo mesh organization listed as the abuse contact.

The nodes run DHCP servers and each have a /24 IPv4 subnet in the 10.0.0.0/8 range that is statically assigned by coordination between mesh groups and individuals hosting and administrating their own nodes on People's Open Network (currently only the sudo mesh organization). If a user connects to the peoplesopen.net access point on a node that isn't sharing internet, then batman-adv intercepts the DHCP request and forwards the request to another node on the network that has Internet connectivity (see the gw_mode option for batman-adv).

The private network does not limit bandwidth and provides access to both direct access to the Internet (if the node owner has hooked the node up to the Internet) and access to the mesh. Each node's private network runs on 172.30.0.0/16 and uses NAT between the private network and the mesh. It does not accept any new incoming connections from the mesh onto the 172.30.0.0/16 subnet.

Node flashing and configuration

One of our medium-term goals is to be able to sell nodes on our website and minimize the amount of work required to re-flash/configure the nodes and provide documentation for the user. To facilitate this, our current process for new nodes is:

  • A new node is flashed either automatically (using e.g. ubiquiti-flasher or merakiflasher) or manually with the sudowrt firmware.
  • The node is plugged into a server running our node-configurator software.
  • A sudo mesh volunteer pulls up https://nodeconf.local and uses a web interface to fill out contact info for the node owner, initial bandwidth sharing limits and private wifi SSID.
  • The node-configurator generates SSH keys, SSH root password, web admin password and private wifi password, then it configures the node, saves the info in the node database and shuts down the node.
  • The node-configurator automatically prints a sticker containing some basic info including wifi and web admin passwords.
  • The sudo mesh volunteer attaches the sticker to the nodes power supply and puts the node back in the box with a set of instructions for how to install and use the node.
  • The node is shipped to the new node owner!

The node-configurator has both a server and a client component. The newly flashed sudowrt nodes automatically run the node-configurator client when they boot, and the client uses DNS-SD and mDNS to find node-configurator servers on the local network. The node then connects to the server using SSL and the server is ready to configure the node. The node-configurator server talks to Avahi using DBUS to announce itself using DNS-SD. The server is written in Python using Twisted and the client is written in Lua using luasec, and uses the mdnssd-min utility to provide DNS-SD and mDNS.

The node-configurator includes a webserver and management web app. The web app talks to the server and connected nodes using websockets.

Node management

All nodes set up by sudo mesh automatically allow root access using an SSH key held by a few trusted sudo mesh organizers. This is to allow us to update the firmware and troubleshoot network issues. We inform node-owners of this fact and tell them how to prevent sudo mesh from accessing their nodes, but also indicate that they should be ready to manage their own node if they choose to do this.

We don't yet have a solution for node monitoring but we're expecting to use the new version of wlan slovenja's nodewatcher software.

We don't yet have an automatic update solution in place, but it will work similarly to the node-configurator:

  • Any number of node-updater servers announce themselves on the mesh and whether or not an update is available.
  • The nodes run a future version of mdnssd-min as a daemon that keeps a currently list of node-updaters.
  • Once every N hours +/- a random factor, if any node-updaters have updates available, all nodes connect to a randomly chosen node-updater and request an update.
  • The node-updaters send the nodes an ipk file with the update and the nodes check the signature and install it if it's signed by a trusted authority.

Minimum hardware specs

The sudowrt firmware minimally needs:

  • Atheros chipset
  • 32 MB ram
  • 8 MB flash
    • (or 4 MB flash and a USB port with a USB drive attached)

The firmware is currently only tested to be working on the older Atheros chipset (OpenWRT "atheros" architecture) but we're working on getting the newer Atheros chipsets working (OpenWRT "ar71xx" architecture).

We don't support less than 32 MB of ram because OpenWRT itself doesn't support less than 32 MB of ram as of the 12.09 "Attitude Adjustment" release.

We could probably squeeze the firmware into 4 MB flash, but we've decided it's not worth the trouble, and using jffs instead of squashfs simplifies some things.

Internet bandwidth

We encourage node-owners to share their internet with the mesh, but on top of that we are talking to local non-profit organizations and ISPs about getting access to more cheap and free bandwidth.

Social

Community-Based Participatory Action Research in the San Antonio district of Oakland

  • We are currently researching existing community organizations in the San Antonio neighborhood for potential collaboration, and have established relationships with (and set up mesh nodes for) three grassroots organizations in the San Antonio neighborhood: Liberating Ourselves Locally (LOL), a makerspace run by and for people of color; Sustaining Ourselves Locally (SOL), a community garden and food justice advocacy and education space; and Cycles of Change, a community bike repair, advocacy and education space. Moving forward, we intend to expand the mesh through reaching out to grassroots organizations and local businesses, our process of designing and deploying mesh services guided by the needs and desires of existing community actors.
  • The ethnographic research component of the project also involves interviewing local residents, designing and distributing community surveys, historical and political analysis, and asset mapping of existing and potential community resources.

Documentation of use cases and user stories

  • Articulating use cases for mesh networks involves the creation of user stories based on interviews with local residents and participatory engagement with existing community organizations and groups. The research process will be transparently documented on a research wiki, incorporating interview notes, meeting minutes, an annotated bibliography, written analysis and visual infographics (for an example, see Jenny's current research wiki here: http://wiki.tidepools.co).
  • This documentation is intended to support a model of open source technology design that is bottom-up in nature, rooted in the interests of those who would receive the greatest humanitarian benefit from the technology and participate intimately with the development process.

Illustrated instructables for adapting recycled/reused items for DIY hardware

  • A major focus of the project is to experiment with recycled and donated hardware for the purposes of designing mesh solutions at minimal cost. Experimentation with various firmwares (eg; Commotion, Freifunk, Byzantium) and protocols (eg; OLSRd, batman-adv, Babel) using off-the-shelf and upcycled hardware (eg; donated routers and satellite dishes) will be extensively documented. Well-designed instructables/comics will incorporate use cases, user stories, and DIY building processes in an effort to engage everyday folks to experiment with mesh technology in their local neighborhoods.

Getting municipal actors to support the mesh

  • Over time, we expect municipal actors (people working for local governments, libraries, schools, etc.) to see the mesh as an ally in efforts to bridge the digital divide. We are creating a short introduction to the project explaining why municipal actors should care about the mesh what they can do to support it.

Meeting Minutes

See the Minutes page.

Web Resources

Retrieved from "https://sudoroom.org/mediawiki/index.php?title=Mesh&oldid=7393"