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.