Sunday, November 16, 2014

Linux RPL router

Recently there have been huge developments in Linux 6LoWPAN support. Old linux-zigbee was renamed to more appropriate linux-wpan. Openlabs released an excellent tutorial on running 6LoWPAN on RaspberryPi. With it you can get running 6LoWPAN Border Router, even if you never compiled Linux kernel before. Openlabs also released 802.15.4 module for RaspberryPi - it is very reasonably priced, works as advertised, and is currently best choice to quickly start development. Delivery with USPS seems fast too (12 days to Poland, Europe in my case).

Following my previous experiments with Grinch Border Router, I decided to try to take it one step further, and run RPL routing protocol on top of RaspberryPi with 6LoWPAN. My results below.

Linux branch

Following Openlabs advice, I decided to go with linux-wpan-next branch. I had one problem running this branch on RaspberryPi - Ethernet stopped working. I found solution on - the bug was caused by missing USB config directives in kernel. Take extra care to enable both CONFIG_USB_DWC2_HOST and CONFIG_USB_DWC2_PLATFORM in your kernel config.

Fixing RPL implementation

After checking the Internet for existing Linux RPL implementations, I found three feasible candidates:

After preliminary testing, I decided to go with linux-rpl, as it is a kernelspace implementation. Repository for linux-rpl contains code in a form of huge patches for Linux kernel 3.10, 3.11 and 3.12. After a few unsuccessful atempts to merge them I ported the 3.12 patch into linux-wpan-next branch manually. I left out patches related to XBee. My patched branch is available on Github

To run RPL you should clone my branch and then basically follow Openlabs tutorial:

  1. Run make menuconfig and enable proper kernel options (remember to enable CONFIG_IPV6_RPL and CONFIG_IPV6_RPL_OF_OF0 and USB options mentioned above)
  2. Build patched kernel
  3. Patch the device tree to add AT86RF233 transceiver and rebuild .dtb file
  4. Build U-Boot
  5. Move kernel, device tree file and U-Boot to the SD card with new Raspbian installation
  6. Boot up Raspberry and log-in using SSH (or keyboard/screen)
  7. Build userspace lowpan tools
  8. Configure wpan0 and lowpan0 interfaces

The steps above should give you working RaspberryPi with eth0 and lowpan0 interfaces.

Running RPL

First thing to do is to compile RPL userspace tools. Then you can enable RPL on chosen interface: for example lowpan0. You can run your RPi as a non-root RPL router. It will then search for a DODAG to join. To do that issue command:

sudo rpl-ctl enable lowpan0

You can also use sysctl:

sudo sysctl -w net.ipv6.conf.lowpan0.rpl_enabled=1

In most cases you will want your RPi to be DODAG root (it is useful when you plan to use your RPi to be a border router). As a DODAG root, your RPi will distribute address prefix for other RPL routers. To do that issue commands:

sudo sysctl -w net.ipv6.conf.lowpan0.rpl_dodag_root=1

sudo sysctl -w net.ipv6.conf.lowpan0.rpl_enabled=1

After that your RaspberryPi is be ready to communicate with RPL nodes. If you want to use your RPi as a Border Router there are other steps to take: enabling IPv6 forwarding, configuring IP address on eth0 interface, running radvd on eth0 interface, etc.

Communication with Contiki nodes

To determine which links should be used as a first choice, RPL protocol uses objective function (OF). All RPL nodes in a DODAG must use the same OF. The most basic objective function is OF0, and it is the only OF supported currently by Linux. Contiki OS 2.7 uses MRHOF objective function by default, but it supports OF0 too. To achieve communication between RaspberryPi with RPL, and Contiki, you need to compile Contiki with RPL using OF0 function. To do that add following line in your platform contiki-conf.h file:

#define RPL_CONF_OF rpl_of0

Remove other OF definitions if present. With this modification, your Contiki nodes should join DODAG formed by RaspberryPi.

Possible issues

I haven't throughly tested this setup, so bugs can be expected. Few remarks:

  1. (Edit: 01 Feb 2015) Multihop doesn't work - probable cause is lack of hop-by-hop RPL option support
  2. RPL userspace tools info commands (for example rpl-ctl list-neighbors) usually return nothing, it might be a bug
  3. I noticed nodes are slow to rejoin DODAG after restart.

Further tests are necessary.


RPL for Linux is usable. Joao Pedro Taveira's implementation seems to work with Linux 3.17 and 6LoWPAN (after minimal patching). This is very surprising, that implementation is no longer developed. Linux box is a superior solution for Border Router than any embedded system. Open Source's inefficiency is sometimes amazing.

Thursday, September 4, 2014

txThings improvements and news

I updated my txThings library and made some improvements:

