Serval Mesh 0.90 Release Candidate 1 is Out

The past year and a half we have put a large amount of effort into rebuilding the Serval Mesh application from the inside out, to include end-to-end encryption, integrated short-messaging and resilient file sharing, all made much, much more useful by a completely overhauled user interface.

Therefore it is with great pleasure that I announce our first release candidate for version 0.90 of the Serval Mesh.

This has only been possible due to the outstanding efforts, including during some difficult times, of our core team (in alphabetic order): Andrew Bettison, Romana Challans, Jeremy Lakeman and Corey Wallis.

To get an idea of the extent of changes, take a look at the release notes and related documents. Changes include:

If you have used version 0.08, you will notice these changes:

• A completely redesigned human interface.
• A much smaller APK; faster to download and install.
• No need for third-party apps like SMSDroid or WebSMS.

The main screen now presents nine buttons:

• Call to make voice calls
• Messages to compose and view messages
• Contacts to discover nearby phones on the Mesh and show your Contact List
• Maps calls up the Serval Maps interface (if installed)
• Share files to send files via the Rhizome file-distribution system, list and view received files, see how much storage you are using
• Share Us to give the Serval Mesh software to other users with compatible Android devices
• Settings to adjust settings (see below)
• Switch Off(On) to stop or start Serval Mesh
• Help for instructions and information

The help system is more detailed and complete:

• Guide To Interface explains the buttons on the main screen
• Accounts & Contacts explains how Serval Mesh identifies you and other users to each other
• Licence is the full text of the software licence
• Serval Security describes Serval's security features, Android permissions used, and the Privacy Policy
• About introduces the Serval Project and leads to the Donate button
• Quick Links contains some useful links for further reading
• Serval Version is the full text of these release notes

The Settings menu has been overhauled:

• Wifi Settings lets you examine and change Wi-Fi settings
• Accounts Management lets you change your Serval Mesh phone number and name
• View Logs shows a log of recent software activity
• Redetect Wifi redetects the device's Wi-Fi chipset

There have been enormous changes under the hood:

