Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Spec

VIEWS: 0 PAGES: 7

									Requirements
OrangeMesh will:
   1. Provide internet connectivity to community groups.
   2. Integrate with the existing Open-Mesh Dashboard.
   3. Provide instructive end user documentation.
   4. Allow network owners to manage terms of service compliance and network usage.
   5. Prevent users from becoming locked in to a specific provider of dashboard services.

Secondary requirements are:
   1. Very simple and easy set-up for non-technical users.
   2. High system reliability, minimizing the need for troubleshooting.

Subsequent versions of the dashboard will:
   1. Facilitate communication between users so they can solve problems collectively.
   2. Allow users to update their documentation as solutions are devised.


Background
OrangeMesh is a software project to develop a wireless mesh network management tool for non-
technical users. OrangeMesh will make use of several existing open source tools in order to accomplish
its mission.

-   BATMAN (mesh routing protocol). Maintained by open-mesh.net. (open-mesh.net/batman)
-   ROBIN (mesh firmware). Maintained by Antonio Anselmi. (www.blogin.it)
-   Open-Mesh Dashboard (existing mesh network management tool). Maintained by Mike Burmeister-
    Brown of NetEquality. (www.open-mesh.com) Note: this is maintained separately from the
    BATMAN protocol and is a separate project; the similarity of name is coincidental.

Our project is most closely associated with the Open-Mesh dashboard. We are working closely with
Open-Mesh to implement new features and extend the existing dashboard in order to meet the needs
of our local client, Orange Networking. Our project will be contributed back to the Open-Mesh source
tree for the benefit of the rest of the community mesh networking community.

Underlying OrangeMesh is the RO.B.IN project, maintained by Antonio Anselmi (www.blogin.it). RO.B.IN
is an open source mesh firmware built on top of OpenWRT “Kamikaze”, a Linux-based operating system
for wireless routers. The mesh protocol we will support is B.A.T.M.A.N. (Better Approach to Mobile Ad-
Hoc Networking), the successor to the very popular OSLR mesh protocol used by community wireless
groups around the world. This is a very active open source project which we expect to improve
significantly over the coming years.


User Classes
Each OrangeMesh community consists of three main user classes:
    1. Visitor – Guests to the community who simply need internet access and do not have any long-
       term commitments to the maintenance of the network.

    2. Neighbors (User) – Non-technical

    3. Geeks (Administrator) – Community Technical Volunteer


User Scenarios
Vinny the Visitor. Vinny is in town for the weekend visiting his cousin Billy. After long hours of driving, he
finally arrives at his cousin’s house and decides to check his email. Billy’s not the most technically
inclined fellow, and does not have broadband internet access at his home. Vinny turns on his laptop,
notices the open wireless network called “OrangeMesh Community Wifi”, connects, and opens up his
browser to navigate to his webmail. He is greeted by the network’s splash screen, and is delighted by
the friendly, inviting page that welcomes him to the community and displays terms of use. He clicks the
big button at the bottom that says “Connect” and is forwarded to the webpage that he wants to see.



Nelly the Neighbor. Nelly works during the day and uses the computer during her downtime in the
evenings. Mostly she likes to send pictures to her sister, do some online banking and pay her bills, and
read up on her favorite hobby, live-action Connect Four. She’s a very generous person, and so she
shares her expensive broadband connection with her neighbors by hosting an OrangeMesh node in her
house. She doesn’t really know what the node does, but she is curious about the network, and
sometimes she logs into the dashboard just to see how many people are connected to the network and
click on the pretty widgets that represent nodes to look at the exciting AJAX drop-down effects. She
doesn’t use the dashboard very often, but she did register with the network as a neighbor so she could
have some control over what information about her is attached to her node.

Garth the Geek. Garth is a 17 year old high school student who narrowly avoided becoming disillusioned
by the meaninglessness of his suburban existence by getting involved with his community wireless
network. Garth is no networking professional, but he grew up with computers and is comfortable using
them. He’s the kid his teachers go to when they can’t figure out how to use the DVD player on the TV or
don’t know how to hook their laptop up to the projector. Garth is also on the Geek Team for the
OrangeMesh Community Network, and after coming home from school he gets an email from a
frustrated community member that their internet connection is very slow. He logs into the dashboard,
and access the Geek Tools to analyze the network. He notices that the number of hops to the gateway
for one part of the network is unusually high, and upon further investigation notices that the gateway in
that part of the neighborhood has been down for three hours. He clicks on the entry for the node to find
out the contact information for the node owner, and gives them a call. The node owner realizes that her
husband unplugged the node so he could plug in his new remote controlled foam dart launcher. After
chastising him, the node owner plugs in the node, and Garth verifies on the dashboard that the node is
back online and functioning properly.
Core Functionality
Network Administration Dashboard (Primary) – Graphical web-based interface to simplify community
based administration of Mesh network while enabling easy expansion and visualization of network
topology.

