Hello Michael, Thanks! Answers to your questions here:
- We used plain Contiki, since we forked from 6lbr, which itself forked from plain Contiki (we did this since 6lbr already had CoAPs functionality implemented). We have given thought to migrating to Contiki-ng, so that could happen at some point. - By disadvantaged networks we do mean something similar to constrained networks as defined in RFC 7228. In the past we've mostly focused on DIL (Disconnected, intermittent, and limited bandwidth) environments mostly due to the mobility of the devices involved and the environmental conditions of our use cases. But most of the constraints are similar. - We are striving to get it down to around 250 kb, but we haven't spent that much time yet trimming it down. With some work, we should probably be able to get there. Thanks for your comments! Sebastian On 1/28/19, 6:51 PM, "Michael Richardson" <[email protected]> wrote: Thanks for the report! Sebastian Echeverria <[email protected]> wrote: > * We used Contiki as the base/OS for the code. More specifically, we > forked Contiki, or contiki-ng? > from the 6lbr project (https://github.com/cetic/6lbr), as that version > already had some code for handling DTLS connections and AES encryption in > it. > * We are using the TI CC2538dk board as our constrained target platform. > * The implementation has support for the DTLS profile, using pre-shared keys, > as this was enough for our use case. Yes, but often not really enough for a deployment where we need certificates or raw public keys, and this may have significant affects on packet sizes :-( > * We modified the Erbium CoAP server in 6lbr to be able to simultaneously > listen for CoAP and CoAPs connections (using TinyDTLS underneath). That's an interesting and useful change. > * The implementation has some additional optional features related to our > disadvantaged network environments, such as bootstrapping of the PSK > credentials, and detecting revoked tokens through introspection. When you say "disadvantaged", I think that you mean "constrained", as per RFC7228? > * The current binary is around 300 kb, which is good enough for the 512 kb > flash on the TI boards, though it may be a bit too large for a class II > device. We can probably make it a bit smaller. In terms of RAM, it fits in > the 32 KB available on the TI boards. The key number is 256K, so that one can double buffer the firmware image. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
