[Commotion-dev] may day olsr testing report

[Hans-Christoph Steiner]

On May 2, 2012, at 6:56 PM, Jeremy Lakeman wrote:

> On Thu, May 3, 2012 at 5:09 AM, Hans-Christoph Steiner
> <hans at guardianproject.info> wrote:
>> 
>> http://guardianproject.info/2012/05/02/mobile-mesh-in-a-real-world-test/
>> 
>> Nathan, Mark, Lee, and I (all from Guardian) tried some OLSR mesh testing during the May Day protests and marches.  We were able to get 4 devices to associate and mesh together, but not without some trials and travails.  Two pairs of devices setup two separate BSSIDs, so were on separate networks.  We turned them all off, then associated  them one at a time, and then they all got onto the same BSSID and olsrd started doing its thing.  This made us think that we should just use a hard-coded BSSID in the setup, with a preference to allow standard ad-hoc association to find a BSSID.
>> 
>> Next we tried to use some services.  We were going to try running a cryptocat session, but the phone that was running cryptocat via a Lil' Debi Debian install was having trouble staying connected to the mesh.  Next we tried a serverless direct SIP call using CSIPSimple.
>> 
>> CSIPSimple uses the Android Java API to determine if the device is online.  The current approach to configuring the ad-hoc mode used by Android-Wifi-Tether-based apps including Serval and Barnacle-based apps including OLSR-Mesh-Tether disables the wifi via the Android Java API, then configures ad-hoc mode using command line tools.  This means that Android believe that the wifi is off, and when apps query the network status via the normal Android API, Android will tell it what it believes: there is no network connection.
>> 
>> This works in Serval because Serval is a self-contained system with its own SIP client and server, etc.  This does not work for situations where we want to provide generic IP service using OLSR mesh on Android phones.  I'm going to try to see if I can get the ad-hoc setup to work while making Android believe that the wifi is an and associated with infrastructure-mode network.
> 
> Yes, we had similar issues with SipDroid connecting to localhost or
> choosing codec's believing there was no available bandwidth.
> But not for much longer, we've dropped asterisk and sipdroid now in a
> development branch and have started to replace them.
> Yes, we have a big "Not Invented Here" complex. But we found a number
> of reasons not to use SIP's tcp session protocol and we needed
> something that would be easier for us to port in future.
> 
>> Also, in the process of setting up the mesh while mixing in a crowd and walking with a crowd down the street we realized two key things: 1) the setup process should be tolerant of frequent interruptions, and 2) it should be as easy as possible for people to give the mesh app itself from one phone to another.  #1 is in the scope of our current Commotion work and we will focus on making a UI that clearly shows its status and lets the user continue where they left off.  #2 is outside of the scope of our Commotion work, but Guardian Project will be working directly on that issue as part of a separate project, so we'll try to keep everyone informed on our progress with that.
> 
> 1) Fire a "share" intent with your own apk path. You can get this from
> your own package info. The user can choose bluetooth to transfer the
> file to another phone. Or you can look through the list of results to
> find bluetooth yourself. Though not all phones have the proper
> bluetooth stack to receive a file without additional software.
> Samsungs work at least.
> 
> 2) put the phone into hotspot mode and start a web server, again you
> can find the path to your own apk and serve a copy of it.
> 
> Serval does both, in the latest version.


Right, I remember now, that seemed to work pretty well.  I'll take a look and try to incorporate this into the OLSRMeshTether app.  The promise of Bluetooth is great, unfortunately it varies so much how its implemented that its hard to deliver on that promise on all devices.

.hc