... and Serval is a first-round winner of the Pacific Humanitarian Challenge

See: http://pacifichumanitarianchallenge.org/announcing-top-10-first-round-winners

This is a challenge posed by AusAID, the Australian International Aid agency to help Pacific Nations following disaster and emergency situations.

Together with NZ Red Cross our proposal looks at making Serval operationally ready and in use in Pacific Nations to help people stay connected when cyclones and other disaster strikes.

Succinct Data pilot in Fiji

While we have been quiet lately, we haven't been idle.  Quite the opposite. The last few weeks we have been working on getting Succinct Data operationally ready for use by NZ Red Cross, which we have now succeeded in doing, as explained in the press release with Magpi below.

http://home.magpi.com/media-room/magpi-satellite-communication-integration/?utm_content=bufferb8735&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

This has only been possible because of the generous support a grant from USAID, and the assistance of the folks at both Magpi and VasTerra.

TP-Link Firmware Lockdown and Alternative (Better!) Hardware for Mesh Extenders

TP-LINK are starting to lock down the firmware on their routers.  This is a bad idea, because it means that there will be more and more routers out there that have horribly out of date and vulnerable firmware, that cannot be updated and secured by end-users, or in our case, re-purposed to meet their individual and/or humanitarian needs.  This is rather sad.

Fortunately, there are manufacturers making what are basically souped up clones of the cheap TP-LINK routers, such as the WR703N and MR3020 that we have been using for the Mesh Extender prototypes.

One that has caught our eye is this one:

https://wiki.openwrt.org/toh/gl-inet/gl-ar150

Which you can buy from places like this:

http://www.aliexpress.com/item/GL-iNet-6416A-150Mbps-802-11g-b-n-SMART-Mini-WiFi-Wireless-Router-OPENWRT-ENGLISH-Firmware/32273181856.html
http://www.aliexpress.com/item/GL-iNet-AR-150-150Mbps-OPENWRT-Firmware-Mini-Routers-Wi-Fi-Router-WiFi-Repeater-Booster-Extender/32464052719.html

It comes with OpenWRT DD 14.07 pre-installed, has 64MB RAM (instead of 32MB in the MR3020) and 16MB FLASH (instead of the tiny 4MB on the MR3020), has the serial port already with a header on it (unlike the fiddly soldering process on the MR3020), and also has a few GPIOs on the same header (none on the MR3020), and has two ethernet ports (instead of one on the MR3020).   Oh yes, and if you don't mind paying an extra US$5, which still brings the price to only almost what an MR3020 costs), you can have an external Wi-Fi antenna, which will be sure to increase the range compared with the PCB antennae on the MR3020 (which we hope to verify soon).

In short, it is at least as good, if not better, on every technical measure when compared with the MR3020 and WR703N, and they are also cheaper! In fact, we can get the external antenna version express international couriered via DHL from China for less than we have to pay for an MR3020 via ebay in Australia!

Further, with the extra flash, we should be able to make a Mesh Extender install package set that can just be installed on it, because there is actually enough room in the flash for servald, lbard and the various scripts and things we need. Combine that with the fact that we have a real physical header that we can use to connect between the RFD900 radio and the router PCB, avoiding the need for any soldering at all*, the physical assembly process is now greatly simplified. This makes us very happy about the prospect of making Mesh Extenders easier to build and provision, including for people who aren't big on soldering.

All we will need to have is some special little cable made that goes between the headers on the PCB, and the RFD900 radio, and an updated case design.

Now, about that little * about "no soldering", the only problem we have remaining is that the headers which come on the board don't have a 5V line populated, so we will still need to solder a header on, assuming that the Power-Over-Ethernet header has access to the 5V rail, which seems like a reasonable prospect.  We will take a look at this when the 5 units that we have ordered have arrived. In any case, soldering on just a header is not a big problem, and we might even be able to ask the manufacturer to prepare a batch with the header fully populated.  Likewise, we can probably ask some company in China to make up the little adapter cables that we will want to go between the radio and PCB.

We wouldn't have found these units if TP-LINK weren't being unhelpful with their firmware lockdown policy, so in this particular case it is a clear example where being unfriendly to the open-source will result in

