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

Bruno Melo bsilva.melo at gmail.com
Fri Mar 11 20:19:25 CET 2016


Oh you're right, it really seems so. I've seen it before on GitHub but
didn't really noticed the potential.

I'll take a look at this (PR+IETF Draft) and see what I can achieve with it.

Thanks a lot for the help, guys.
I'll keep in touch.

[]'s,
Bruno Melo.

On Fri, Mar 11, 2016 at 1:00 PM, Emmanuel Baccelli <
Emmanuel.Baccelli at inria.fr> wrote:

> Hi Bruno,
> following a discussion with @authmillenon, you might consider testing this
> PR:
> https://github.com/RIOT-OS/RIOT/pull/4861
> Do you also have the impression that something like this would help you
> towards your goal?
> Cheers
> Emmanuel
>
> 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
>>> IETF
>>> > 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
>>> RIOT
>>> 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
>>
>>
>
> _______________________________________________
> 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/1cac2848/attachment.html>


More information about the users mailing list