Mesh/User Guide

Revision as of 00:38, 18 July 2014 by Jwentwistle (talk | contribs) (created the page with main page details)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

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 working on the older Atheros chipset (OpenWRT "atheros" architecture) as well as the newer Atheros chipsets (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.

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.

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.

Getting municipalities to support the network

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