[Commotion-dev] Unifying Serval and Commotion Mesh

[Paul Gardner-Stephen]

Hello,

On Wed, Dec 19, 2012 at 7:42 AM, Hans of Guardian
<hans at guardianproject.info> wrote:
>
> On Dec 17, 2012, at 4:47 PM, Jeremy Lakeman wrote:
>
>> 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.
>>>
>>> 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?
>>>
>>
>> If the Commotion Android application broadcasts an intent when the
>> network is up, it would be fairly easy for Serval to start our daemon
>> and communicate on that interface.
>
> I think MeshTether will send one of the standard "wifi connected" broadcasts since it is not telling Android to disable the wifi first.  That's the biggest difference between the Serval and MeshTether approaches.  MethTether is aiming to provide transparent IP networking based on the mesh, while Serval turns off Android's awareness of the wifi and sets things up how it needs them to be. In any case, it would be easy to add custom broadcasts if that's needed.
>
> About approaches to merging the mesh parts, I think we need to first agree on common approaches, like:
>
> - make everything apparent to Android as possible (connected status, SSID, etc)

Agreed.

> - provide transparent TCP/IP networking (no special tricks needed to use it)

Agreed.
If we want to allow for large meshes, even with local reachability
then we need to keep the Birthday Paradox in mind, and allow a large
enough IP address space on the mesh.  Similarly, we want to avoid
10.0.0.0/8 and other popular blocks used by mobile telcos around the
world so that we don't end up with conflicting configurations.  For
example, if the mesh is 10.x.x.x and the cellular link is also
10.x.x.x, internet access breaks.  This is why we chose random
self-assignment in 28/7 (28.0.0.0 - 29.255.255.255) for the mesh, as
telcos don't use those (it is two consecutive DoD class A's), and it
is big enough that mobile devices in a mesh are very unlikely to hit
an IP address conflict (p<<0.5 for networks of O(5,000) nodes).

> - specific scripting technique for adhoc mode setups (edify or whatever)

Indeed. I suspect that we probably have the more mature offering on
that front, with our edify+detect script stuff, which you alude to
below.

> - etc.
>
> MeshTether is a bit messy in parts, but its working well on the devices it can get into adhoc mode.  That's the part that Serval has lots of goodies for: getting lots of devices into adhoc mode.

Indeed, so my feeling is that the best path is to grab our WiFi
detection/control/chipset support stuff out, and use that, with all
the Android awareness stuff you have already, and add possibly add an
extra intent for notifying that a device is in ad-hoc mode.

Some sort of API is also necessary to ask for a particular wifi mode,
abstracting it away from the built in messy and always changing
interfaces, especially for AP and ad-hoc mode which is not supported
off-the-shelf.  Access Point mode is really important for us (and I
think in time, for Commotion) for enabling asynchronous connectivity
among phones that we can't make do ad-hoc mode for what ever reason.

Paul.

> .hc
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/commotion-dev
>