New America Foundation - Second Contractor Agreement “NAF2”

In September 2012, The Serval Project commenced a second round of work for the New America Foundation's Open Technology Institute to integrate and document the wireless mesh security mechanisms and an OpenBTS dialplan developed for the Commotion Wireless Project in the First Agreement.

Attachment A - Work Packages


1. Integration testing and remedial work

The VoMP channel driver for Asterisk developed under New America Foundation - First Contractor Agreement “NAF1” was tested using two OpenBTS units:

  1. a RangeNetworks 2110 Development Kit supplied to The Serval Project under the terms of the First Agreement,
  2. a RangeNetworks 5150 supplied to The Serval Project under the terms of the Second Agreement.

The integration tests are described in app_dna/ The remedial work was required to:

  • make VoMP codec negotiation explicitly use PCM codec
  • improve the OpenBTS sample Asterisk configuration
  • fix the DNA Helper script invocation
  • handle empty Serval subscriber names in DNA requests
  • improve “ringing” signalling via VoMP
  • resolve various issues raised by the Commotion Wireless integrators

2. Documentation of Serval DNA and integration with Commotion

A policy for technical documentation was developed to address the problem of Wiki content becoming out of date with respect to the source code, and to ensure that all technical instructions are included with the source code so that users attempting to build or configure the software can do so without depending on access to the Wiki web site.

The following technical documents were then produced:

Additionally, the following major Technology Roadmap entries were produced:

3. Attendance at trial deployment

The Serval Project performed trial deployments in early 2013 at 2013 and KiwiEx 2013 following agreement from NAF. 2013

The 2013 trial could not test with OpenBTS units because the conference was situated in a major metropolitan centre. Instead, the trial aimed to test the VoMP channel driver for Asterisk by setting up a PSTN gateway to a commercial VoIP provider in order to provide free VoMP calls to conventional phones for the duration of the conference.

In practice, the Wi-Fi coverage in the conference areas could not be used for VoMP calls, mostly because of congestion as described in the 2013 conference report, so the gateway was never used by conference attendees. Testing was limited to a few calls made from within range of the project's own Wi-Fi router outside conference hours. Despite this setback, the trial was valuable because it revealed the practical obstacles to operating a Mesh network using public infrastructure or in areas with Wi-Fi saturation. The 2013 conference report discusses this in more detail.

KiwiEx 2013

The KiwiEx 2013 field trial with New Zealand Red Cross did not directly test Commotion OpenBTS integration, but indirectly improved it by advancing development of the Serval Mesh app for Android, in particular Voice over Mesh Protocol (VoMP) and Rhizome. A main focus of the trial was the prototype Serval Mesh Extender, which could vastly increase the range between meshed Commotion OpenBTS units.

The trial was conducted using six Samsung Galaxy S2 GT-I9100 phones whose purchase was funded under the Second Agreement.

4. Serval DNA logging and field diagnosis

Experience had shown that many issues in the field either arose from incorrect configuration or required configuration changes to diagnose. Ongoing development was increasing the demand on the configuration system, whose minimal, ad hoc implementation was causing problems:

  • inconsistent approach to reporting missing or malformed options meant that log files could not always be relied upon for diagnosis;
  • no detection or reporting of unsupported options, so configuration typos were hard to spot;
  • configuration code was scattered throughout the source, so it was hard for developers to work holistically on the configuration schema;
  • there was little or no documentation;
  • there was no “schema view” command (built-in help);
  • there was no unified approach to typing or parsing, so new configuration options were always prone to new defects, buffer overflow errors, etc.;
  • automatic configuration re-load by the running daemon was not practical.

It was becoming plain that the existing configuration system would soon become the cause of degrading software quality and field diagnosis headaches. So a completely new configuration parser and schema definition were developed. It was then straightforward to improve the Serval DNA logging system to multiplex output to more than one kind of log at once, under control of configuration:

  1. a log file rotated and expired by time
  2. standard error
  3. on Android builds, eg, Serval Mesh (app for Android), the Android log

The new configuration system made it very easy to log the entire configuration at the start of every new (rotated) log file, so that every file carries a complete description of the operational context.

With automatic rotation and expiry of log files, it is now a short step to finish implementing Field diagnosis.

5. Resolution of pending NaCl issues

Following Dan Bernstein's recommendation, Serval DNA was upgraded to the newer “ref10” implementation of the NaCl crypto_sign component, with the following benefits:

  1. ref10 provides an API primitive to convert an elliptic curve private to a public key, resolving one of the main outstanding NaCl integration issues.
  2. ref10 is optimised for the ARM architecture, and reduced the mean signature verification time from 272ms to 13ms on an 800MHz ARM (Rock 500 handset).
  3. The new ref10 private key format made it possible to reduce the size of the Rhizome bundle key from 512 to 256 bits, which significantly reduced the overhead for storing and transmitting Rhizome manifests.

The Security Framework document was finalised ready for review by Dan Bernstein.

The lack of the -fPIC option in the NaCl Makefile remains an issue, so NaCl still cannot be built as a shared library on 64-bit Linux systems.

6. Road map for future development

The Technology Roadmap Wiki page has been developed. This required a complete overhaul of Wiki content and development of a Wiki information architecture in order to:

  • collect all descriptions of current or proposed technology into a single namespace
  • link to “technology” pages extensively throughout the Wiki (eg, from within this report) to avoid repetition
  • make the Wiki navigable and informative enough to welcome and orient new developers
  • ensure that all new content has a single, obvious location
  • make the Wiki a useful tool for reviewing the state of the Project and planning next steps.
content/activity/naf2.txt · Last modified: 14/11/2013 16:47 by Andrew Bettison