[riot-users] CoAP Servers + Border Routers on 6LoWPAN+RPL

Emmanuel Baccelli Emmanuel.Baccelli at inria.fr
Fri Mar 11 17:00:23 CET 2016

Hi Bruno,
following a discussion with @authmillenon, you might consider testing this
Do you also have the impression that something like this would help you
towards your goal?

On Thu, Mar 10, 2016 at 9:11 PM, Bruno Melo <bsilva.melo at gmail.com> wrote:

> Hi Lennart,
> Yes, I'm in the mailing list.
> First of all, thank you for the clarification regarding some of those
> tools. :-)
> Until now I was able to create basic line topologies with desvirt, and
> also to follow the
> "RIOT and Multi-Hop Routing with RPL" successfully (besides the IOT-Lab
> part). I
> need to experiment with grid topologies, since I think that is more close
> to what I'm looking for.
> My issue is that, although I'm able to run microcoap_server and
> gnrc_networking
> examples on native, the first uses IPv6+UDP+CoAP (so no RPL, 6LoWPAN and
> 802.15.4)
> and the second lacks 6LoWPAN and 802.15.4 (I'm ignoring CoAP in this case
> since
> I believe it would be "easy" to serve CoAP over that example).
> It may be a somehow dumb questioning, but *I wonder if I could run
> gnrc_networking*
> *(actually something based on it) on native including 802.15.4+6LoWPAN*,
> although
> I don't have the hardware --- meaning some emulated form or anything close
> to this.
> I know 6LoWPAN is not necessary to the functionality of the example itself
> on native,
> but I'd like to see the packets/frames from those protocols going back and
> forth.
> > Can you further specify what exactly you want to investigate? Basically,
> > nothing in the IoT is secure in any way. You could start with the
> hardware
> > that doesn't provide MMU's, operating systems (or the lack thereof) and
> their
> > bugs, address spoofing, DDoS attacks, data integrity, encryption (DTLS)
> and
> > so on.
> That's the thing: we don't know yet. I'm on a lab where people know their
> security-related
> stuff, but nothing about IoT tech. So, we wanted to build a "close enough
> to reality/production" scenario,
> and then start doing some Security Testing (from running static analysis
> tools to stress testing,
> some code coverage analysis), as well as looking for bugs/issues on the
> protocols specifications and
> [actually focus on] their implementations, trying to run DTLS, and so on.
> Basically, we're on a very exploratory phase. :-(
> []'s,
> Bruno Melo.
> Ps.: I'll also change things here to use that microcoap fork, thank you
> for pointing me to that.
> On Thu, Mar 10, 2016 at 4:41 PM, Lennart Dührsen <
> lennart.duehrsen at fu-berlin.de> wrote:
>> [putting you in CC because I don't know if you subscribed the mailing
>> list]
>> Hi Bruno,
>> I'll give you a few hints:
>> > I've seen a lot of keywords out there (e.g.: desvirt, ethos/ethos_br,
>> > tun/tap devices, ZEP, marz, tunslip, ...), but I'm still unable to
>> figure
>> > out the best way I could achieve the following scenario I want to build.
>> desvirt [0] is the virtualization framework for the DES-Testbed (=actual
>> hardware) [1] at FU Berlin. You can use desvirt to simulate arbitrary
>> network
>> topologies of RIOT nodes on your computer. The virtual nodes will be
>> instances
>> of the native port [2]. These will communicate using virtual network
>> interfaces, so called tun/tap devices. A tun interface works on layer 3
>> (i.e.
>> it gives you IP packets), a tap interface, which is what the native port
>> uses,
>> works on layer 2. tunslip [3] enables you to send IP packets over a serial
>> interface. The border router makes use of this; the RIOT node sends IP
>> packets
>> over a serial interface to a Linux host, on which you can retrieve said
>> packets from a tun interface. Concerning ZEP and marz, I'd say those are
>> not
>> important for you (I can't speak for ZEP, but marz was just a quick hack
>> and
>> to my knowledge doesn't work anymore).
>> > Just to provide context/motivation, and to present a few limitations as
>> > well, I would like to say:
>> > - I want to build this because it seems to cover, on a very general
>> way, a
>> > typical scenario of distributed CoAP nodes forming a LoWPAN using the
>> > stack (CoAP+UDP+RPL+6LoWPAN+802.15.4);
>> RIOT supports 802.15.4, 6lowpan, IPv6, RPL, UDP, and CoAP. There's a
>> tutorial
>> for RPL in the wiki [4]. microcoap [5] is the CoAP library used by most
>> folks, but I suggest you use this fork [6] instead, because microcoap is
>> not
>> being maintained anymore and lacks documentation.
>> > - For my master thesis I want to investigate security scenarios/issues
>> on
>> > IoT, and at least initially, I would like to do that with RIOT (great
>> open
>> > source project, congratz guys!).
>> > - *I believe this scenario would allow me to do this investigation over
>> the
>> > whole stack of protocols, with nodes taking different roles and so on*;
>> > - I would really like a way to accomplish this --- or some
>> closely-related
>> > form --- using only native, because we're very *limited on re$ource$*,
>> but
>> > if needed we could try to buy some samr21-xpro (which seems to be the
>> most
>> > developed in RIOT right now) or some cheaper hardware to use with XBee
>> > shields (or any other suggestion from you guys);
>> Can you further specify what exactly you want to investigate? Basically,
>> nothing in the IoT is secure in any way. You could start with the hardware
>> that doesn't provide MMU's, operating systems (or the lack thereof) and
>> their
>> bugs, address spoofing, DDoS attacks, data integrity, encryption (DTLS)
>> and
>> so on.
>> > ​Is that possible/feasible? What would be the best (or at least
>> > least-problematic) way to achieve that given my thoughts above?
>> Again, depends on what exactly you want to look at.
>> > Ps.: I was also able to run RIOT on Cooja, but as far as I understand I
>> > would have to develop a lot on Cooja to support the network
>> interactions I
>> > would like to see (and also support a board to which I can compile CoAP
>> > server applications, since telosb doesn't even have netif nor memory,
>> from
>> > what I understood). This could be a way to go, but not my preferred one.
>> I suggest you stick to RIOT OS on native and desvirt, then ;)
>> Hope this helps; best regards and good luck,
>> Lennart
>> [0] https://github.com/des-testbed/desvirt
>> [1] http://des-testbed.net/node/4
>> [2] https://github.com/RIOT-OS/RIOT/wiki/Board%3A-native
>> [3] https://github.com/RIOT-OS/RIOT/tree/master/dist/tools/tunslip
>> [4]
>> https://github.com/RIOT-OS/RIOT/wiki/Tutorial:-RIOT-and-Multi-Hop-Routing-with-RPL
>> [5] https://github.com/1248/microcoap
>> [6] https://github.com/i2ot/microcoap
> _______________________________________________
> users mailing list
> users at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/users/attachments/20160311/cfb6c66d/attachment-0001.html>

More information about the users mailing list