Running Serval in the Core Network Simulator

I've just been visiting the NICER project folks in Darmstadt and Marburg in Germany, where they are starting to use Serval for various parts of their research.  They have a really nice approach to the work, which is quite complementary to what we are doing.  One of the things that they have done recently is to work on simulating various Serval networks.  In the linked post below, the describe how to simulate Serval using the Core network simulator.

http://otg-living.blogspot.com.au/2016/01/running-serval-in-core-network-simulator.html

autoconf AC_PROG_JAVAC possibly undefined macro

Some folks are occassionally hitting a problem where they receive an error similar to the following when they try to run autoconf on the serval-dna repository (or indeed other software):

autoconf AC_PROG_JAVAC possibly undefined macro

This is extremely annoying, and doesn't really give any clues as to the cause.  A bit of googling reveals that this can be fixed in most cases by running:

autoreconf -i

Then autoconf should be able to be run without further problems.

Getting rid of the Offers4U ad-ware track-ware on Mac

Offers4U is an annoying ad-inserting thing for browsers that pops up large annoying "offer suggestions" and other junk when browsing the web (which also implies that it is taking a bit too close a look at your browsing activities..).

There is plenty of information about how to get rid of it on Windows, however there wasn't any clear information on how to get rid of it from Chrome on a Mac.

After a little exploration I found that it is part of the seemingly-unrelated "SafeFrom.Net helper" that claims only to be a tool to make it easier to download videos from youtube and other streaming sites.

To get rid of it, open chrome://extensions/ in chrome, and then disable the SaveFrom.net helper extension.  I guess if you still want to be able download from youtube and other places (e.g., if you lost the original of a video you uploaded some time ago), then you can turn the extension on, open a new tab, and then disable it again after completing the download.

Working on Mesh Extender firmware

I've been working on various aspects of the Mesh Extender firmware lately.

There are now a bunch of configuration options you can set by putting text files on the FAT partition of the USB memory stick.  This makes it fairly easy to set the configuration in the field, but putting the USB stick into almost any computer.  Gory details for them are on github, but I'll introduce a couple of fun ones now.

otabid.txt lets you specify a Rhizome Bundle ID (BID) that will be assumed to contain over-the-air updates.  Together with the over-the-air-updates/bootstrap program in the mesh-extender-builder repository linked above, this creates a nice easy way to update the main Serval binaries and configuration files on a Mesh Extender.  While this facility was designed to help with the development process, it will also come in handy for general software updates.  By setting the BID to a BID of your own choice, it is possible to have separate groups of Mesh Extenders that get updated separately, so that you can, for example, maintain separate development and production devices.

The second file is monitor.sid, and works with the above so that you can get a Mesh Extender to send a MeshMS message to someone whenever they apply an over-the-air update.  The message contains the GIT commit of the mesh-extender-builder repository that built the over-the-air update, thus providing you with a nice easy way to keep track of which Mesh Extenders have which version of what.

Sending the MeshMS was pretty easy, as we have a nice command line interface for doing so. The only real magic is getting the SID of the Mesh Extender, which we do with a nested shell command to get the SID out of Serval's keyring structure.  Here is the complete bit of code that sends the MeshMS, if monitor.sid exists.

# Now send a MeshMS to whoever cares about this mesh extender

if [ -e /dos/monitor.sid ]; then

  RECIPIENT=`cat /dos/monitor.sid`

  COMMIT="GITCOMMITSTUFF"

  /serval/servald meshms send message `/serval/servald keyring list | tail -1 | cut -f1 -d:` ${RECIPIENT} "Over-the-air-update installed on this mesh extender: git ${COMMIT}"

fi

What was really nice was that this worked first time.  Once I got the SID out of my phone, and put it on the Mesh Extender, and pushed out an OTA update, I had a MeshMS within a minute or so that looked like this:

Note that the timestamp is the creation time of the OTA update, not the time it was applied.

Also, note that these OTA updates are pushed out over the Serval Mesh itself -- the Mesh Extender has no internet access.  In other words, we now have a nice facility that allows us to update Mesh Extenders in the field, without any supporting infrastructure, and with enough feedback so that we know which devices have been updated to what version.