Simplified Deployment Process (Secondary) – Streamline the third party tools and configuration
processes needed to establish a Mesh Network into a unified configuration process that allows users
without advanced technical knowledge to set up a mesh network by presenting a series of wizards and
detailed tutorials.




OrangeMesh Features
Simplified Deployment Process
Motivation: The Open-mesh dashboard will be available in the next few weeks for anyone to install on
their own servers. However, the installation process is currently somewhat involved. We will simplify
this process so that non-technical users can get their server up and running as quickly as possible. To do
so we will build a setup script that will walk users through the process of setting up their own Open-
Mesh server.

Specification: A user will run an executable script that will open up a wizard to walk through the setup
process. The first screen of the wizard will explain to the user that they are about to setup the
dashboard server, and will outline the installation requirements: a working installation of the LAMP
stack. The wizard will provide a link to the XAMPP project as information for users who do not have
LAMP configured.

The actual “setup” process for the dashboard is quite simple, and involves little more than copying the
dashboard files into their appropriate location to be served by the Apache webserver. The setup script
will give a dialog box to navigate to location where the user has installed Apache, and will extract the
dashboard files to that location. The setup script will then prompt the user to for the name of their
network’s database, and will proceed to create a new database in MySQL. It will also create the
necessary tables in this database (nodes, network, and users). The script will modify the dashboard
script files to reflect the names of these tables.

This specification is not yet complete, because the scope of the problem will depend on the open-mesh
code. We need to deploy open-mesh ourselves first to see what needs improvement here.

Documentation for Non-Technical Users
Motivation: A comprehensive manual for the dashboard is essential to making the software useful to
non-technical users. Community members who are administering the network should not need to spend
hours studying the dashboard for it to be useful to them. Documentation should explain the
“symptoms” of common network issues and the significance of every alert feature. Further, it should be
well-integrated into the dashboard, so administrators can quickly get the help they need.
Just as important is educational network user documentation to enable users of the mesh to learn
about the technology they are using and as a result feel less intimidated by it. In doing so, they become
more able and more willing to solve their own problems without requiring the assistance of others,
decreasing the workload of the network administrators and thus reducing support costs.

Specification: The dashboard administrator manual should touch on every aspect of controlling the
dashboard and the network. A link to the manual will be at the bottom of each page, reading “What
does this page mean?” Dashboard administrators and users will be able to click on that link have a
popup describe what each item on that page means, including definitions and significance to the
network.

The educational user documentation will be available on the publicly accessible status page. Its purpose
will be to “help users help themselves” by providing solutions to common problems (network
connectivity issues, slow connections, etc) in a way that helps users understand the technology they are
using.

This documentation is an evolving specification and will change as we learn more about the issues faced
when setting up and maintaining a ROBIN mesh.

Migration between Remote and Local Dashboard Servers
Motivation: Users of the dashboard should have the freedom to choose from where they manage their
dashboard, be it a remotely hosted solution from NetEquality or their own locally hosted server.

Specification: Under the “Advanced” pane of the “Edit Network” screen, the administrator will be able
to export their information to a remote dashboard server, or enable their server to receive data from
remote dashboard servers. The first of these is “Export” functionality, while the second is “Import”.

To export the network information stored in the database, the administrator will have a dialog to enter
the IP address or hostname of the remote dashboard server. The information tip located to the right of
this dialog (See existing Open-Mesh configure network page) will remind administrators how to find this
information. It will also remind them that this operation will send all their data to a remote server and
will provide a link to more extensive documentation. It will finally remind them that the import
capability on the remote server must be enabled for the transfer to work properly (see below). After the
administrator puts the remote dashboard server’s information in, they will click “Export” and the export
function will begin. If the remote server does not have importing enabled (see below), the administrator
will receive a “failed transfer” error message. This message will also appear if the remote server is not
reachable. Otherwise, the administrator will be told that the transfer is in progress and will be notified
when the transfer is complete.

The Import functionality will be mostly transparent to the administrator. Due to the security risk of
allowing an arbitrary user to send large amounts of data to the dashboard, this functionality will be
disabled by default. The administrator must specifically enable Importing if he or she would like to
import data. It will revert to the off state after 1 hour. The administrator may turn on importing by
clicking the “Enable Import” checkbox in the advanced section of the network configuration page. When
they do so, the dashboard will accept imported data for one hour. They can disable this functionality by
Deselecting the checkbox.

Node Owner Information System
Motivation: The nodes in a network may be spread over a geographically disperse area, and will often
be housed inside the homes of community members. Network administrators will need access to these
nodes at certain points to perform maintenance and troubleshooting. In order to do this, the
administrators will need records of who owns each node, along with a way to contact them.

Secondly, in order to increase community involvement and more easily expand the network, community
members should be able to apply to become node owners. Allowing non-administrators this ability will
distribute the workload of initial setup and allow organic expansion down the road

Specification: This functionality has two components, one publicly accessible and the other privately
accessible.

