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

Thanks, Alex - your response is *very* helpful...

Anyone have a suggestion about other ways to do interop testing, especially with a non-storing mode LBR/DODAG root?

- Ralph

> On Apr 2, 2015, at 4:34 PM 4/2/15, Alexander Aring <alex.aring@gmail.com> wrote:
> 
> Hi Ralph and Michael,
> 
> On Thu, Apr 02, 2015 at 02:40:41PM -0400, Michael Richardson wrote:
>> Ralph Droms (rdroms) <rdroms@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@ietf.org
> https://www.ietf.org/mailman/listinfo/roll