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 < [email protected]> 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 <[email protected]> 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 < >> [email protected]> 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 >> [email protected] >> https://lists.riot-os.org/mailman/listinfo/users >> >> > > _______________________________________________ > users mailing list > [email protected] > https://lists.riot-os.org/mailman/listinfo/users > >
_______________________________________________ users mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/users