• The foundations of the Serval Security Framework are now in place. Elliptic curve cryptography is used for identifying, protecting and authenticating subscribers and mesh network traffic.
• All Serval-to-Serval traffic (except Rhizome transfers) is now encapsulated in Serval's new, secure Mesh Datagram Protocol, implemented as an overlay network on standard IP over Wi-Fi.
• The original Java implementation of the Rhizome file sharing system has been superseded by a new implementation in C within the serval-dna component, using SQLite as the local storage engine.
• Voice calls are now carried over the mesh using Serval's own Voice over Mesh Protocol, which has been designed to replace SIPand RTP. As a result, call quality and latency have improved.
• MeshMS (Serval's SMS-like service) now uses Rhizome as its transport.
• Improved stability and responsiveness.

Version 0.90 is still considered experimental software, and there are a number of features and improvements that we intend to implement in releases between versions 0.90 and 1.00.

What we need now is for people to download and test this release candidate, and report any issues they encounter.

For more information, visit the Serval wiki page for this release candidate.

Update: see a video of us using 0.90RC1 here.

Rhizome over MDP

The Serval Mesh uses our own overlay network, rather than relying solely on any underlying IP network.  This decision was made for several reasons.

First, we knew that IP over ad-hoc WiFi has a number of problems, many of which are a direct result of interoperability problems among and within ad-hoc WiFi implementations.  Such interoperability issues could manifest as, among other things, an inability to deliver unicast IP packets, but allowing broadcast IP packets to be delivered just fine.

Second, we have planned from the outset to diversify our radio options beyond WiFi and other traditional wireless-IP based solutions. In particular, we have had our eye on low-bandwidth communications in the ISM bands.  At low bandwidth IP encapsulation would incur unnecessary overheads. Also, allowing compatibility with IP would mean that any such mesh would soon be drowned out by the general IP chatter of hosts, because most modern software is no longer designed with dialup and sub-dialup speeds in mind.

Third, it allows us to use public keys as network identifiers, and so gain some very nice security characteristics for free.

So we created the Serval Overlay Mesh (SOM) and Mesh Datagram Protocol (MDP) as our solution to this. We have already implemented encrypted voice calls and Serval DNA resolution over MDP.

That left the Rhizome store-and-forward file and data distribution system as the sole part of the Serval Mesh dependent on IP networking and unicast packets.

So this week I finally got around to implementing Rhizome over MDP, using a protocol similar to TFTP, but with each request asking for up to 32 packets at a time to improve throughput.  We also have some ideas for buffering and handling packet loss and out-of-order delivery, which we hope to implement soon.

In the process we also revamped Rhizome transfers to stream directly into the database, instead of having to be written to temporary files first.  We also hash the files as we receive them, so that there is no big time hit at the end of reception.  This is important for slow devices, large file transfers and situations where servald's responsiveness is important, such as when carrying a voice call.

But for now, we are happy that we can transfer arbitrarily large files using only broadcast IP packets, which makes it much easier to create useful mesh networks using existing ad-hoc WiFi capable equipement.

The image below shows servald running on a Dragino, and me poking it to see if a file has been received.  The file "foo" is duly received after a short while.

Syria in the Dark

Today it was announced that all Syria was cut off from the internet, and parts of the cellular telephone networks were shut down as well.

This is an example of a "politically induced disaster" as compared to the more familiar "naturally induced disasters", such as those resulting from bushfire or earthquake.

Whatever anyone may think of either the Syrian government or the rebel forces, what is clear is that an entire country suffers and is made more vulnerable by this kind of act.

It is thus suffering and vulnerability --- whatever the cause --- that the Serval Project seeks to alleviate.

And so when we hear news like this, the response in the lab is "code more", so that we can start delivering resilient communications solutions as soon as possible.

US Carriers Continue to Seek to Avoid Emergency Preparedness (and all Other) Regulation

In the aftermath of "Super Storm Sandy", questions are being asked in the USA about carriers, their preparedness for handling emergencies and disasters, and in a subtle way, whether the carriers are willing to incur the cost of such preparations, or whether they should be free to put profit ahead of the safety of the people, and avoid as much regulation as possible.

See, for example:

http://www.bloomberg.com/news/2012-11-15/why-cell-phones-went-dead-after-hurricane-sandy.html

Meanwhile, the people on the ground remain vulnerable to the whims of carriers, when they most need communications.  This is one of the many reasons why we continue work on the Serval Project, so that we can re-empower people to solve their own communications needs.

Open Writing of Serval Documentation

As the Serval Project is based in a University, we have a need to write academic papers.  However, such papers take a while to write, get peer reviewed and published. This is a problem since Serval is also an open-source project, and we need to get information out to the community in a timely manner.

So I am trying an experiment.  I am progressively moving all paper preparation activity into our github repository (http://github.com/servalproject/serval-docs/).

Some legacy documents will be in LibreOffice /OpenOffice format.

For new documents I will be aiming to use LyX (a LaTeX frontend), because commits that change documents will result in meaningful diffs between versions.  Also figures exist as separate files, and so are easier for people to access, update and/or reuse.

One of the nice advantages is that people can submit corrections, view older revisions, or submit "bugs" or "feature enhancements" for improvements to the document.  Overall, it seems like it should result in better papers.

Anyway, the first document there is a document describing Serval Rhizome.

Secure Communications Is Valuable

Well, we already knew this, but it is pleasing to see when others create things that are similar to what we are doing.  In this case, it is Phil Zimmermann (of PGP fame).  He has a startup called Secure Circle offering secure telephony and messaging:

http://www.fastcompany.com/3001938/phil-zimmermanns-silent-circle-builds-secure-seductive-fortress-around-your-smartphone

The actual company website is here.

Similarities between Silent Circle and Serval include the use of ECC for the crypto (we are using Curve25519 (effectively 251 bits) while they are using the NIST 384-bit curve), and some of the telephony services being offered.   There is no reason why we couldn't move to 384-bit or stronger crypto, but we do not see the need at this time.  It would be quite possible for us (or someone else) to switch out the crypto system for a different one should people desire to do so. The most practical reason why we are are not yet on a longer ECC system is that the NaCl library that we use is yet to support one, which reflects, in part, the fact that a (well implemented) 251-bit ECC system offers ample security for the time being.

Differences include that Serval is free (as in beer and as in liberty) and open-source, and rather importantly, that Serval technologies are designed for resilience, and do not require a cellular network or internet access to facilitate communications.

Using Serval as a Basis for Environmental Monitoring

One of our developers, Corey Wallis, is in the midst of a project with some of the other researchers in the Flinders University Disaster Research Centre (DRC) where they are creating a system to acquire temperature and humidity data from mass gathering events, such as concerts and sports events.

This involves both fixed and mobile devices with sensors continuously collecting data for analysis both at the event and on-line.

One of the tricks is that we can't rely on cellular service being available at these events.  Also, we want all of the field teams who are gathering data to also be able to visualise and act on the data, so we need a many-to-many distribution scheme.

These features make it an good fit for Serval Rhizome, our store-and-forward/Delay Tolerant Networking (DTN) system, that is able to handle both of these requirements, and will result in a very versatile system that can be used anywhere in the world.

Corey has made some good progress on the hardware and software for the data gathering, as can be seen in this blog post:

http://magdaaproject.org/2012/10/08/mobile-environment-monitoring-software-update/

Among the next steps are to actually integrate it with the Serval Mesh software so that the data can be shared among the field teams and analysis staff.