WISP-in-a-box Way Forward

This is a draft of the spec for the WISP-in-a-box development. It is fairly up-to-date but may not be the latest version.

Overview

The entire WISP-in-a-box system consists of:

• A central dashboard, running on the gateway server, from which:
  • the network can be monitored and all node can be configured
  • pre-paid vouches can be administered
  • software running on the server (web & mail services, etc) can be administered
  • all functionality will work without upstream Internet access
• Mesh nodes which:
  • receive configuration updates from the central dashboard
  • run a captive portal that interacts with clients and authenticates against the gateway server
  • route themselves intelligently using BATMAN

Component Diagram

Illustration 1: WISP-in-a-box basic components

The basic setup is diagrammed to the right.

For the Village Telco project, many components are the same. There is some additional functionality that's desired, however, so the steup might look more like:

Illustration 2: Village Telco network, built on top of WISP-in-a-box mesh

This document is going to mainly focus on specifying the needs of the mesh & networking side of things, with an eye towards exactly how voice-related services will be integrated (but not an elaborate discussion of the technologies themselves).

Dashboard & Server

Existing Projects

The OrangeMesh and Open-Mesh dashboards provide almost exactly the functionality we require. However, they have a number of problems:

• Both dashboards require the nodes to be running ROBIN firmware to receive configuration updates. ROBIN, as it is now, only runs on Atheros-based devices, not Broadcom devices (like the Linksys WRT). Some semi-serious hacking will be required to add support for Broadcom devices into ROBIN, since right now it assumes the use of the Atheros-only MadWifi drivers.
• With an eye towards localization & modularity, the OrangeMesh sources aren't quite what we'd like them to be.

Because of these limitations, we may not want to use the OrangeMesh/Open-Mesh dashboard. We still want to imitate the same basic style of system, however, while adding some functionality to meet the additional needs of our dashboard (e.g. ability to administer vouchers and server services, things that the OrangeMesh/Open-Mesh dashboards don't cover).

Our Approach

We will start essentially from scratch on the dashboard, with the OrangeMesh dashboard as an example to work off of and borrow heavily from.

The dashboard we will design will be highly modular, with a high-level menu in which the user can select a module to work with. A module might be an existing software component or a new one we've written. In the case of Network Status and Network Configuration, we can use the Orangemesh/Openmesh/ROBIN setup as a reference, and where appropriate can adapt their code to suit our needs. Other tools to borrow from include Zeroshell for network QoS configuration. Essential modules include:

• Server Administration -- brings up Webmin
• Vouchers -- brings up phpMyPrepaid, our data billing control system
  • phpMyPrepaid additionally controls the CoovaChilli instances running on all routers, including the ability to restrict or permit free access to the rest of the mesh network
• Network Status -- new custom dashboard component with following features:

• A semi-detailed list of all the nodes in the mesh, including:
  • the node's IP and MAC addresses
  • the node's current status (simple up or down)
  • when they were last heard from (when an update from that node was last received)
• Basic network usage statistics, data taken from RADIUS:
  • Total bandwidth going out of the gateway in the last X amount of time
  • Heaviest users of the network to monitor abuse (further information on individual users is available already in phpMyPrepaid)
• Ability to test network throughput, either through:
  • Simple interface to run iperf between any two nodes, or:
  • Visual display of metrics & signal strengths of every link, data reported from clients' BATMAN daemons and network tools

• Network Configuration -- new custom dashboard component with following features (note this is designed to be minimal for ease of use):
  • Change SSID of mesh backhaul
  • Change channel of mesh backhaul
  • “Advanced” features:
    • push command to all nodes via SSH
    • Change QoS settings both:
      • On the server, for outgoing traffic going to the upstream connection
      • On the various nodes in the mesh, for intra-mesh network bandwidth management.
  • Other features? Open to discussion. Potentially:
    • Change basic firewall features of each node (particularly, can clients access each others' computers when connected to the same CoovaChilli instance)

Possible other modules include Asterisk and A2billing pages.

The dashboard will send out all configuration updates using a standardized API; any mesh node in the network will have to run a client implementing this API that receives configuration messages from the dashboard and makes the necessary changes to files on its system. The API will be just as modular as the dashboard, so if a user wants to only implement certain features (say, add billing to an existing network) she would only need to implement a client for the platform her nodes are running (or, ideally, there will already be a client for that platform). Through the dashboard the user could then disable the unwanted modules. The dashboard will only send out updates for the components that are enabled, and the client will only modify configuration files for the components it receives.

All of the components of the larger dashboard will be skinned in a unified CSS style, with the potential for branding built in.

Mesh Nodes

The mesh nodes themselves will run OpenWRT. Node software includes:

• Batman for routing
• CoovaChilli as a local captive portal
• Intra-mesh QoS software, configurable from the dashboard. Uncertain as to what tools exactly to use here.
• A client daemon modeled on the ROBIN scripts that receives updates from the dashboard and sends any necessary information back to the dashboard. The client daemon will have to be co-developed with the dashboard.
• In addition to configuration through the dashboard, we will include a minimal web interface for configuring each individual node. This interface will run on the nodes, and can be a stripped-down version of X-WRT's webif^2 or FFLuCI.

Task Breakdown

Once the specification is agreed upon work can begin. At that time further task breakdowns may be useful, but at a high level the expectation currently is:

1. Dashboard & first client development: Meraka
2. Minimal interface development: Inveneo
3. Potential further client development for other systems (such as those used in Village Telco): Inveneo