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
