Re: [riot-devel] Refectoring the network stack
Hi Adam, 2014-11-07 11:38 GMT+01:00 Adam Hunt : > Will this refactoring effort allow for multiple interfaces on a single > RIOT device? Yes this (and easier more modularity through less coherence => easier testing) is the main reason for the refactoring. > What about bringing the border router support back into a state where a > real, well designed RIOT based border router? Or, is the role of a border > router better filled by Linux and the associated 15.4 driver work that's > being done. > The broken border router is mainly the fault of the broken 6LoWPAN Neighbor Discovery and the restricted possibility of multiple interfaces (it used to be just a thread, that scooped all packets not addressed to a node in the PAN over the UART of a node with no other option available). Since the refactoring effort also aims to squash this bugs once and for all (again through easier testing) and the multiple interface support is build-in into the model (you can even have SLIP over UART, if you do not have an Ethernet or WiFi module; have a look at PR #1454 [1]), there is nothing that is in the way of a functioning border router. Cheers, Martine [1] https://github.com/RIOT-OS/RIOT/pull/1454 ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
On 2014-11-07 21:38, Adam Hunt wrote: Will this refactoring effort allow for multiple interfaces on a single RIOT device? What about bringing the border router support back into a state where a real, well designed RIOT based border router? Or, is the role of a border router better filled by Linux and the associated 15.4 driver work that's being done. I'm just adding my 2c worth. I'm not really directly answering the question. Recently I've been using the ESP2866 wifi modules. They're pretty interesting. I really think at some point, a 'Cloud' approach needs to be considered/discussed. Yes, there are lots of people that want their own device-space but since a 'Linux Router' is extra hardware+software (that somebody might not want), some sort of cloud notion is worthwhile considering. It's also 'funding-friendly'. Regards David ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
Will this refactoring effort allow for multiple interfaces on a single RIOT device? What about bringing the border router support back into a state where a real, well designed RIOT based border router? Or, is the role of a border router better filled by Linux and the associated 15.4 driver work that's being done. On Thu Nov 06 2014 at 10:24:24 AM Martine Lenders wrote: > > Am 06.11.2014 18:56 schrieb "Adam Hunt" : > > > > > > I'm sorry, somehow I missed the point where you mentioned 802.15.4e. > Feel free to ignore me. After last night I shouldn't be allowed to post in > public forums full of people smarter than I. > > No need to be sorry. I'm guilty of this "falacy", too! xD > > > > > --adam > > > > On Nov 6, 2014 9:46 AM, "Martine Lenders" > wrote: > >> > >> Hi Adam, > >> > >> Am 06.11.2014 18:38 schrieb "Adam Hunt" : > >> > > >> > Is support for TSCH in there somewhere? While I'm not entirely read > up on the spec it would seem to be fairly important these days. > >> > > >> > What is the current state of TSCH support in RIOT these days? I'm > stuck on my phone at the moment or I'd take a look for myself (really, it > probably has a bit more to do with my being hungover and slightly lazy this > morning). > >> > >> Currently use the already existing TSCH implentation OpenWSN. So that's > where it is hiding ;) > >> > >> Cheers, > >> Martine > >> > >> > > >> > --adam > >> > > >> > On Nov 5, 2014 9:15 AM, "Martine Lenders" > wrote: > >> >> > >> >> Hi, > >> >> as discussed on the virtual meeting we aim to have the new network > stack running with the next release (end of November or before christmas). > Currently, I'm the only one directly involved into the development (appart > from several radio driver implementations), and while parts of the model > come from me, Hauke is currently refining it. As for development it is > clear, that I can't be the only one working on it. > >> >> > >> >> I'm currently in the testing stage of 6LoWPAN but it is mostly done, > but I still need some kind of way to communicate with the transceiver > module for older boards (alternative would be to remove it, but for this we > need #1772 and #1733 merged and all boards moved to the low-level driver > model). I hope I have this done at the end of next week. > >> >> > >> >> All in all it's still a long way to the transport layer and to speed > things up, I thought some of you guys may want to help me. I tried to split > down the tasks at hand and assigned preliminary some people who might be > able to do it. If you do not want/can not do this task, please notify this. > Also if you want to take over a task do tell so too, please. Every > assignment with a question mark is not fixed yet. > >> >> > >> >> * Model (Martine? and Hauke) > >> >> * 6LoWPAN > >> >> - backwards compatibility with transceiver module (Martine) > >> >> - bug-hunting (Martine) > >> >> - ND according to https://tools.ietf.org/html/rfc6775 (Martine?, > depends on a running ND for IPv6) > >> >> - optional: Next header compression (Oleg?) > >> >> * IPv6 > >> >> - port to netapi and pktbuf and remove 6LoWPAN dependency > (Martine?) > >> >> - consistent and extendable IPv6 Extension Header API (Martine?) > >> >> - consistent and extendable ICMPv6 API (Lotte?) > >> >> - Neighbor discovery according to > http://tools.ietf.org/html/rfc4861 (Martine?, depends maybe on ICMPv6 > API, but can be done without it, I guess) > >> >> * Transport layer > >> >> - port to netapi and pktbuf (Cenk?) > >> >> > >> >> * optional tasks for full deprecation of `transceiver`: > >> >> - port OpenWSN (would this also include an IEEE 802.15.4e MAC > layer?) and CCNlite to netapi or netdev > >> >> - port boards that use cc110x to periph API or port cc110x_legacy > and cc110x_legacy_csma to netdev > >> >> - either removal or port to netdev of redbee-econotag > >> >> > >> >> > >> >> ___ > >> >> devel mailing list > >> >> devel@riot-os.org > >> >> http://lists.riot-os.org/mailman/listinfo/devel > >> >> > >> > > >> > ___ > >> > devel mailing list > >> > devel@riot-os.org > >> > http://lists.riot-os.org/mailman/listinfo/devel > >> > > >> > >> > >> ___ > >> devel mailing list > >> devel@riot-os.org > >> http://lists.riot-os.org/mailman/listinfo/devel > >> > > > > ___ > > devel mailing list > > devel@riot-os.org > > http://lists.riot-os.org/mailman/listinfo/devel > > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
Am 06.11.2014 18:56 schrieb "Adam Hunt" : > > I'm sorry, somehow I missed the point where you mentioned 802.15.4e. Feel free to ignore me. After last night I shouldn't be allowed to post in public forums full of people smarter than I. No need to be sorry. I'm guilty of this "falacy", too! xD > > --adam > > On Nov 6, 2014 9:46 AM, "Martine Lenders" wrote: >> >> Hi Adam, >> >> Am 06.11.2014 18:38 schrieb "Adam Hunt" : >> > >> > Is support for TSCH in there somewhere? While I'm not entirely read up on the spec it would seem to be fairly important these days. >> > >> > What is the current state of TSCH support in RIOT these days? I'm stuck on my phone at the moment or I'd take a look for myself (really, it probably has a bit more to do with my being hungover and slightly lazy this morning). >> >> Currently use the already existing TSCH implentation OpenWSN. So that's where it is hiding ;) >> >> Cheers, >> Martine >> >> > >> > --adam >> > >> > On Nov 5, 2014 9:15 AM, "Martine Lenders" wrote: >> >> >> >> Hi, >> >> as discussed on the virtual meeting we aim to have the new network stack running with the next release (end of November or before christmas). Currently, I'm the only one directly involved into the development (appart from several radio driver implementations), and while parts of the model come from me, Hauke is currently refining it. As for development it is clear, that I can't be the only one working on it. >> >> >> >> I'm currently in the testing stage of 6LoWPAN but it is mostly done, but I still need some kind of way to communicate with the transceiver module for older boards (alternative would be to remove it, but for this we need #1772 and #1733 merged and all boards moved to the low-level driver model). I hope I have this done at the end of next week. >> >> >> >> All in all it's still a long way to the transport layer and to speed things up, I thought some of you guys may want to help me. I tried to split down the tasks at hand and assigned preliminary some people who might be able to do it. If you do not want/can not do this task, please notify this. Also if you want to take over a task do tell so too, please. Every assignment with a question mark is not fixed yet. >> >> >> >> * Model (Martine? and Hauke) >> >> * 6LoWPAN >> >> - backwards compatibility with transceiver module (Martine) >> >> - bug-hunting (Martine) >> >> - ND according to https://tools.ietf.org/html/rfc6775 (Martine?, depends on a running ND for IPv6) >> >> - optional: Next header compression (Oleg?) >> >> * IPv6 >> >> - port to netapi and pktbuf and remove 6LoWPAN dependency (Martine?) >> >> - consistent and extendable IPv6 Extension Header API (Martine?) >> >> - consistent and extendable ICMPv6 API (Lotte?) >> >> - Neighbor discovery according to http://tools.ietf.org/html/rfc4861 (Martine?, depends maybe on ICMPv6 API, but can be done without it, I guess) >> >> * Transport layer >> >> - port to netapi and pktbuf (Cenk?) >> >> >> >> * optional tasks for full deprecation of `transceiver`: >> >> - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?) and CCNlite to netapi or netdev >> >> - port boards that use cc110x to periph API or port cc110x_legacy and cc110x_legacy_csma to netdev >> >> - either removal or port to netdev of redbee-econotag >> >> >> >> >> >> ___ >> >> devel mailing list >> >> devel@riot-os.org >> >> http://lists.riot-os.org/mailman/listinfo/devel >> >> >> > >> > ___ >> > devel mailing list >> > devel@riot-os.org >> > http://lists.riot-os.org/mailman/listinfo/devel >> > >> >> >> ___ >> devel mailing list >> devel@riot-os.org >> http://lists.riot-os.org/mailman/listinfo/devel >> > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
I'm sorry, somehow I missed the point where you mentioned 802.15.4e. Feel free to ignore me. After last night I shouldn't be allowed to post in public forums full of people smarter than I. --adam On Nov 6, 2014 9:46 AM, "Martine Lenders" wrote: > Hi Adam, > > Am 06.11.2014 18:38 schrieb "Adam Hunt" : > > > > Is support for TSCH in there somewhere? While I'm not entirely read up > on the spec it would seem to be fairly important these days. > > > > What is the current state of TSCH support in RIOT these days? I'm stuck > on my phone at the moment or I'd take a look for myself (really, it > probably has a bit more to do with my being hungover and slightly lazy this > morning). > > Currently use the already existing TSCH implentation OpenWSN. So that's > where it is hiding ;) > > Cheers, > Martine > > > > > --adam > > > > On Nov 5, 2014 9:15 AM, "Martine Lenders" > wrote: > >> > >> Hi, > >> as discussed on the virtual meeting we aim to have the new network > stack running with the next release (end of November or before christmas). > Currently, I'm the only one directly involved into the development (appart > from several radio driver implementations), and while parts of the model > come from me, Hauke is currently refining it. As for development it is > clear, that I can't be the only one working on it. > >> > >> I'm currently in the testing stage of 6LoWPAN but it is mostly done, > but I still need some kind of way to communicate with the transceiver > module for older boards (alternative would be to remove it, but for this we > need #1772 and #1733 merged and all boards moved to the low-level driver > model). I hope I have this done at the end of next week. > >> > >> All in all it's still a long way to the transport layer and to speed > things up, I thought some of you guys may want to help me. I tried to split > down the tasks at hand and assigned preliminary some people who might be > able to do it. If you do not want/can not do this task, please notify this. > Also if you want to take over a task do tell so too, please. Every > assignment with a question mark is not fixed yet. > >> > >> * Model (Martine? and Hauke) > >> * 6LoWPAN > >> - backwards compatibility with transceiver module (Martine) > >> - bug-hunting (Martine) > >> - ND according to https://tools.ietf.org/html/rfc6775 (Martine?, > depends on a running ND for IPv6) > >> - optional: Next header compression (Oleg?) > >> * IPv6 > >> - port to netapi and pktbuf and remove 6LoWPAN dependency (Martine?) > >> - consistent and extendable IPv6 Extension Header API (Martine?) > >> - consistent and extendable ICMPv6 API (Lotte?) > >> - Neighbor discovery according to http://tools.ietf.org/html/rfc4861 > (Martine?, depends maybe on ICMPv6 API, but can be done without it, I guess) > >> * Transport layer > >> - port to netapi and pktbuf (Cenk?) > >> > >> * optional tasks for full deprecation of `transceiver`: > >> - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?) > and CCNlite to netapi or netdev > >> - port boards that use cc110x to periph API or port cc110x_legacy and > cc110x_legacy_csma to netdev > >> - either removal or port to netdev of redbee-econotag > >> > >> > >> ___ > >> devel mailing list > >> devel@riot-os.org > >> http://lists.riot-os.org/mailman/listinfo/devel > >> > > > > ___ > > devel mailing list > > devel@riot-os.org > > http://lists.riot-os.org/mailman/listinfo/devel > > > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
Hi Adam, Am 06.11.2014 18:38 schrieb "Adam Hunt" : > > Is support for TSCH in there somewhere? While I'm not entirely read up on the spec it would seem to be fairly important these days. > > What is the current state of TSCH support in RIOT these days? I'm stuck on my phone at the moment or I'd take a look for myself (really, it probably has a bit more to do with my being hungover and slightly lazy this morning). Currently use the already existing TSCH implentation OpenWSN. So that's where it is hiding ;) Cheers, Martine > > --adam > > On Nov 5, 2014 9:15 AM, "Martine Lenders" wrote: >> >> Hi, >> as discussed on the virtual meeting we aim to have the new network stack running with the next release (end of November or before christmas). Currently, I'm the only one directly involved into the development (appart from several radio driver implementations), and while parts of the model come from me, Hauke is currently refining it. As for development it is clear, that I can't be the only one working on it. >> >> I'm currently in the testing stage of 6LoWPAN but it is mostly done, but I still need some kind of way to communicate with the transceiver module for older boards (alternative would be to remove it, but for this we need #1772 and #1733 merged and all boards moved to the low-level driver model). I hope I have this done at the end of next week. >> >> All in all it's still a long way to the transport layer and to speed things up, I thought some of you guys may want to help me. I tried to split down the tasks at hand and assigned preliminary some people who might be able to do it. If you do not want/can not do this task, please notify this. Also if you want to take over a task do tell so too, please. Every assignment with a question mark is not fixed yet. >> >> * Model (Martine? and Hauke) >> * 6LoWPAN >> - backwards compatibility with transceiver module (Martine) >> - bug-hunting (Martine) >> - ND according to https://tools.ietf.org/html/rfc6775 (Martine?, depends on a running ND for IPv6) >> - optional: Next header compression (Oleg?) >> * IPv6 >> - port to netapi and pktbuf and remove 6LoWPAN dependency (Martine?) >> - consistent and extendable IPv6 Extension Header API (Martine?) >> - consistent and extendable ICMPv6 API (Lotte?) >> - Neighbor discovery according to http://tools.ietf.org/html/rfc4861 (Martine?, depends maybe on ICMPv6 API, but can be done without it, I guess) >> * Transport layer >> - port to netapi and pktbuf (Cenk?) >> >> * optional tasks for full deprecation of `transceiver`: >> - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?) and CCNlite to netapi or netdev >> - port boards that use cc110x to periph API or port cc110x_legacy and cc110x_legacy_csma to netdev >> - either removal or port to netdev of redbee-econotag >> >> >> ___ >> devel mailing list >> devel@riot-os.org >> http://lists.riot-os.org/mailman/listinfo/devel >> > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
Is support for TSCH in there somewhere? While I'm not entirely read up on the spec it would seem to be fairly important these days. What is the current state of TSCH support in RIOT these days? I'm stuck on my phone at the moment or I'd take a look for myself (really, it probably has a bit more to do with my being hungover and slightly lazy this morning). --adam On Nov 5, 2014 9:15 AM, "Martine Lenders" wrote: > Hi, > as discussed on the virtual meeting we aim to have the new network stack > running with the next release (end of November or before christmas). > Currently, I'm the only one directly involved into the development (appart > from several radio driver implementations), and while parts of the model > come from me, Hauke is currently refining it. As for development it is > clear, that I can't be the only one working on it. > > I'm currently in the testing stage of 6LoWPAN but it is mostly done, but I > still need some kind of way to communicate with the transceiver module for > older boards (alternative would be to remove it, but for this we need #1772 > and #1733 merged and all boards moved to the low-level driver model). I > hope I have this done at the end of next week. > > All in all it's still a long way to the transport layer and to speed > things up, I thought some of you guys may want to help me. I tried to split > down the tasks at hand and assigned preliminary some people who might be > able to do it. If you do not want/can not do this task, please notify this. > Also if you want to take over a task do tell so too, please. Every > assignment with a question mark is not fixed yet. > > * Model (Martine? and Hauke) > * 6LoWPAN > - backwards compatibility with transceiver module (Martine) > - bug-hunting (Martine) > - ND according to https://tools.ietf.org/html/rfc6775 (Martine?, > depends on a running ND for IPv6) > - optional: Next header compression (Oleg?) > * IPv6 > - port to netapi and pktbuf and remove 6LoWPAN dependency (Martine?) > - consistent and extendable IPv6 Extension Header API (Martine?) > - consistent and extendable ICMPv6 API (Lotte?) > - Neighbor discovery according to http://tools.ietf.org/html/rfc4861 > (Martine?, depends maybe on ICMPv6 API, but can be done without it, I guess) > * Transport layer > - port to netapi and pktbuf (Cenk?) > > * optional tasks for full deprecation of `transceiver`: > - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?) > and CCNlite to netapi or netdev > - port boards that use cc110x to periph API or port cc110x_legacy and > cc110x_legacy_csma to netdev > - either removal or port to netdev of redbee-econotag > > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
Hi, On 11/05/14 18:15, Martine Lenders wrote: * Transport layer - port to netapi and pktbuf (Cenk?) Maybe we should think on how to use messaging with large buffers and adapt netapi accordingly? IMHO it would simplify a lot. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
Hi Martine! > I'm currently in the testing stage of 6LoWPAN but it is mostly done, but I > still need some kind of way to communicate with the transceiver module for > older boards (alternative would be to remove it, but for this we need #1772 > and #1733 merged and all boards moved to the low-level driver model). I > hope I have this done at the end of next week. I guess deprecating the old transceiver API completely would be the better approach. Probably the MSB-A2 (+AVSExtrem) and maybe the WSN430-v1_3b are the only somewhat relevant boards where a new driver is missing. But it's probably not too difficult to adapt it to #1772. > - optional: Next header compression (Oleg?) Sure, I can do this. > * Transport layer > - port to netapi and pktbuf (Cenk?) I'm also willing to provide support here, but won't have to much time to work on it directly. > * optional tasks for full deprecation of `transceiver`: > - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?) and > CCNlite to netapi or netdev Sounds doable to me from what I know about both stacks. > - port boards that use cc110x to periph API or port cc110x_legacy and > cc110x_legacy_csma to netdev See above. > - either removal or port to netdev of redbee-econotag The infamous econotag... Porting it to the new periph interface could be nice, but I would consider it as optional for the release. Cheers, Oleg -- I'm working on a bittorrent joke, but I only have about 30% and nobody's seeding! pgp41yDBg1cHY.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
Sorry for the many errors in grammar and spelling (and the missing complimentary close). Accidentaly hit the send button before reading through the mail again… Kind regards, Martine 2014-11-05 18:15 GMT+01:00 Martine Lenders : > Hi, > as discussed on the virtual meeting we aim to have the new network stack > running with the next release (end of November or before christmas). > Currently, I'm the only one directly involved into the development (appart > from several radio driver implementations), and while parts of the model > come from me, Hauke is currently refining it. As for development it is > clear, that I can't be the only one working on it. > > I'm currently in the testing stage of 6LoWPAN but it is mostly done, but I > still need some kind of way to communicate with the transceiver module for > older boards (alternative would be to remove it, but for this we need #1772 > and #1733 merged and all boards moved to the low-level driver model). I > hope I have this done at the end of next week. > > All in all it's still a long way to the transport layer and to speed > things up, I thought some of you guys may want to help me. I tried to split > down the tasks at hand and assigned preliminary some people who might be > able to do it. If you do not want/can not do this task, please notify this. > Also if you want to take over a task do tell so too, please. Every > assignment with a question mark is not fixed yet. > > * Model (Martine? and Hauke) > * 6LoWPAN > - backwards compatibility with transceiver module (Martine) > - bug-hunting (Martine) > - ND according to https://tools.ietf.org/html/rfc6775 (Martine?, > depends on a running ND for IPv6) > - optional: Next header compression (Oleg?) > * IPv6 > - port to netapi and pktbuf and remove 6LoWPAN dependency (Martine?) > - consistent and extendable IPv6 Extension Header API (Martine?) > - consistent and extendable ICMPv6 API (Lotte?) > - Neighbor discovery according to http://tools.ietf.org/html/rfc4861 > (Martine?, depends maybe on ICMPv6 API, but can be done without it, I guess) > * Transport layer > - port to netapi and pktbuf (Cenk?) > > * optional tasks for full deprecation of `transceiver`: > - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?) > and CCNlite to netapi or netdev > - port boards that use cc110x to periph API or port cc110x_legacy and > cc110x_legacy_csma to netdev > - either removal or port to netdev of redbee-econotag > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Refectoring the network stack
Hi, as discussed on the virtual meeting we aim to have the new network stack running with the next release (end of November or before christmas). Currently, I'm the only one directly involved into the development (appart from several radio driver implementations), and while parts of the model come from me, Hauke is currently refining it. As for development it is clear, that I can't be the only one working on it. I'm currently in the testing stage of 6LoWPAN but it is mostly done, but I still need some kind of way to communicate with the transceiver module for older boards (alternative would be to remove it, but for this we need #1772 and #1733 merged and all boards moved to the low-level driver model). I hope I have this done at the end of next week. All in all it's still a long way to the transport layer and to speed things up, I thought some of you guys may want to help me. I tried to split down the tasks at hand and assigned preliminary some people who might be able to do it. If you do not want/can not do this task, please notify this. Also if you want to take over a task do tell so too, please. Every assignment with a question mark is not fixed yet. * Model (Martine? and Hauke) * 6LoWPAN - backwards compatibility with transceiver module (Martine) - bug-hunting (Martine) - ND according to https://tools.ietf.org/html/rfc6775 (Martine?, depends on a running ND for IPv6) - optional: Next header compression (Oleg?) * IPv6 - port to netapi and pktbuf and remove 6LoWPAN dependency (Martine?) - consistent and extendable IPv6 Extension Header API (Martine?) - consistent and extendable ICMPv6 API (Lotte?) - Neighbor discovery according to http://tools.ietf.org/html/rfc4861 (Martine?, depends maybe on ICMPv6 API, but can be done without it, I guess) * Transport layer - port to netapi and pktbuf (Cenk?) * optional tasks for full deprecation of `transceiver`: - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?) and CCNlite to netapi or netdev - port boards that use cc110x to periph API or port cc110x_legacy and cc110x_legacy_csma to netdev - either removal or port to netdev of redbee-econotag ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
