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

sorry - meant to send that to ralph.  frustration with implementing some 
kernel software.

         Geoff

On 04/02/2015 03:50 PM, Ralph Droms wrote:
> 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
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll