Re: [riot-devel] LGPL compliance testing - This is just to state an opinion of a different kind :-)
Hi guys, sorry to interrupt here: You are discussing the question whether Linux is available for more hardware than RIOT ??? Even though this discussion may be a nice amusing chat for tea time (imagining a 'native port' of Linux running as a RIOT Thread, RIOT on a CRAY Supercomputer, RIOT operating the fridge of the Space Shuttle), it seems completely irrelevant with respect to the subject LGPL compliance testing. Instead of broadening the debate further and further, I would very much like to see this subject converge ... and vanish. If I remember correctly, we had a pretty convergent perspective about half a year ago ... and nothing new or relevant has sprung to my eyes since then. May be I miss important details ... but I'm actually more attached to moving forward than discussing in widest broadness. Cheers happy weekend Thomas On 20.02.2015 13:35, Emmanuel Baccelli wrote: Hi Matthias, On Thu, Feb 19, 2015 at 11:47 PM, Matthias Waehlisch m.waehli...@fu-berlin.de mailto:m.waehli...@fu-berlin.de wrote: Hi Kaspar, sorry for the silence! As you pointed out in your email, there are scenarios where the approach will not help due to technical reasons (and using a weird compiler might have technical reasons as well). You may consider these as irrelevant. But there is one aspect for sure in the IoT, the IoT is much more heterogenous compared to the current Internet. This is a crucial difference making the approach less suitable compared to developing for Linux, for example. For me the sentence RIOT allows LGPL + proprietary source code at the same level of comfort compared to Linux sounds like a cheap marketing slogan making clear that the persons are not aware of the IoT diversity. Linux runs on a wide variety of 32bit and 64bit hardware. RIOT aims to do the same on other (smaller) hardware, for a wide variety of 32bit, 16bit (and to some extent 8bit) platforms. At first sight, I don't see a huge difference here in terms of heterogeneity. How would you quantify/qualify this difference? Best Emmanuel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] [GSOC 2015] Project A2
Hi Samarth, yes, I agree with your analysis. One aspect I'd like to emphasize, though, is that with 'intelligence' we need distribution, i.e., the sensors need to talk to each other. Now for the discussion on the use case: You're perfectly right, if we predict we are operating under probabilities. First assumption is that the person continues moving and does not simply stop. Sometimes these probabilities are very high, for example, when a person walks down a hallway or opens a door. Sometimes these probabilities are lower, if a person can walk right or left for instance. Our use case is that we want (with some threshold) support continuous lightening on some price of energy consumption. Typically light sources (incl. the sensors) are not densely covering the area. In our university for example, I have to deeply enter a lecture hall until a sensor detects me and switches on the light. This is really unpleasant at complete darkness. It is also inconvenient, if people walk down a path and lights turn on too late. Then a steady change in brightness is affecting the vision. However, there is some tunable parameter (energy versus comfort) and there is learning potential (i.e., how often did a prediction succeed?). I guess this gives a rather rich field of building a solution that covers quite a number of aspects and focuses on the really exciting topic of a distributed intelligent system. Does this help? Best regards, Thomas On 09.03.2015 09:03, Samarth Bansal wrote: Hello! I just got across Project A2 : Intelligently interacting light switches. Sounds really interesting. I have a few questions: 1. The most naive approach I can think about it is this - When a motion detector sensor detects the presence of a person, the light turns on. 2. Now that we are adding intelligence - is it that basically we are trying to determine the path that a person might take and then turn on lights accordingly? Lets suppose that the particular person has an ID, and our devices have historical data about that person as well as of other people. So the path is determined by taking into context and giving apt weight to both forms of data - to predict a path. 3. If that is the case, I have a concern. As for any learning problem, we will be operating under probabilities. Given the nature of the problem in hand, there maybe multiple paths possible with high probability(Right?). For energy efficiency, we won't really like the lighting system to turn on all the probable lights. That is the precise reasons for having sensors. So how does the intelligent lighting system help? The hardware part looks simple. I guess that any micro-controller with a PIR motion sensor attachment and a bunch of LEDs should be good enough for prototyping. Although I think we can simulate the environment by laying down a graph of motion sensors and lights instead of setting up hardware. Does this make sense? Looking forward to the comments! Thanks, Samarth -- Samarth Bansal 4th Year Undergraduate Department of Mathematics and Statistics IIT Kanpur E-Mail: samar...@iitk.ac.in mailto:samar...@iitk.ac.in, samarthbansa...@gmail.com mailto:samarthbansa...@gmail.com Phone: +91-9871551169 Blog : samarthbansal.com/blog http://samarthbansal.com/blog -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] TLS
Hi Matthias, there is ongoing work on DTLS + additional authentication. There is also a port of the Relic library toolkit https://code.google.com/p/relic-toolkit/ including an extension for modern Edwards Curves (ECC). There should be also additional work, but I'm not sure about its status. Best, Thomas On 10.03.2015 21:11, Matthias Dübon wrote: Hello everyone, I just heard about the RIOT project and it seems very promising. I also heard some people are also working on some kind of security suite for RIOT. Could I have some more information about the idea and the status of that approach? best Matthias ᐧ ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Riot Software Update
Hi, yesterday in the IAB technical plenary, Hannes Tschofening stressed the need for system software maintenance. This raises the question: Have we spent enough thoughts on automated secure software updates for RIOT, are we approaching this subject? It might be some thing worth while considering?? Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Switch to BSD?
Hi Emmanuel, all, forgot to reply on this: We at HAW are fine with keeping LGPL license. So no conflict from our side. Best, Thomas On 22.03.2015 14:02, Emmanuel Baccelli wrote: Dear all, thanks for the input from everyone on this topic. It is a tough case to decide, based on our long and detailed exchanges on this subject. But it is probably time to conclude. At INRIA, we came up with the following observations: - there is no enthusiastic majority for a license change to BSD/MIT, - as solutions competing with RIOT are quasi-exclusively BSD/MIT, (L)GPL is a way to stand out positively. Concerning this last point, we observed that staying on the (L)GPL side strengthens our position comparing ourselves to Linux -- which has been one of our key non-technical arguments so far. Furthermore, studies such as [1] show that small companies and start-ups are going to determine IoT. More than bigger companies, such small structures need to spread development and maintenance costs for the kernel and all the software that is not their core business. Our analysis is that this is more compatible with (L)GPL than with BSD/MIT. We are of the opinion that, compared to BSD/MIT, (L)GPL will improve final user experience, security and privacy, by hindering device lock-down, favoring up-to-date, and field-updgradable code. We think this a more solid base to provide a consistent, compatible, secure-by-default standard system which developers can build upon to create trustworthy IoT applications. Last but not least, we think that (L)GPL is a better base than BSD/MIT to keep the community united in the mid and long run. For these reasons, even though we still believe a switch to BSD/MIT would facilitate RIOT's penetration rate initially, we want to continue releasing under LGPLv2.1. I also want to point out that even though this is basically status quo, we think this discussion was far from useless, because it helped clarify where we stand, and for what. From our point of view, the next steps are now to set up a non-profit legal entity for RIOT, and to put CLAs in place, allowing non-exclusive rights for the code to this legal structure. Best, Emmanuel [1] http://www.gartner.com/newsroom/id/2869521 -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] The border router wi^H^H is ready!
WOW - Watson is on his way! Cheers, Thomas On 17.09.2015 18:31, Oleg Hahm wrote: Ladies and gentlemen! I'm more than proud to announce that just a couple of minutes ago I sent the first successful ping from an iotlab-m3 node over a RIOT powered border router (running on a samr21-xpro) to my desktop PC and received its response! Let's celebrate this tonight! Cheers, Oleg P.S. Everything you need is included in my pre-release branch: https://github.com/OlegHahm/RIOT/tree/2015.09-RC0 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT+ULAs: no router entry
Hi, this may be. In any case, the erroneous behavior described by smlng should not depend on the use of ULAs. Proposal to smlng: Please use global unicast addresses and confirm the misbehavior. Strip off ULA from the discussion thereafter. Cheers, Thomas On 22.04.2016 12:33, Cenk Gündogan wrote: Hey, That sounds like the problem described in this issue [1]. The current master / release candidate version should include a "workaround" fix for that. Cheers, Cenk [1] https://github.com/RIOT-OS/RIOT/issues/5122 On 04/22/2016 12:19 PM, smlng wrote: Hi everyone, I'm testing COAP between RIOT on Phytec pba-d-01-kw2x and Linux on RasPi+Openlabs using ULA IP addresses. On the Pi I run a 'radvd' to advertise a ULA prefix to RIOT, which works: - RIOT sends RS after boot - the Pi answers with RA containing ULA prefix - RIOT configures ULA IP on 6lo iface COAP (or communication in general) via ULA IP works, as long as RIOT has the Pi in its routers cache. However, sometimes RIOT _forgets_ or does not set a routers entry for the Pi at all. In that case communication is not possible via ULAs, using link-local IPs works all the time. The issue seems be with the RS+RA processing. I found that sometimes RIOT does not create a routers entry on reception of a RA - though it does configure the ULA prefix correctly. I just had the case that RIOT configures the ULA _and_ sets a routers entry, hence communication was working. At least for about 15min, but then RIOT send another RS, Pi answers with RA, RIOT still has ULA IP configured -- BUT the routers entry for the Pi is gone and communication fails. Again: using link-local IPs still works. Btw. even when communication via ULAs is working, RIOT never creates a ncache entry for ULA IP of the Pi but it did create an ncache entry for link-local IP of the Pi. I thought the latter is not required/allowed in 6lo but for ULAs it should create an entry? Has somebody else observed this behavior or any hints how to resolve this? Thanks, best Sebastian ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Global IPV6
Hi Baptiste, are you in search for a trigger that fires every time a new prefix is advertised/seen? Or do you refer to the event of a new IPv6 interface being configured? Cheers, Thomas On 13.07.2016 16:51, Baptiste Clenet wrote: Hi, How can I be informed that my node has got a new global IPV6? I would like to call a function every time the node get a new global IPV6 address. How can I do that? Cheers, -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Fragmentation support in IP
Hi Martine, Adeel, there had been proposals in 6LowPan + Roll by Pascal Thubert for adding reliability to 6LowPan (recovering fragments) ... but if I see things correctly, they have never gotten anywhere -> Carsten? In any case, the design discussion seems a bit out of focus: Whether to design a L2 protocol or an application layer (on top of CoAP) should be sorted out first. I guess these things depend on the problem scope and the objectives. Cheers, Thomas On 19.08.2016 09:56, Martine Lenders wrote: Hi Adeel, What do you mean by "lost fragment recovery"? To my knowledge there is no such thing in 6LoWPAN fragmentation. Regards, Martine Am 19.08.2016 12:59 vorm. schrieb "Adeel Mohammad Malik" <adeel.mohammad.ma...@ericsson.com <mailto:adeel.mohammad.ma...@ericsson.com>>: Hi again Thomas, Do you mean that 6LoWPAN in RIOT does not support lost fragment recovery? Assuming it does, what I had in mind was that we could segment data in the application to the IP MTU and leverage the lost fragment recovery feature in 6LoWPAN to get a decent performance. This way we may not need to implement lost segment recovery in the application. But if 6LoWPAN in RIOT does not support recovery of lost fragments we might as well run our application direclty on link layer (since we dont need IP routing). /Adeel Original message ---- From: "Thomas C. Schmidt" <t.schm...@haw-hamburg.de <mailto:t.schm...@haw-hamburg.de>> Date: 8/18/2016 23:27 (GMT+01:00) To: RIOT OS kernel developers <devel@riot-os.org <mailto:devel@riot-os.org>> Cc: Börje Ohlman <borje.ohl...@ericsson.com <mailto:borje.ohl...@ericsson.com>>, Joakim Borgh <joakim.bo...@ericsson.com <mailto:joakim.bo...@ericsson.com>> Subject: Re: [riot-devel] Fragmentation support in IP Hi Adeel, adding to this: you should keep in mind that in LowPANs you may easily trigger multiple layers of fragmentation (loosing one fragment is loosing all!) ... and that receivers may not be ready to handle UDP datagrams of 'arbitrary' sizes. So if you really want to stay away from upper layer protocols like CoAP, you should process data segmentation in your application (not sure this is the best idea, though). Cheers, Thomas On 18.08.2016 22:54, Carsten Bormann wrote: > Hi Adeel, > > IP fragmentation is usually a bad idea*), and more so on a constrained > network. If you need to transfer payloads beyond a kilobyte or so, > maybe CoAP (RFC 7252) with the block-wise transfer protocol (currently > being published as RFC-to-be 7959) solves your problem. > > Which encryption expands a few bytes of plaintext to kilobytes of > ciphertext? (You may be thinking about signatures; e.g., hash-based > signatures can be 3-6 KiB or even more. These might occur in firmware > updates and are covered quite well by CoAP + block-wise.) > > Grüße, Carsten > > *) > https://tools.ietf.org/html/draft-mathis-frag-harmful-00 <https://tools.ietf.org/html/draft-mathis-frag-harmful-00> > http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf <http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf> > > Adeel Mohammad Malik wrote: >> Hi Thomas, >> >> I agree that IP fragmentation is not an equivalent for data streaming. >> However it still facilitates transporting data that exceeds the MTU. The >> use case we are looking at is encryption of IoT data that may result in >> a few bytes of plaintext being converted to a few kilobytes of >> ciphertext. Had IP supported fragmentation in RIOT it would have been >> possible for us to send such data. >> >> /Adeel >> >> >> Original message >> From: "Thomas C. Schmidt" <t.schm...@haw-hamburg.de <mailto:t.schm...@haw-hamburg.de>> >> Date: 8/18/2016 18:11 (GMT+01:00) >> To: devel@riot-os.org <mailto:devel@riot-os.org> >> Subject: Re: [riot-devel] Fragmentation support in IP >> >> Hi Adeel, >> >> GNRC in RIOT supports fragmentation, e.g. in the context of 6LowPAN. >> >> However, you seem to be interested in sending UDP datagrams that exceed >> the MTU payload size. I don't think this is common use ... and I don't >> think this is clever, either. IP fragmentation is not an equivalent for >> data streaming. >> >> Cheers, >> Thomas >> >> On 18.08.2016 18:04, Adeel Mohammad Malik wrote: >>> Hi all, >>&
[riot-devel] RIOT App Store - Hiring Lead Developers in Berlin and Hamburg
Dear RIOTers, the two RIOT labs FU-Berlin and HAW-Hamburg are about to start the new project of a RIOT App Store. RAPstore shall provide configurable software tailored to the needs of IoT application providers. Two teams of three developers each are scheduled to bring this project to reality and make it useful for the community. Currently, we are hiring the technical leads for both teams. We offer a 3 years contract (German TVL E13) with annual salary ranging from 45.000 - 65.000 €, depending on experience. For more information and applications, please contact Berlin: Matthias - m.waehli...@fu-berlin.de Hamburg: Thomas - t.schm...@haw-hamburg.de or both of us. Please help to distribute this call to those who could be interested. Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] To global seed or not to global seed
Hi Oleg, Ludwig, On 08.03.2017 10:30, Oleg Hahm wrote: Hi Ludwig! On Wed, Mar 08, 2017 at 10:28:13AM +0100, Ludwig Knüpfer wrote: Am 8. März 2017 10:21:15 MEZ schrieb Oleg Hahm <oliver.h...@inria.fr>: Is testing and simulation the only use case you can imagine? I'm somewhat reluctant to add code just for non-production purposes. Since we outspokenly target researchers with RIOT this is a production feature. However we might want to move this feature into a dedicated implementation of the same interface. Thanks, that was more or less what I meant. I'm not sure whether we 'over-complicate' the issue. There are good PRNGs with state space of one (or very few) int, call it seed. So if this function is called as 'rand(seed)', rand can be stateless ... and seed is allocated memory of the application. Seeds could be initially generated by 'random_init(seed)'. At the same time, one can overload with a stateful 'rand()' which is auto-initialized and convenient ... and for those who don't care for more control. IMO, this would not need a 'random_init()' user call. Cheers, Thomas Btw: David Jones (UCL Bioinformatics) writes "Rule #1: Do not use system generators. ... Almost all of these generators are badly flawed. Even when they are not, there is no guarantee that they were not flawed in earlier releases of the library." -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Ahoi SANE
### sorry, a premature version of this mail suffered from early escape # Dear RIOTers, this is to announce SANE, a new project initiative and collaboration with the University of Hamburg - one of four flagship projects chosen to advance the digital strategy of the state of Hamburg. SANE - "Smart Networks for Urban Citizen Participation" will integrate and deploy smart private sensors based on RIOT in a distributed urban sensing system based on JADEX https://www.activecomponents.org. JADEX is a successful agent platform created by UniHH. It will in particular link RIOT to JADEX and foster the RIOT-based availability of urban sensors. Starting in early 2018, this project will provide the opportunity of applied research positions (TVL/E13 full-time or part-time) in the field - so please feel free to contact me in case you are interested to work or collaborate. A PhD option is provided. Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Graphing build sizes
Hi Koen, really great: please let us know once you are ready for a deployment. Best, thomas On 11/10/2017 17:10, Martine Lenders wrote: Hi Koen, Wow, +1! Cheers, Martine 2017-10-11 16:59 GMT+02:00 Koen Zandberg <k...@bergzand.net <mailto:k...@bergzand.net>>: Hello, One of the issues from the CI discussion at the RIOT summit was the tracking and graphing of the nightly build sizes. After some instructions from Kaspar for getting the JSON files I got something working here: https://riot-graphs.snt.utwente.nl/dashboard/db/demonstrator?orgId=1 <https://riot-graphs.snt.utwente.nl/dashboard/db/demonstrator?orgId=1> For now I want to keep it up to date by running my script as a cron every night approximately after the nightly build. The source code of the script that parses and pushes the values to the database can be found at my github [1]. The dashboard is now a simple Grafana templated dashboard where a test and a board can be selected. I'd like to expand this by creating a dashboard for every test or for every board. The most difficult thing for now is to present the huge amount of data in a clear and concise way. Input on this and the overview in general is most welcome. Koen [1]: https://github.com/bergzand/RIOT-graphs <https://github.com/bergzand/RIOT-graphs> ___ devel mailing list devel@riot-os.org <mailto:devel@riot-os.org> https://lists.riot-os.org/mailman/listinfo/devel <https://lists.riot-os.org/mailman/listinfo/devel> -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Updates to the build system - modules definition
Hi Dan, Gaetan, I wonder, what problems are we trying to solve? Maybe we can clearly enumerate them first so that we can check later, whether an improved solution really solves these problems. Cheers, Thomas On 24/11/2017 16:47, Daniel Petry wrote: Hi Gaetan I would like to introduce some packaging concepts around RIOT. To consider modules like well defined distribution packages and not only source files added to an application firmware. From what you're saying, I understand that the aim is to make modules completely self-contained with respect to build definitions, and make those definitions much more human readable. In this way, an application developer can go to only one place to find out information regarding a module's build (dependency information, etc.), and a module developer only has to write/change the module directory Makefile and can do so with declarative language. Also, the information can be easily parseable for eg a user interface. So the changes you're proposing are: 1) Move build information concerning a particular module into that module's Makefile 2) Make the module makefiles able to be written with purely declarative language 3) Retain backwards compatibility with the current build system Is this correct? I think 2) would be great for user friendliness, and 3) is a no-brainer. 1) is a bigger topic as there are a number of different ways in which dependencies are manifested for example, so I think this can be a point for further discussion... do you have any particular examples? Dan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Gnrc Router Solicitation Messages (Thomas C. Schmidt)
Hiho, to be more explicit: a Router Solicitation Messages should be sent out immediately after a link comes up. This usually happens by link triggers from the interface. Best, Thomas On 30/10/2017 14:27, smlng wrote: Hi Francisco, On 30. Oct 2017, at 14:21, Francisco Molina <francisco.mol...@inria.cl> wrote: It's not really that i wan't to change the interval. The thing is my node goes into deep sleep and to be battery efficient I need Router Solicitation Messages to go out as soon as it wakes up, which is not happening with gnrc default set-up. That's why I was asking how I can trigger one in the cleanest way. Cheers, Actually, you shouldn't need to trigger a RS explicitly. This should happen automatically within RIOT, i.e., send an RS whenever a link gets ready, which also applies to wake up from sleep. Hence, (IMHO) this needs to be fixed in the network stack. @miri64 might know the right place? Anyhow, if not already done: please open an issue addressing and describing this issue, so we have it officially and trackable. Best, Sebastian ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] rfq commercial additions to riot-os
Hi Richard, thanks for sharing your thoughts on the list! I'm not sure I fully understand your requirements, but believe that some are generically interesting for RIOT, e.g., running several/many 802.15.4 networks in parallel. What about this join/leave button? Best, Thomas On 31/10/2017 22:14, Richard Klingler wrote: Evnin' from \.ch (o; Some of you from #riot-os already know some backgrounds... I work for a company doing sanitary devices (basically anything controlling water) with IoT capabilities...currently WLAN/Ethernet connection only... To extend our portfolio we would like to switch over to 802.15.4 network... Target areas would be for example hospitals with hundres od WSN nodes per building. In the past I tested so far contiki, skipped totally tinyos and ended up with an easily setup riot-os network at home...which was the base to present to our CEO... We have already assigned a local company to do a WSN but they failed after half year to deliver anything useful. That's why I always kept a back plan from the beginning evaluating open source solutions... I got the OK today to ask here on this list for external men power to extend the already great riot-os capabilities with special features we would need to be successful in commercial/industrial fields, mainly: - run independant wsn side by side with not interfering each other - simple joining/leaving a node to/from a PAN with simple button press We would like early as possible..speaking...within two weeks (o; thanks in advance for listening and for the already great riot-os (o; davorin@#riot-os richard ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] rfq commercial additions to riot-os
Hi Richard, here is the other Thomas again. On 31/10/2017 23:41, Richard Klingler wrote: So you're saying a node can participate even with two networks at the same time? Anyway... Yes, RIOT can handle multiple network interfaces and can speak with arbitrary neighbors from its neighbor cache. But what we a re mainly looking is to external manpower with a deeper riot-os knowledge to implement our needed features Either sponsoring to the project if a feature is of everyones interest or to a company doing specific features which is applicable mostly to our needs. Do you know of any company having knowledge/time/ doing such stuff? There are quite a number of people that (a) are generally working on advancing RIOT and (b) some are available for doing additional freelance work. So we should be able to help you in some way. Best, Thomas On Tue, 31 Oct 2017 15:35:52 -0700, Thomas Eichinger wrote: Hi Richard, On 31 Oct 2017, at 14:42 PDT(-0700), Richard Klingler wrote: Hmm.. I see you sometimes joining/leaving #riot-os (o; That might be me, different Thomas. ;) Yes the different networks is very interesting...and definitively a need not sure if it is easily done like adding a second interface on UNIX with a simple ifconfig (o; Having two network interfaces is already possible with RIOT as well as RIOT provides a ifconfig command for configuration. The button thing...don't have to be a button..and is also not always possible... Let's say you want to deploy a new network Idea is like all nodes have a default PAN as the firmware is all the same (more or less). You start deploying the network from the border router away by pressing a button which tells it to start a join procedurefor example by broadcasting on that PAN a message like "who ever wants to joing my new network with PAN ID xxx, you have 5 minutes time" Then on the the next node you press also a button, which then listens on the default PAN and accepts then the new PAN advertised by the router node... A leave would be then like pressing the button for 5 seconds...putting it back into the default PAN If I understand your scenario correctly, what you are suggesting involves a 802.15.4 coordinator announcing PAN or channel changes and/or manages hardware addresses. I started a discussion on this topic recently but for now RIOT is still missing these "runtime" features. Please be aware though that, to the best of my knowledge, nothing in the standard keeps a device from starting to communicate on a certain channel with a certain PAN ID at any point in time. Best, Thomas On Tue, 31 Oct 2017 22:28:09 +0100, Thomas C. Schmidt wrote: Hi Richard, thanks for sharing your thoughts on the list! I'm not sure I fully understand your requirements, but believe that some are generically interesting for RIOT, e.g., running several/many 802.15.4 networks in parallel. What about this join/leave button? Best, Thomas On 31/10/2017 22:14, Richard Klingler wrote: Evnin' from \.ch (o; Some of you from #riot-os already know some backgrounds... I work for a company doing sanitary devices (basically anything controlling water) with IoT capabilities...currently WLAN/Ethernet connection only... To extend our portfolio we would like to switch over to 802.15.4 network... Target areas would be for example hospitals with hundres od WSN nodes per building. In the past I tested so far contiki, skipped totally tinyos and ended up with an easily setup riot-os network at home...which was the base to present to our CEO... We have already assigned a local company to do a WSN but they failed after half year to deliver anything useful. That's why I always kept a back plan from the beginning evaluating open source solutions... I got the OK today to ask here on this list for external men power to extend the already great riot-os capabilities with special features we would need to be successful in commercial/industrial fields, mainly: - run independant wsn side by side with not interfering each other - simple joining/leaving a node to/from a PAN with simple button press We would like early as possible..speaking...within two weeks (o; thanks in advance for listening and for the already great riot-os (o; davorin@#riot-os richard ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list dev
Re: [riot-devel] IPSEC/IKEv2
Hi Baptiste, as far as I remember, Tobias Guggemos http://www.mnm-team.org/~guggemos/ from LMU Munich was working on this. Plese back check with him. Cheers, Thomas On 03/07/2018 08:50, Baptiste Clenet wrote: Hi, Is there any implementation of IPSEC/IKEv2 in RIOT network stack? Has anyone planned to implement it? Cheers, -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Gnrc Router Solicitation Messages
Hi, why would you want to change the router solicitation interval (RTR_SOLICITATION_INTERVAL) outside the scope foreseen by the RFC? Thomas On 26/10/2017 16:58, Francisco Molina wrote: Dear Devel's, I need to change the frequency on which router solicitation messages are sen't or manually trigger them. I've found I can do this by modifying GNRC_SIXLOWPAN_ND_RTR_SOL_INT at sys/include/net/gnrc/sixlowpan/nd.h. But since the default value is already the minimum value specified by the RFC I'm wandering what would be the cleanest way to force a router solicitation message. Thanks in advance, cheers! Francisco -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Cortex M33 support
Hi Juan, thanks for pointing out: I'll try and check with our contacts to NXP. Best, Thomas On 17/10/2018 14:17, Juan Ignacio Carrano wrote: Hi everyone, Is anybody working / wanting to work on Cortex M33 support? Currently there are no chips available for the general public. AFAICT Nordic and NXP are the only ones with pre-production parts. I'm trying to get samples from both. It would be great if we could have at least some basic support for when the devices reach the market. Also, if somebody has closer contact with either Nordic or NXP, it would be great. Regards, Juan Ignacio Carrano ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
Hi Joakim, On 17/12/2018 09:37, Joakim Nohlgård wrote: Thank you for your answer. OK I think I understand what you mean, but is this really the correct behavior? It was certainly unexpected to me to have the packets go out the default route instead of on the interface with the configured prefix. I will try to elaborate: I have a prefix 2001:db8::/64 configured for the wireless interface. When I run ping6 2001:db8::1234 from the shell on the RIOT node, I expect the system to first attempt to find 2001:db8::1234 on the interface which has been configured for that prefix, instead of immediately falling back and taking the default route when the destination does not already exist in the NIB neighbor table. I would expect so, too: This should be the correct routing decision and default routing is wrong. Sorry, I didn't see that in your previous mail. I'm not sure such fallback makes sense at all, if a specific, globally routable prefix is configured. If 2001:db8::1234 is not reachable via 2001:db8::/64, a 'destination unreachable' should be triggered. Cheers, thomas On Mon, Dec 17, 2018 at 9:11 AM Thomas C. Schmidt wrote: Hi Joakim, it appears that you are experimenting with a special case. Normally, a sending node decides on the outgoing interface based on the destination IP prefix. If you don't have a more specific routing entry, the default IF is correctly chosen in your case. After the interface is selected, the source needs to decide on the Layer2 framing. Most link-layer technologies use an addressing (802.3/11, 15.4 ...) and the MAC address is acquired via ND. In your case, you mention SLIP. A serial line interface does not use L2 addresses and does not need ND. Best, Thomas On 17/12/2018 08:59, Joakim Nohlgård wrote: Hi developers, When using the shell on the gnrc_border_router application trying to send to an unknown address with its designated prefix, the application does not send any neighbor solicitations on the wireless network. When I type ping6 2001:db8::1234 I expected that a neighbor solicitation query to go out on the interface that has been configured with the routing destination for 2001:db8::/64, but wireshark shows that nothing is sent on the wireless, but instead the ICMPv6 packet is sent immediately over the slip/ethos interface, which is configured as the default route. Is this behavior correct or is this a routing bug? Configurations: ifconfig Iface 6 HWaddr: 02:DA:F1:03:BC:48 MTU:1500 HL:64 RTR RTR_ADV Source address length: 6 Link type: wired inet6 addr: fe80::da:f1ff:fe03:bc48 scope: local TNT[1] inet6 addr: fe80::2 scope: local VAL inet6 group: ff02::2 inet6 group: ff02::1 inet6 group: ff02::1:ff03:bc48 inet6 group: ff02::1:ff00:2 Iface 7 Channel: 26 Page: 0 NID: 0x23 Long HWaddr: 23:31:53:29:36:B7:6E:5A TX-Power: 0dBm State: IDLE max. Retrans.: 3 CSMA Retries: 4 ACK_REQ CSMA MTU:1280 HL:64 RTR RTR_ADV IPHC Source address length: 8 Link type: wireless inet6 addr: fe80::2131:5329:36b7:6e5a scope: local VAL inet6 addr: 2001:db8::2131:5329:36b7:6e5a scope: global VAL inet6 group: ff02::2 inet6 group: ff02::1 inet6 group: ff02::1:ffb7:6e5a routing: nib route 2001:db8::/64 dev #7 default* via fe80::1 dev #6 Best regards, Joakim ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
Hi Joakim, it appears that you are experimenting with a special case. Normally, a sending node decides on the outgoing interface based on the destination IP prefix. If you don't have a more specific routing entry, the default IF is correctly chosen in your case. After the interface is selected, the source needs to decide on the Layer2 framing. Most link-layer technologies use an addressing (802.3/11, 15.4 ...) and the MAC address is acquired via ND. In your case, you mention SLIP. A serial line interface does not use L2 addresses and does not need ND. Best, Thomas On 17/12/2018 08:59, Joakim Nohlgård wrote: Hi developers, When using the shell on the gnrc_border_router application trying to send to an unknown address with its designated prefix, the application does not send any neighbor solicitations on the wireless network. When I type ping6 2001:db8::1234 I expected that a neighbor solicitation query to go out on the interface that has been configured with the routing destination for 2001:db8::/64, but wireshark shows that nothing is sent on the wireless, but instead the ICMPv6 packet is sent immediately over the slip/ethos interface, which is configured as the default route. Is this behavior correct or is this a routing bug? Configurations: ifconfig Iface 6 HWaddr: 02:DA:F1:03:BC:48 MTU:1500 HL:64 RTR RTR_ADV Source address length: 6 Link type: wired inet6 addr: fe80::da:f1ff:fe03:bc48 scope: local TNT[1] inet6 addr: fe80::2 scope: local VAL inet6 group: ff02::2 inet6 group: ff02::1 inet6 group: ff02::1:ff03:bc48 inet6 group: ff02::1:ff00:2 Iface 7 Channel: 26 Page: 0 NID: 0x23 Long HWaddr: 23:31:53:29:36:B7:6E:5A TX-Power: 0dBm State: IDLE max. Retrans.: 3 CSMA Retries: 4 ACK_REQ CSMA MTU:1280 HL:64 RTR RTR_ADV IPHC Source address length: 8 Link type: wireless inet6 addr: fe80::2131:5329:36b7:6e5a scope: local VAL inet6 addr: 2001:db8::2131:5329:36b7:6e5a scope: global VAL inet6 group: ff02::2 inet6 group: ff02::1 inet6 group: ff02::1:ffb7:6e5a routing: nib route 2001:db8::/64 dev #7 default* via fe80::1 dev #6 Best regards, Joakim ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] New Directions in Testing for RIOT
Dear RIOTers, in the continuous efforts to improve the quality of the RIOT OS software, our group in Hamburg put recent efforts in improving automated testing. One focal task was to introduce Hardware-in-the-Loop (HiL) testing as a standard nightly procedure exposing an (increasing) number of boards to an (increasing) number of tests. As of today, I2C and UART are deployed, but we hope to grow test coverage quickly with your help. While developing test strategies, we identified a lack of an expressive testing framework. Along this line, we investigated Pytest and Robot Framework. Current discussions on GitHub indicate that Robot is the advanced choice for reasons documented in https://github.com/RIOT-OS/RIOT/issues/10241. This work raised several areas of discussion on which we want to solicit your feedback and rough consensus of the RIOT community: *HiL Testing:* The nightly HiL testing is deployed and displayed here: https://ci.riot-os.org/nightlies.html (click on "HIL test results"). The corresponding PR on I2C testing is https://github.com/RIOT-OS/RIOT/pull/10147 *Choice of Framework:* A comparison of frameworks and an initial discussion has been started. Please provide your feedback and comments here: https://github.com/RIOT-OS/RIOT/issues/10241 *Presentation:* The initial presentation was chosen to support a quick overview, but allow for a detailed exploration of tests and results on the Web. It certainly can be improved. Please provide your feedback and comments here: https://github.com/RIOT-OS/RobotFW-frontend/issues/1 Many thanks for your input - and keep RIOTing! Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
Hi Martine,
On 17/12/2018 11:17, Martine Lenders wrote:
at first glance this seems to be indeed a bug. If the prefix
`2001:db8::/64` is configured for one interface, this should be hint
enough for the NDP to use that interface to multicast the NS there. I'll
investigate that.
However, I have to add that RFC 6775 (which applies for the border
router) makes the neighbor discovery very destination-oriented (so
typically NS are only send upstream performing address registration with
the upstream router). So that might also be a legitimate behavior, as
downstream nodes should usually be registered via Address registration
with the border router or at least a route should be configured to the
downstream node with a routing protocol of your choosing ;-).
Yes, but forwarding to the default upstream should be a failure in this
case: The packet would then come back from upstream in a loop.
Cheers,
Thomas
Am Mo., 17. Dez. 2018 um 10:13 Uhr schrieb Thomas C. Schmidt
mailto:t.schm...@haw-hamburg.de>>:
Hi Joakim,
On 17/12/2018 09:37, Joakim Nohlgård wrote:
> Thank you for your answer. OK I think I understand what you mean, but
> is this really the correct behavior?
> It was certainly unexpected to me to have the packets go out the
> default route instead of on the interface with the configured prefix.
>
> I will try to elaborate:
> I have a prefix 2001:db8::/64 configured for the wireless interface.
> When I run ping6 2001:db8::1234 from the shell on the RIOT node, I
> expect the system to first attempt to find 2001:db8::1234 on the
> interface which has been configured for that prefix, instead of
> immediately falling back and taking the default route when the
> destination does not already exist in the NIB neighbor table.
>
I would expect so, too: This should be the correct routing decision and
default routing is wrong. Sorry, I didn't see that in your previous
mail.
I'm not sure such fallback makes sense at all, if a specific, globally
routable prefix is configured. If 2001:db8::1234 is not reachable via
2001:db8::/64, a 'destination unreachable' should be triggered.
Cheers,
thomas
> On Mon, Dec 17, 2018 at 9:11 AM Thomas C. Schmidt
> mailto:t.schm...@haw-hamburg.de>> wrote:
>>
>> Hi Joakim,
>>
>> it appears that you are experimenting with a special case.
>>
>> Normally, a sending node decides on the outgoing interface based
on the
>> destination IP prefix. If you don't have a more specific routing
entry,
>> the default IF is correctly chosen in your case.
>>
>> After the interface is selected, the source needs to decide on the
>> Layer2 framing. Most link-layer technologies use an addressing
>> (802.3/11, 15.4 ...) and the MAC address is acquired via ND. In your
>> case, you mention SLIP. A serial line interface does not use L2
>> addresses and does not need ND.
>>
>> Best,
>> Thomas
>>
>> On 17/12/2018 08:59, Joakim Nohlgård wrote:
>>> Hi developers,
>>> When using the shell on the gnrc_border_router application
trying to
>>> send to an unknown address with its designated prefix, the
application
>>> does not send any neighbor solicitations on the wireless network.
>>> When I type ping6 2001:db8::1234 I expected that a neighbor
>>> solicitation query to go out on the interface that has been
configured
>>> with the routing destination for 2001:db8::/64, but wireshark shows
>>> that nothing is sent on the wireless, but instead the ICMPv6
packet is
>>> sent immediately over the slip/ethos interface, which is
configured as
>>> the default route.
>>>
>>> Is this behavior correct or is this a routing bug?
>>>
>>> Configurations:
>>>> ifconfig
>>> Iface 6 HWaddr: 02:DA:F1:03:BC:48
>>> MTU:1500 HL:64 RTR
>>> RTR_ADV Source address length: 6
>>> Link type: wired
>>> inet6 addr: fe80::da:f1ff:fe03:bc48 scope: local
TNT[1]
>>> inet6 addr: fe80::2 scope: local VAL
>>> inet6 group: ff02::2
>>> inet6 group: ff02::1
>>> inet6 group: ff02::1:ff03:bc48
>>> inet6 group: ff02::1:ff00:2
>>>
>>> Iface 7 Channel: 26 Page: 0 NID: 0x23
>>> Long HWaddr: 23:31:53:29:36:B7:
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hi, if this is a "problem statement and design document", then concise and measurable requirements on power management should go into the corresponding section. Also, a clear and falsifiable problem statement should be given. This should IMO address the question, why timer problems cannot be fixed by simply repairing the xtimer (+ underlying HW abstractions). A long list of ztimer promises appears rather unessential and confusing. Thomas On 09/12/2019 17:45, Kaspar Schleiser wrote: Hi, On 12/9/19 4:52 PM, Kaspar Schleiser wrote: Hi Robert, On 12/9/19 4:25 PM, Robert Hartung wrote: Do we need to put any thoughts in power management / low_power / integration with pm_layered? Or are the possible issues addreses / already talked about? Yes and yes. ;) I'll my thoughts so far. I've added this to the wiki page: # Power management considerations - currently, ztimer is pm_layered agnostic. If a timer is set on a periph_timer, this would probably not prevent sleep (timer would not trigger), whereas if a ztimer is set on a rtt, it would behave as expected (timer hardware keeps running in sleep, timer isr wakes up MCU). - (TODO) if a timeout has been set (e.g., `ztimer_set(clock, timeout)`), the backend device blocks sleeping if necessary. IMO this is the minimum requirement, but still needs to be implemented. - Idea: we specify that by convention, ZTIMER_MSEC (and ZTIMER_SEC) *keep running in sleep mode*, whereas ZTIMER_USEC stops when the MCU enters sleep (unless a timeout is scheduled). This is current behaviour *if* ZTIMER_USEC is using periph_timer as backend and ZTIMER_MSEC is using RTT/RTC. This would mean that `before = ztimer_now(clock); do something; diff = ztimer_now(clock) - before;` only works if either `do_something` does not schedule away the thread causing sleep *or* a clock is used that runs in sleep mode. - the behaviour could be accessible either through defines (ZTIMER_USEC_LPM_MODE or ZTIMER_USEC_DEEPSLEEP ...), *or* be made part of the ztimer API - in addition, we could add functions to explicitly tell the clocks to stay available until released, e.g., `ztimer_acquire(clock); before = ztimer_now(clock); do something; diff = ztimer_now(clock) - before; ztimer_release(clock);`. Once the "if timer is scheduled, don't sleep" is implemented, this could also be worked around by: `ztimer_set(clock, dummy, 0x); ...; ztimer_cancel(clock, dummy);` Feedback appreciated! Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hi Marian,
On 09/12/2019 20:06, Marian Buschsieweke wrote:
Also, a clear and falsifiable problem statement should be given.
could you elaborate on what you mean by a problem statement being falsifiable?
"falsifiable" is a standard principle in science: It is sometimes
difficult to verify a statement, if application contexts cannot be
exhaustively enumerated ("It never rains in California"). Falsification
is often simpler, since only a counter-example is needed. A statement
that is neither verifiable nor falsifiable is useless for rigorous
argumentation.
"RIOT needs an easy to use, efficient and flexible timer system" is such
a poster child of a non-arguable statement and may move to the introduction.
Regarding xtimer:
If the current 1 us resolution in the API is the key problem, then this
should be stated clearly in the problem statement so that it can be
questioned and discussed.
Best,
Thomas
Do you want to be able to check that a given problem cannot be solved by
existing features?
This should IMO address the question, why timer problems cannot be fixed by
simply repairing the xtimer (+ underlying HW abstractions).
The mayor issue is that the API uses a fixed 1 µs resolution. As an uint32_t in
1 µs resolution would overflow after ~72 minutes, an uint64_t is needed as a
direct consequence. This in turn results in the use of 64 bit arithmetic, which
is very ill suited on IoT devices, especially on 8 bit and 16 bit platforms.
Additionally, an API using 1µs resolution can be best implemented with fast
timer hardware. But those usually prevent any power saving modes. This is very
ill suited for the huge majority of IoT scenarios.
Simply changing xtimer to use an RTT instead would solve the power saving
issue. But RTTs usually operate at frequencies in the range of 1kHz -
32.678kHz. A base unit of 1µs makes very little sense in that case. And I'm
aware of places in RIOT that depend on xtimer having a resolution in the order
of microseconds; those would just break.
All those issues are direct consequences of the use of a fixed 1 µs resolution.
Allowing callers to specify the timer resolution would fix these. But that
requires an API change.
(All that reasoning is part of the wiki page already.)
Kind regards,
Marian
On Mon, 9 Dec 2019 18:48:39 +0100
"Thomas C. Schmidt" wrote:
Hi,
if this is a "problem statement and design document", then concise and
measurable requirements on power management should go into the
corresponding section.
Also, a clear and falsifiable problem statement should be given. This
should IMO address the question, why timer problems cannot be fixed by
simply repairing the xtimer (+ underlying HW abstractions).
A long list of ztimer promises appears rather unessential and confusing.
Thomas
On 09/12/2019 17:45, Kaspar Schleiser wrote:
Hi,
On 12/9/19 4:52 PM, Kaspar Schleiser wrote:
Hi Robert,
On 12/9/19 4:25 PM, Robert Hartung wrote:
Do we need to put any thoughts in power management / low_power /
integration with pm_layered? Or are the possible issues addreses /
already talked about?
Yes and yes. ;)
I'll my thoughts so far.
I've added this to the wiki page:
# Power management considerations
- currently, ztimer is pm_layered agnostic. If a timer is set on a
periph_timer, this would probably not prevent sleep (timer would not
trigger), whereas if a ztimer is set on a rtt, it would behave as
expected (timer hardware keeps running in sleep, timer isr wakes up MCU).
- (TODO) if a timeout has been set (e.g., `ztimer_set(clock, timeout)`),
the backend device blocks sleeping if necessary. IMO this is the minimum
requirement, but still needs to be implemented.
- Idea: we specify that by convention, ZTIMER_MSEC (and ZTIMER_SEC)
*keep running in sleep mode*, whereas ZTIMER_USEC stops when the MCU
enters sleep (unless a timeout is scheduled). This is current behaviour
*if* ZTIMER_USEC is using periph_timer as backend and ZTIMER_MSEC is
using RTT/RTC.
This would mean that `before = ztimer_now(clock); do something; diff =
ztimer_now(clock) - before;` only works if either `do_something` does
not schedule away the thread causing sleep *or* a clock is used that
runs in sleep mode.
- the behaviour could be accessible either through defines
(ZTIMER_USEC_LPM_MODE or ZTIMER_USEC_DEEPSLEEP ...), *or* be made part
of the ztimer API
- in addition, we could add functions to explicitly tell the clocks to
stay available until released, e.g., `ztimer_acquire(clock); before =
ztimer_now(clock); do something; diff = ztimer_now(clock) - before;
ztimer_release(clock);`.
Once the "if timer is scheduled, don't sleep" is implemented, this
could also be worked around by:
`ztimer_set(clock, dummy, 0x); ...; ztimer_cancel(clock,
dummy);`
Feedback appreciated!
Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mail
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hi Marian,
On 09/12/2019 21:00, Marian Buschsieweke wrote:
I'd like to point out that the research community has largely dismissed Karl
Poppers contribution to the demarcation problem, as largely accepted fields of
research are not falsifiable. E.g. the evolution theory cannot be falsified.
https://rationalwiki.org/wiki/Falsifiability_of_evolution ?
Maybe it is time for you to move on as well?
Well, if we give up rational argumentation, then we end up in blind
guesswork or insignificant conversation.
Statements such as "I really like my timer drift today!" are amusing,
but not helpful.
Cheers,
Thomas
On Mon, 9 Dec 2019 20:35:24 +0100
"Thomas C. Schmidt" wrote:
Hi Marian,
On 09/12/2019 20:06, Marian Buschsieweke wrote:
Also, a clear and falsifiable problem statement should be given.
could you elaborate on what you mean by a problem statement being falsifiable?
"falsifiable" is a standard principle in science: It is sometimes
difficult to verify a statement, if application contexts cannot be
exhaustively enumerated ("It never rains in California"). Falsification
is often simpler, since only a counter-example is needed. A statement
that is neither verifiable nor falsifiable is useless for rigorous
argumentation.
"RIOT needs an easy to use, efficient and flexible timer system" is such
a poster child of a non-arguable statement and may move to the introduction.
Regarding xtimer:
If the current 1 us resolution in the API is the key problem, then this
should be stated clearly in the problem statement so that it can be
questioned and discussed.
Best,
Thomas
Do you want to be able to check that a given problem cannot be solved by
existing features?
This should IMO address the question, why timer problems cannot be fixed by
simply repairing the xtimer (+ underlying HW abstractions).
The mayor issue is that the API uses a fixed 1 µs resolution. As an uint32_t in
1 µs resolution would overflow after ~72 minutes, an uint64_t is needed as a
direct consequence. This in turn results in the use of 64 bit arithmetic, which
is very ill suited on IoT devices, especially on 8 bit and 16 bit platforms.
Additionally, an API using 1µs resolution can be best implemented with fast
timer hardware. But those usually prevent any power saving modes. This is very
ill suited for the huge majority of IoT scenarios.
Simply changing xtimer to use an RTT instead would solve the power saving
issue. But RTTs usually operate at frequencies in the range of 1kHz -
32.678kHz. A base unit of 1µs makes very little sense in that case. And I'm
aware of places in RIOT that depend on xtimer having a resolution in the order
of microseconds; those would just break.
All those issues are direct consequences of the use of a fixed 1 µs resolution.
Allowing callers to specify the timer resolution would fix these. But that
requires an API change.
(All that reasoning is part of the wiki page already.)
Kind regards,
Marian
On Mon, 9 Dec 2019 18:48:39 +0100
"Thomas C. Schmidt" wrote:
Hi,
if this is a "problem statement and design document", then concise and
measurable requirements on power management should go into the
corresponding section.
Also, a clear and falsifiable problem statement should be given. This
should IMO address the question, why timer problems cannot be fixed by
simply repairing the xtimer (+ underlying HW abstractions).
A long list of ztimer promises appears rather unessential and confusing.
Thomas
On 09/12/2019 17:45, Kaspar Schleiser wrote:
Hi,
On 12/9/19 4:52 PM, Kaspar Schleiser wrote:
Hi Robert,
On 12/9/19 4:25 PM, Robert Hartung wrote:
Do we need to put any thoughts in power management / low_power /
integration with pm_layered? Or are the possible issues addreses /
already talked about?
Yes and yes. ;)
I'll my thoughts so far.
I've added this to the wiki page:
# Power management considerations
- currently, ztimer is pm_layered agnostic. If a timer is set on a
periph_timer, this would probably not prevent sleep (timer would not
trigger), whereas if a ztimer is set on a rtt, it would behave as
expected (timer hardware keeps running in sleep, timer isr wakes up MCU).
- (TODO) if a timeout has been set (e.g., `ztimer_set(clock, timeout)`),
the backend device blocks sleeping if necessary. IMO this is the minimum
requirement, but still needs to be implemented.
- Idea: we specify that by convention, ZTIMER_MSEC (and ZTIMER_SEC)
*keep running in sleep mode*, whereas ZTIMER_USEC stops when the MCU
enters sleep (unless a timeout is scheduled). This is current behaviour
*if* ZTIMER_USEC is using periph_timer as backend and ZTIMER_MSEC is
using RTT/RTC.
This would mean that `before = ztimer_now(clock); do something; diff =
ztimer_now(clock) - before;` only works if either `do_something` does
not schedule away the thread causing sleep *or* a clock is used that
runs in sleep mode.
- the beha