1. txThings is now a proper Python package. It is available on PyPI. You can install txThings on most Python environments using command:

easy_install txthings


pip install txthings

These commands should automatically install txThings dependencies too - currently it's only Twisted. On Linux you need root privileges (sudo). You can also specify txThings as a dependency for your own application.

2. I added an example for Resource Directory. Resource Directory is based on draft-ietf-core-resource-directory-01 (it's already outdated but changes shouldn't be dramatic).

Also Christian Amsüss recently ported txThings to Python 3 and asyncio. Asyncio is a new Python 3 module, backed by Guido himself. It's an effort to partially unify many different Python asynchronous frameworks (make them run on a common event loop). I support this idea - it's Python's only chance against node.js. Twisted is actively being ported to Python 3 and is going to have bindings for asyncio, so one day it might be possible to just run the code and not worry about compatibility. Christian's library is called aiocoap. If you plan to develop apps for Python 3, you should strongly consider using aiocoap.

Saturday, March 8, 2014

Aneska - simple CoAP browser for Android

When I started working on txThings CoAP library I needed to create some GUI tools for testing - simple client and server. I checked the existing Python GUI libraries and I wasn't really satisfied with the results of my search. GUI programming in Python is very fragmented, there are over 40 libraries, and it's hard to make an informed choice. I've finally decided to try Kivy framework - its webpage seemed nice. Kivy is a modern framework, with strong focus on multiple platform and touch screen support. It has some nice features:
  • runs on Windows, Linux and Android (with Python for Android)
  • looks more or less the same on each platform
  • supports Twisted integration
  • supports many touchscreen features like swiping, scrolling etc.
At first I wanted to create a very simple tool for testing txThings library on Linux and Windows, but out of curiosity I tried packaging the app for Android . The tutorial was well written, and everything went very smooth - after around 4 hours I had first working Android app. I was really amazed by the simplicity of the process. I decided to work a bit more on it, and gradually I got a very basic CoAP browser. It was quite usable, but not very polished. Then I took a decision to finish the job, and release the simple CoAP browser to the Play store.

GUI development

Kivy is a very nice framework, but many parts of it are still quite immature. Kivy uses its own Kv language to describe the layout. It works fine with simple widgets like buttons and labels. But many complex widgets like treeviews, spinners etc. are in reality compounds of simpler widgets. It is sometimes hard to access the properties of these "inner" widgets using Kv language. Occasionally it's necessary to overload existing widgets to achieve desired effects. Many times I had to browse the source code of some widgets to get things done (luckily after two years of dealing with Contiki OS, reading Python source code is a piece of cake :) ). On the other hand, some complicated stuff was very easy to achieve using Kivy - like swipe-to-close browsing cards, and animated screen transitions.

After finishing the communications layer and the GUI I decided to implement also some simple parser for RFC 6690 CoRE Link Format. I used link_header library from Asplake. I also added simple bookmarks support. After that I added icon and splash screen, and started working on the visuals. I discovered that designing a decent GUI for a mobile app is not that easy :) - maybe using a combination of blue and orange wasn't the best choice ;).

Double-stack support

Big problem in making the browser was IPv4/IPv6 double stack operation. CoAP is meant to be used mostly with IPv6, but it's adoption is still not very wide. IPv4 support is simply a must. Linux (and Android) IPv6 UDP sockets can send and receive IPv4 packets, provided that the address is passed as IPv4-mapped IPv6 address (::ffff:X.X.X.X). That doesn't work on Windows (bug in Windows Python 2.7 code). Another thing was the DNS support. I had no idea how to tackle that problem, but at the end of 2013, new version 13.2 of Twisted framework was released, that supported RFC 6555 "Happy Eyeballs" algorithm. This algorithm was designed for TCP-based, human-operated client apps, however I managed to adapt it to work with UDP-based application. I had to change some parts of txThings blockwise code to allow for callbacks after every block (this can be useful later to implement progress bars for blockwise transfers). Currently the "Happy Eyeballs" works fine with normal and blockwise requests. I'm not entirely sure about observe requests - the algorithm will accept the first response and send RST to all subsequent responses, but if the response is NON it might not always cancel the observation. Proactive observe cancellation is being discussed by IETF right now, so maybe it will solve the problem.


The resulting application is more proof of concept than a perfect solution. Unfortunately the application starts quite slow on Android (around 2 seconds on my SGS3), probably because of Python interpreter. The download is rather big, because it's bundled with Python and its extensions. However the app does its job, runs on Linux and Windows, and at the time of writing it's the only CoAP browser for Android so it might be useful for researchers and testers. I used it successfully with CoAP test servers:

  • TZI Universitat Bremen: coap://
  • ETH Zurich: coap://

I am planning to setup my own test server based on txThings and twistd.

Link to the app below: