I thought this might be of interest for some of you (which are not subscribed to
the ROLL ML).
printk(??? No FDIV bug? Lucky you...\n);
Hi Ralph and Michael,
On Thu, Apr 02, 2015 at 02:40:41PM -0400, Michael Richardson wrote:
Ralph Droms (rdroms) rdr...@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 .
In my opinion there is still much stuff to do there for bringing this
stuff mainline. There is a blog article  about somebody who tested it
with contiki nodes and it seems basically to work with limitations.
The userspace implementations:
- SimpleRPL .
Prototype implementation in python.
- unstrung .
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 ). So you
will have trouble to run current implementations with current mainline
if you don't this behaviour.
Roll mailing list
Description: PGP signature
devel mailing list