[Commotion-dev] Unifying Serval and Commotion Mesh

[Hans of Guardian]

On Dec 19, 2012, at 7:47 AM, Dan Staples wrote:

> On 12/18/2012 09:19 PM, Paul Gardner-Stephen wrote:
>> 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.
> 

> Paul,
> 
> I have no idea how well supported it is in android, but would using IPv6
> for the mesh be better for avoiding address collision? The private
> address space for IPv6 is undoubtedly large enough to avoid address
> collision with any significant probability.
> 
> And just as a note, Commotion uses the 5.0.0.0/8 block for mesh
> addresses. However, I'm not sure what this particular subnet was chosen.
> 
> Dan

I think that is one among many good reasons to use IPv6 for the meshes.  IPv6 support on Android should be fine, but I haven't tried it. Other good reasons are:

* meshes can use addresses spaces that don't violate allocation rules (i.e. routing non-routable segments, "borrowing" allocated segments, etc.)

* IPv6 is much less widely known and understood, so if we can get it working solidly, that puts attackers at a potential disadvantage.

.hc