[Commotion-dev] Unifying Serval and Commotion Mesh (Paul Gardner-Stephen)

stoker mistr.stoker at gmail.com
Sat Jan 5 00:36:58 UTC 2013


Thanks Eric for pulling SPAN into the conversation. I'm a bit late to
the party but thanks to Seamus I'm finally subscribed to the
commotion-dev mailing list.

SPAN is a framework for mesh network experimentation on the Android
platform (iOS support is also in the works). Don't be turned off by
the "experimentation" aspect - SPAN is quite functional. We like to
express that SPAN is constantly being advanced and we're very open to
new ideas.

Here's a high-level breakdown for those who aren't familiar with SPAN:

- We have an Manet Service and associated API that allows apps to turn
ad-hoc mode on and off, configure various network settings
programmatically and through a config file, query the network status
and routing information, and return a list of reachable peers. Also,
the device can be configured connect to traditional network
infrastructure via the cell chip or a secondary wireless network
adapter.

- We have a simple Manet Manager UI for configuring the network and
starting / stopping ad-hoc mode. We're working on allowing user to
share the app and config info by physically bumping phones (NFC).

- We have a simple mesh network visualizer app developed using
Processing for Android.

- We use standard Linux tools such as ifconfig, iwconfig, and iptables
to configure the wireless network adapter. As long as apps use the
right IP address they do not need to use the Manet Service API or be
modified in any way to make use of the ad-hoc network.

- Currently we support OLSR, but are not tied to any particular
routing protocol. We're interested in supporting reactive protocols to
cut down on network chatter. We like the idea of remaining as silent
as possible until you need to send data; however, complete silence
doesn't seem possible because at a minimum beacon frames will be sent
out and handled by the MAC layer.

- We're in the process of using tinc to create P2P VPN network
overlays on top of the mesh and using the openssl library to support a
variety of encryption algorithms.

- Public keys will be side-loaded or shared by physically bumping
phones with peers. Key pairs will also be generated on the device.
We'll support X.509 certs if users have a CA. The Manet Manager will
provide a convenient UI for sharing and managing keys and certs.

Here's a list of some of the things we want to stay away from:

- Being tied to a custom routing or mesh networking protocol. Custom
solutions often work very well and have their merits, but as a mesh
experimentation framework we'd like our protocols to be plug-and-play
if possible. Wouldn't it be great if there was a common API for
interacting with such protocols? It would be even better if they
worked transparently. That's why we're leaning towards a global device
proxy that intercepts all outgoing and incoming packets and sends them
to our Manet Service for mesh-related processing.

- Data interception and MITM attacks. The idea of sending your public
key over the open air without a pre-existing authentication mechanism
presents an opportunity for identify spoofing and a MITM attack.
That's why we plan on sharing keys via side-loading or a phone bump.
Also, broadcasting data packets makes it relatively simple to sniff
those packets without placing a malicious device in promiscuous mode
or monitor mode. We'd like to encapsulate full IP packets + headers in
VPN tunnel mode. Also, we'd like to encrypt the routing protocol
traffic itself to prevent malicious entities from manipulating the
network topology and perform DoS attacks.

Some things of note:

- SPAN provides a generic ad-hoc enabler - that is, if your device is
rooted, your wireless chipset driver module supports ad-hoc mode, and
your kernel supports wireless extensions (wext). Devices with Broadcom
chips work the best - about half the time the kernel or module code
needs to be slightly modified or built with new kernel options. It's
not our goal to customize a kernel for each Android device out there.
It would be great if there was a way to roll in the necessary kernel
modifications into CyanogenMod or the like, but the device-specific
nature of those customizations makes that relatively difficult. Also,
it seems that CyanogenMod's intention is to stay as "vanilla" as
possible and to focus kernel changes on performance and stability
improvements.

- We modified the pttdroid app. to get group voice chat working over
the mesh. The intent is to provide a simple replacement for
traditional push-to-talk (PTT) land mobile radios (LMRs) in a close /
moderate range environment. The app. is very simple - it's not
session-based and uses UDP, which works well in a mesh where people go
in and out of range at will. Using the app. you can see what other
peers are in the network, talk to them individually, create groups of
them, or passively listen for all incoming communications. The app.
doesn't support SIP or connect to a VOIP gateway.

Links:

Google group discussion forum: https://groups.google.com/forum/#!forum/spandev

Open source code: https://github.com/ProjectSPAN

- stoker



More information about the Commotion-dev mailing list