Hi Emmanuel, hi all,
Hi Lotte,
on your blog posts for watr.li you mention using R-idge + 6LoWPAN on a Pi, and you mention using RPL (or AODV) on top of that, in the near future, which is a very interesting perspective.
My question is: how do you intend to go about this?
Actually, we’ve already gone about this, and we’re working on a blogpost about this right now. The approach we opted for is a bit… pragmatic due to time constraints, but I’d be very very interested in improving this situation in general.
The situation we have right now is as follows:
Rosand Tech provides us with a RPL daemon [0] implementation, which Martin patched to make it work again with the latest Linux kernel. This daemon does its RPL-y thing, communicates with our RIOT nodes through the R-IDGE stick and writes all found routes to the Linux routing table.
This all sounds very nice, but there’s a catch: The rpld code seems to be a wrapper around contiki’s native mode. So what it does is it spawns a contiki instance, let that one do all the RPL operations, tunnels the packets generated by the contiki instance through towards the R-IDGE and back, and in case it hears about any route updates from the contki instance, then sets these in the linux kernel, too.
As I said, it’s probably a more pragmatic than perfect solution from Rosand, but there’s one big benefit of this “hack”: we git a little bit of RIOT-RPL interop experience.
( This is where Martin’s RPL improvement PRs came from. 
)
It would be great to discuss approaches on the mailing list, because there may be some cross-benefits at hand.
With Ubuntu people we had discussed using RIOT native instance running in Linux to use RIOT network stack. Discussing with Ludwig today, he mentioned another approach whereby the RIOT network stack could be straightforward to port to Linux, and thus provide their missing IoT network stack to communicate with RIOT devices (and still have a single code base to maintain for us).
That sounds like a great idea. There seem to be some RPL implementations for linux around [1], but one of them seems to rely heavily on kernel modules (which could be avoided altogether with the oonf api’s solution of listening on a tun/tap device which tunnels all unroutable packets into user space we talked about at the NSTF meeting), the second one was written in python, and the third one I couldn’t completely make sense of ad-hoc. And I have no idea about the interoperability status of either of them.
Do you already have a particular concept in mind? It would great to know about this.
See above. If anybody else on the list has ben working on the same problem, please share!
Cheers,
Lotte
Cheers,
Emmanuel
[0] http://rosand-tech.com/downloads/index.html
[1] http://sixpinetrees.blogspot.de/2014/11/linux-rpl-router.html