[Unstrung-hackers] [Roll] Looking for Linux implementation of RPL for interop testing

Michael Richardson mcr at sandelman.ca
Mon Apr 6 20:53:52 EDT 2015

I thought I'd repost this here.
The linux-rpl code is likely a good place to start from for getting 6553/6554
support into the kernel so that one can use non-storing mode.

Alexander Aring <alex.aring at gmail.com> wrote:
    > On Thu, Apr 02, 2015 at 02:40:41PM -0400, Michael Richardson wrote:
    >> Ralph Droms (rdroms) <rdroms at cisco.com> 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 implementation.

    > 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

    > [0] https://github.com/joaopedrotaveira/linux-rpl [1]
    > http://sixpinetrees.blogspot.de/2014/11/linux-rpl-router.html [2]
    > https://github.com/tcheneau/simpleRPL [3] http://unstrung.sandelman.ca/
    > [4]
    > http://lists.sandelman.ca/pipermail/unstrung-hackers/2015-March/000014.html

    > _______________________________________________ Roll mailing list
    > Roll at ietf.org https://www.ietf.org/mailman/listinfo/roll

More information about the Unstrung-hackers mailing list