[Commotion-dev] may day olsr testing report

Jeremy Lakeman Jeremy.Lakeman at gmail.com
Wed May 2 22:56:21 UTC 2012


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.

> Another idea we discussed was how to have a "strength meter" for mesh, like the GSM or wifi bars.  We talked about taking a tally of how many first hop connections there are, the total connections, and the total willingness of all of the first hop connections.
>
> .hc
>
>
>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/commotion-dev
>



More information about the Commotion-dev mailing list