[Commotion-dev] Unifying Serval and Commotion Mesh

[Paul Gardner-Stephen]

Hi Josh,

On Tue, Dec 18, 2012 at 3:34 AM, Josh King <jking at chambana.net> wrote:
> Hi Paul,
>
> This is something that we've been thinking about recently here at OTI as
> well. I think it makes a lot of sense to standardize around SSIDs and
> BSSIDs. Additionally, I'm working on rewriting the way that the OpenWRT
> firmware handles connecting to the mesh as a standalone C daemon and
> library, something that I hope may eventually serve as a cross-platform
> way to manage configuration profiles and wireless connection issues in a
> generalized fashion.

I think there is merit in that.

> In the short term, I've been thinking too about how to make sure that
> the Commotion Android application and Serval can work together
> effectively on the same device. Would it make sense for Serval to make
> use of Meshtether to establish the wifi network if it's available, and
> for Meshtether to connect to the Serval application's instance of
> servald for encryption, if available?

Some variation on that makes a lot of sense.  Probably we should look
at what we have in Meshtether and Serval Mesh, and cherry pick the
best from each, so that we can support the most handsets, and then
fold it into one single app that does mesh on Android, and nothing
else.  We can then make use of that (and even bundle it inside) the
Commotion and Serval Mesh APKs.

We are already exposing some APIs on Android for using servald, and we
have wanted for a while to think about the right way to expand that
out, and allow servald to offer secure mesh communications for any app
on the phone (possibly with a SuperUser.apk style prompting the first
(or each) time an app wants to use the mesh).

Both of these would be great for us to find resources to work on and
really facilitate the kind of improved simplicity, interoperability
and de-duplication of effort and interfaces that I think will pay
dividends.

One of the things that might affect how we do that, is that with
support from NLnet Foundation we have begun prototyping non-WiFi mesh
options, e.g., UHF ISM band packet radio, that will be supported by
the Serval Mesh on a "Mesh Helper" device in future.

It would make sense to tie that closely with servald, since servald
will need to use these packet radio interfaces which will not be
exposed as an operating system network interface (we don't want ARP
and chatty 3G/4G designed applications cluttering the limited
bandwidth we can obtain).

Yet, it would make sense for all the mesh interfaces to be handled by
the one application, and to offer a unified interface to that, which
suggests it should be in whatever combined application we create for
handling mesh communications.

Perhaps what all this means is that the combined mesh application
should actually be where servald runs.  Then it is just the
user-facing services that end up in a separate app.

Of course, the mesh control and servald are the largest parts of the
Serval Mesh app right now, and so then it starts feeling like all the
Serval Mesh apk functionality should be in there, in which case
convergence would be logical by cherry picking from Meshtether into
the Serval Mesh apk, and changing the Serval Mesh wifi settings to
follow the Commotion scheme. Else the Serval Mesh user services
(telephony, rhizome etc) are accessed from a separate app, but that
feels like artificial separation, and doesn't any significant
advantages, at least as I think about it at 04.15h.

I am not totally settled on all this yet, and this is largely thinking
out loud, but it seems like there is a good potential solution space
that it makes sense to explore further.

Paul.

> On Sun 16 Dec 2012 09:07:38 PM EST, Paul Gardner-Stephen wrote:
>> Hi All,
>>
>> From a Serval Project perspective, we see much value in converging on
>> a single "standard" SSID (and ideally BSSID) for WiFi mesh networks
>> for Serval and Commotion.  The logical choice is almost certainly to
>> use whatever values that Commotion uses.
>>
>> In fact, what we would like to see in time is that Commotion and
>> Serval's Android ad-hoc WiFi mesh management software converge into a
>> single thing, and possible a single APK that contains all Commotion
>> and Serval functions, or possibly it will be two separate APKs --
>> there are arguments for and against.
>>
>> But back to the present...
>>
>> The BSSID/ad-hoc bug issues on Android phones remains a source of
>> intense pain (which is part of why we are working on a "mesh helper"
>> device that would basically be a cross between an OpenWRT router and
>> mobile phone, that would basically be pocket-sized battery-powered
>> WiFi adhoc+AP plus long-range UHF radio).
>>
>> So I am not sure that a final solution is possible now, but we are
>> thinking about our default SSID for the Serval Mesh 0.90 release we
>> are hoping to have out by Christmas, and we hope to continue the
>> conversation about converging this all as much as possible.
>>
>> Our feeling in the lab here is that until we have interoperation
>> sorted out, that we will probably default to a serval-specific SSID,
>> probably mesh.servalproject.org, so that it will point people to a
>> (yet to be populated) web page where they can learn more.  But for
>> 0.91 and later, we hope to make moves towards convergence.  Perhaps
>> having a short list of configured network names and patterns is the
>> next step, but this is all really thinking out loud for now.
>>
>> Paul.
>>
>> _______________________________________________
>> Commotion-dev mailing list
>> Commotion-dev at lists.chambana.net
>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>
> --
> Josh King
>
> "I am an Anarchist not because I believe Anarchism is the final goal,
> but because there is no such thing as a final goal." -Rudolf Rocker
>