The publicly accessible component will be two new items in the network status page, one entitled “Add
Nodes to Network” and the other “View My Nodes”. The user may click “Add Node” to bring up the
public apply to add nodes interface. This page will be identical to the “Add Node” interface given to
administrators. The user selects the location of his/her node on the map, and a dialog box appears
where the user has clicked. The user is prompted for the MAC address of the node, a node name, a node
description, the user’s name, email address, phone number, and physical address. The user will also be
required to fill in a CAPTCHA to prevent automation of the apply to node system (since this allows users
to directly write to the database, we must prevent malicious users from adding junk data to the
database). After verifying the a node with an identical MAC address has not already been added, the
new node will be added to the database, and its approval status will be set to “Pending” awaiting action
from the administrator. Then the user will receive a message saying “Node information sent to
administrator for approval” if the process was successful. If it was not (i.e., node already existed in
database) the user will receive an error message.

All fields are required fields. If the user does not enter the required information or fails the CAPTCHA,
then the user will receive an error message stating they did not fill in the form correctly; fields with
errors will be indicated. This error condition will also be triggered if they do not enter information in the
proper format (i.e., an invalid MAC address). If a user tries to add a node to the network that has already
been added, the user will receive a failure message stating that the node they tried to add already
existed.

The “View My Nodes” feature will prompt the user for their email address. The dashboard will search its
database for all nodes that match that email address and will display certain vital statistics about them:
Uptime/Downtime, Approval Status (Pending/Accepted/Rejected), and bandwidth usage. If the user
enters an email address that does not correspond to any nodes, they will receive an error message
stating that there are no nodes linked to the email address they entered. This concludes the publicly
accessible view of the node information system.
The privately accessible component is only available to administrators. They will have a new button in
the “Edit Network” section of the dashboard that reads “Manage Nodes”. This will link them to a new
page that has three main views: Accepted Nodes, Rejected/Removed Nodes, and Pending Nodes. All
these pages will show a listing of all nodes that have the corresponding status, including the following
information: Node Name, Trouble status (i.e., the color indicator that would appear in the Google Map;
red for problem, green for ok, etc), IP/MAC address, Description, and the Node Owner name, email,
phone, and address.

Administrators have two ways to change the approval status for a node. Each list item will have a button
that corresponds to a new status. These buttons will be context dependent, depending on what page
the administrator is currently viewing:

        Approved Nodes                   >       “Remove Node”
        Rejected/Removed Nodes           >       “Delete from Database”, “Approve Node”
        Pending Nodes                    >       “Approve Node”, ”Reject Node”

If no nodes match (i.e., there are no pending or rejected nodes), a message will display in place of the
node listing.

The email address for each node owner will be a clickable link. The entire table will be sortable by every
column, as well.

Beneath the node listing, the Administrator can also view all this information in the Google Map
interface. The node information will display in popups over each node, similar to what currently exists in
the network status page in Open-Mesh. Each node will be color coded based on its status.

Need from Mike: API for adding nodes to network. Code for sortable table.

Network User Management
Motivation: Mesh networks, by their nature, grow organically to spread internet access over a broad
area. While this is one of the primary advantages of a mesh, it can also be a legal liability for
organizations sponsoring such networks. These groups need a way to regulate access to their networks
and maintain accountability to their terms of service. In addition, network administrators should be
able to send important network information to their users, if their users opt for this information.

Specification: A ROBIN node has up to two network interfaces, which by default are configured to
broadcast an unencrypted “public” SSID and an encrypted “private” SSID. The dashboard will allow
network administrators to independently configure both of these networks.

Administrators currently have the ability to display terms of service on the splash screen, which is
completely customizable by the administrators. In addition, administrators can select whether they
would like to require users to provide their name and contact information as a requirement for
accepting the terms of service.
This “Access Control” page will also give administrators the option to provide an automated method for
users to obtain the private network key. If enabled, a line will be added to the main dashboard page
that reads, “Join this network!” This will link to a page that explains to network users that they are
applying for the network key to access the private network. Users are then requested to enter their
name, address, email, and phone number, and agree to the network terms of service. Upon submitting
this information, a request is sent to the administrator to approve the new user. Administrators can also
enable an “auto-accept” if desired. The administrator will have a pane in the “Edit Network” section
called “Pending Users” to review user information. When the user is approved, he/she will receive an
email with the network key, as well as a link to the dashboard and the support section.

Updated GUI
Motivation: Many of the features we are planning will require an overhaul of the open-mesh GUI. We
would like to clean up the open-mesh GUI to make the dashboard more distinct from the rest of the
site, as well as break the dashboard up into smaller pieces for ease of use.

Public Access XML Status Feed (a la Meraki)
Motivation: Meraki provides a public API for accessing public network information. This is useful to
developers and others who want to extend the functionality of the dashboard without having to worry
about the details of the dashboard’s implementation.

Specification: Accessible from a specific address (i.e., www.servername.com/networkname/api), the
dashboard will generate periodic XML status feeds that provide all the public network status information
in text form.

								
To top