Mobile mesh in a real world test

Nathan, Mark, Lee, and I 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.

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. We’ll be working on #1 as part of our Commotion work and we will focus on making a UI that clearly shows its status and lets the user continue where they left off. We will be working directly on #2 as part of a separate project, so we’ll try to keep everyone informed on our progress with that.

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.

9 comments for “Mobile mesh in a real world test

  1. sam
    2012/05/06 at 10:20 am

    Regarding 2)

    I had also been thinking about this.

    I am interested in running Pirate box on my phone at protests
    http://fun2code-blog.blogspot.co.uk/2011/12/piratebox-on-android.html

    I will then use that to distribute various .apk files amongst the crowd like your obscuracam one. If the mesh .apk files are also distributed the potential for a ‘viral’ network exists. One that spreads peer to peer amongst a crowd and facilitates communications amongst the crowd.

    • hans
      2012/05/08 at 11:06 pm

      Yeah, distribution of apps is a key issue to solve. Please keep us posted on your progress. I’m not sure that the Pirate Box approach can be made easy enough for the use cases that we are thinking about. The old Palm Pilot app beaming feature is really what we are trying to do. Anyone with a Palm could receive an app from any other Palm.

      This is somewhat possible with Bluetooth, but many devices will still have to go thru the peering process before they can transfer the app. So we’ve been discussing making a tiny Bluetooth beaming app. So if someone has a very slow internet connection, they could get teh tiny beamer, then get any app from anyone else who has the beamer app.

  2. 2012/05/15 at 2:41 am

    re: fixed BSSID – yes!! we do the same at FF. If you use fixed BSSIDs for different channels, then they won’t accidentally merge to the same channel.
    Usually you want to do that to create a multi-channel mesh

    • hans
      2012/05/15 at 10:10 am

      We’re throwing around ideas of how to generate that fixed BSSID. Jeremy of the Serval Project mentioned using a hash generated from the SSID, perhaps that should be a hash generated from the SSID and channel together.

    • renanto
      2012/06/24 at 2:12 am

      how do you get fixed BSSID? i’m implementing batman-adv on android, but still have no success on fixed bssid.
      thanks for advice or clue.

      i’m sorry if my english is bad

      • hans
        2012/06/24 at 4:31 pm

        You can set the BSSID with utilities like iwconfig, which I believe work by writing to /proc or maybe an ioctl() call. For the Commotion Mesh Tether app, we are using a custom utility called wifi that we inherited from the Barnacle Wifi Tether app that we started with.

        • Rick
          2015/03/23 at 12:38 pm

          I am trying to install Commotion Wireless on my 4.4 Android tablets, it did not work. Do you have any clues?

          • Hans-Christoph Steiner
            2015/03/24 at 12:21 pm

            Unfortunately, Google removed support for WiFi adhoc mode starting in Android 4.0. So you can only use Cyanogen and other Android ROMs that support adhoc mode with Commotion or any other wifi mesh.

  3. mki
    2014/02/22 at 6:13 pm

    tanks

Leave a Reply

Your email address will not be published. Required fields are marked *