Re: [Roll] Looking for Linux implementation of RPL for interop testing

Alexander Aring <> Thu, 02 April 2015 20:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A87221A1A6E for <>; Thu, 2 Apr 2015 13:34:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8B7ThKxjN5c5 for <>; Thu, 2 Apr 2015 13:34:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B5F61A1A6A for <>; Thu, 2 Apr 2015 13:34:26 -0700 (PDT)
Received: by wiaa2 with SMTP id a2so118795802wia.0 for <>; Thu, 02 Apr 2015 13:34:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=SvrV2Z57OfYqrpi1iGX5RjcVon9L6EUhxUimknNwFB4=; b=nlxE8ZhyYLqRLqFUdcdN7zraIwcwABi/jXsfimq5BlkPe7sENtgRXzgHikHbyGF/M9 aqwOnb3SwPPDCU9XhDF8N1ZAVVPVo4a9NeAl1EZTWp7q+KMMWtlS4dFdK7SQQ910mo7A JXZD/BH+bh5Q8vFk6GK3y2Z+X3KIXWbafpo80MdK6xl4ICxcGxG258zexPdatQZDbmhl yV9fPdhgPett7z1VBAGI5djdRF1LI3V6+kwj5sYQ+d0BbuNPK8ER2I6ophdWZ9rACMQk 2jXDvn9STSUhWUj56U+ihRX6wWm3HGVJaC/FzCemTXOqyekyghwyYRZ3kMTQrOrwLeHH ln1Q==
X-Received: by with SMTP id dd4mr99317076wjb.56.1428006865238; Thu, 02 Apr 2015 13:34:25 -0700 (PDT)
Received: from omega ( [2003:64:a926:f21c:e2cb:4eff:fe1b:b546]) by with ESMTPSA id ew5sm31499292wic.14.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 13:34:24 -0700 (PDT)
Date: Thu, 2 Apr 2015 22:34:19 +0200
From: Alexander Aring <>
To: Routing Over Low power and Lossy networks <>
Message-ID: <20150402203416.GA18697@omega>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [Roll] Looking for Linux implementation of RPL for interop testing
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Apr 2015 20:39:34 -0000

Hi Ralph and Michael,

On Thu, Apr 02, 2015 at 02:40:41PM -0400, Michael Richardson wrote:
> Ralph Droms (rdroms) <> wrote:
>     > Can anyone point me at an implementation of RPL for Linux that provides
>     > non-storing mode operation?  I'm looking for both an LBR/DODAG root
>     > implementation and an LR implementation.  THe purpose is
>     > interoperability testing with an independent implementation.
> No, I can't point you at this, but I thought I'd answer about why we aren't
> seeing this yet.
> A non-storing mode implementation would require kernel implementation of the
> RH3 header in order to make work (particularly as DODAG root), and at this
> point, I'm unaware of anyone who has done that work, and it certainly isn't
> in the mainstream kernel.
> Perhaps someone out there is already working on it, and has patches.

I know three 3 RPL implementation for linux, all of them has limitations:

One kernelspace and two userspace implementations, I can't say much
about these limitations because I doesn't looked deeper into these
implementations and I have no idea about RPL stuff (currently). :-)

The kernelspace one:

 - Known as linux-rpl [0].
   In my opinion there is still much stuff to do there for bringing this
   stuff mainline. There is a blog article [1] about somebody who tested it
   with contiki nodes and it "seems" basically to work with limitations.

The userspace implementations:

 - SimpleRPL [2].
   Prototype implementation in python.

 - unstrung [3].
   I think the most people on this mailinglist knows about this

For using these implementation with current mainline:

NOTE: We changed in linux the ARPHRD (the uapi type for a netdev) from
ARPHRD_IEEE802154 to ARPHRD_6LOWPAN for the 802.15.4 6LoWPAN interface.

The reason was before the 802.15.4 and 802.15.4 6LoWPAN interface used
the same ARPHRD type, this situation occurs several troubles. Now BTLE
6LoWPAN and 802.15.4 6LoWPAN uses the same ARPHRD type which is
ARPHRD_6LOWPAN. On ARPHRD_6LOWPAN you will have a IPv6 view without L2
information, the ARPHRD_IEEE802154 wpan interface has 802.15.4 frames view.

I mostly saw that userspace applications evaluates the ARPHRD value for
checking on an EUI64 mac address length, which is the same for BTLE
6LoWPAN and 802.15.4 6LoWPAN.

I notice this because some applications still evaluates the old ARPHRD
value (I noticed this about another mail on mailinglist at [4]). So you
will have trouble to run current implementations with current mainline
if you don't this behaviour.

- Alex