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
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://li
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] 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 >>> L
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] 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] 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] Updates to the build system - modules definition
Hiho Gaetan, wasn't it in particular that the current build system does not produce well-defined results in the sense that the outcome depends on the order and hidden interferences?? Wasn't it also that the current configuration system includes overloaded semantics and is thus rather intransparent?? These to me seemed to be the core issues?? Cheers, Thomas On 30/11/2017 22:27, Kaspar Schleiser wrote: Hi, On 11/30/2017 04:32 PM, Gaëtan Harter wrote: 1. Configuration is not documented 2. Information is not readable 3. Modules definition is scattered but in RIOT global files With these issues in mind, I propose to add parseable module meta-data definitions in a file in each module directory to first replace the existing information and then extend it to add more precise ones. How to do in practice it is still to be defined and discussed. When are you gonna take a look at my ninja-based build system? It solves 1-3 quite nicely, and more. You could save a lot of time. 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 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] 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
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] 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 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] 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] 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 <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
[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
[riot-devel] Ahoi SANE
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 sensor based on RIOT in a distributed urban sensing system based on JADEX -- 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] 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 : 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
Re: [riot-devel] To global seed or not to global seed
Hi Cenk, thanks for bringing this up! Can you add the POSIX perspective to the rand* calls? I guess it would be beneficial to remain close to what POSIX describes for an API. Cheers, Thomas On 08.03.2017 00:18, Cenk Gündoğan wrote: Dear RIOTers, for quite some time now we have semi-active discussions (mostly on GitHub) about various PRNG and seeding concepts. In this mail I merely want to focus on the scope of our PRNG implementations' seeds/states. Currently, all function calls in our PRNG implementations and the abstraction layer `sys/random` do *not* allow to pass a custom state. This means, there is *one* global state, that is overwritten with successive calls to `random_init()`, not necessarily from the same thread. At the moment, `auto_init` is the only instance, that calls `random_init` (albeit with `0`, but this is another story). So everything seems to be OK for now (?), but will it stay this way? In the current state, and to guarantee deterministic PRNG sequences, all calls to `random_init()` *must* be ignored, but not the first. Of course, this can be done in various ways .. 1) we can define it as BCP to *not* use `random_init()` if `auto_init` is used => it's hard to guarantee a one-time call to `random_init()` as human do surely err (especially if several nested modules are involved). 2) check within `random_init()` for an unitialized state and only initialize if such a state is prevalent. Ignore the call to `random_init()` if the PRNG was initialized before. => this introduces a further check that is done with each call to `random_init()` and feigns to the user a freshly initialized PRNG. In contrast to the current procedure of having a global state, we rather should opt to allow local states for each thread (not excluding a global state). Although I have no special use case in mind at the moment, I believe that it should be possible to let user applications initialize "their own PRNG" to produce deterministic sequences. With the current approach, the sequence of our PRNG is shared with all available threads. This means, a user application would share the sequence with the network stack's NDP, RPL, TCP, ... implementations. IMO, our random API needs to be extended to provide function definitions that also allow the passing of local seed states. However, different PRNGs use different kind / different numbers of seeds. A "local scope" seed struct would need to encapsulate enough information to be usable with all PRNGs; and that's the part that deserves some thinking. What is your opinion on having / allowing local scope seed states? Cheers, Cenk -- 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" 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" mailto:t.schm...@haw-hamburg.de>> Date: 8/18/2016 23:27 (GMT+01:00) To: RIOT OS kernel developers mailto:devel@riot-os.org>> Cc: Börje Ohlman mailto:borje.ohl...@ericsson.com>>, Joakim Borgh 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" 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, >>> >>> >>> >>> My question is about fragmentation support in IP in RIOT. Does IP in >>> RIOT support fragmentation? The use ca
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 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" Date: 8/18/2016 18:11 (GMT+01:00) To: 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, My question is about fragmentation support in IP in RIOT. Does IP in RIOT support fragmentation? The use case I am after is transferring a large blob of data (let’s say 5 kilobytes) on the UDP/IP stack in RIOT. Is that possible? I know that 6LoWPAN supports fragmentation but that is below the IP layer. I am interested in fragmentation at the IP layer so that application running over it in RIOT can send large data. Regards, Adeel -- 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 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] 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, My question is about fragmentation support in IP in RIOT. Does IP in RIOT support fragmentation? The use case I am after is transferring a large blob of data (let’s say 5 kilobytes) on the UDP/IP stack in RIOT. Is that possible? I know that 6LoWPAN supports fragmentation but that is below the IP layer. I am interested in fragmentation at the IP layer so that application running over it in RIOT can send large data. Regards, Adeel -- 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] Transfer media with RIOT-OS
Dear America, can you clarify this question a bit: What platform, network stack, and network technology do you use? What do you mean by 'media'? If you consider RIOT with the GENRC stack on an average constrained device (iotlab-m3 IoT-Board), then an IP throughput of about 10 Mbit/s can be achieved. If you add an 802.15.4 radio (e.g., Atmel AT86RF231) to the transmission chain, then performance drops down to about 100 kbit/s, which is somewhat natural. The conclusion from this: The RIOT GENRC stack is not a bottleneck in the IoT regime, so 'media' transmission should be as good as Layer 2 allows. Best, thomas On 14.07.2016 23:32, América Ramírez R. wrote: Dear Developers, Has anyone ever used RIOT-OS in order to transfer media? If so, please, would you comment about the throughput reached? Thank you for your time, Sincerely, America -- 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] 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] exhausted Travis
Hiho Kaspar, the ultimate goal is to do this best. If smlng can improve, that's fine. If not, you can blame him. In any case: Critical questions are always welcome. Cheers, thomas On 07.03.2016 22:35, Kaspar Schleiser wrote: Hey, seems like you don't like RIOT CI? Kaspar On 03/07/2016 10:33 PM, smlng wrote: Hey all, +1 for CI task force I'll be happy to contribute and help on this topic, for starters I created an initial wiki page and added some content [2]. Feel free to add and modify ... Best, Sebastian Am 06.03.2016 um 18:59 schrieb Oleg Hahm : Hi Kaspar, Adam, Nick, Cenk, Sebastian (and everyone else who offered her/his help here)! On Fri, Mar 04, 2016 at 12:56:06PM +0100, Kaspar Schleiser wrote: On 03/04/2016 11:44 AM, smlng wrote: @all: Do we need a CI-TaskForce? I guess we implicitly have people working on it, so yeah, let's formalize. I agree that this sounds like a good idea. I added an entry to the wiki page [1]. So, we need two persons who would volunteer to shepherd this task force. Kaspar, for starters, I listed you as a shepherd, please change this, if you don't want to lead this task force. Finally, I wanted to thank all of you who offered help or already contributed (in terms of hardware resources, manpower, and consulting) for this badly needed improvement! It's (once again) great to see the power and helpfulness of this community. Big thanks! Cheers, Oleg [1] https://github.com/RIOT-OS/RIOT/wiki/Task-Forces [2]: https://github.com/RIOT-OS/RIOT/wiki/CI-Task-Force-(CITF) ___ 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] 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] 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
[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] 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
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] 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 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/~schmidt Fax: +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] FIB redesign
Hi Martine, a FIB always only provides unique forwarding rules. So there are no priorities attached to FIB entries. Priorities of routes may occur in RIBs associated with routing protocols ... and a significant question is of course how to deal with competing routing protocols that feed the FIB. (Typically, these routing protocols split horizon according to IP address ranges.) Still, a routing protocol either overrides FIB entries or it doesn't. Cheers, Thomas On 18.11.2014 21:56, Martine Lenders wrote: Hi, it's me again, dumping my latest brainstorm into the thread :D. Don't we need some kind of priorities for the routing protocols, too? Or how does the FIB decide which next hop to choose if more than routing protocol made an entry pointing to it? Cheers, Martine 2014-11-17 8:05 GMT+01:00 Martin mailto:martin.landsm...@haw-hamburg.de>>: Hi Martine, >... Except you mean the routing protocol by this. yes, the `prot_id` is the actual used (running) protocol, i.e. RPL. This identifier must be unique for the running RIOT on the node, i.e. arbitrary but fixed for the lifetime. The "binding" of FIB table entries to a specific (running) protocol is necessary only for updates on them. Probably `kernel_pid_t` for the would be a waste of one byte for each FIB table entry. I will keep it `uint8_t` for now, but test a bit with `kernel_pid_t`. Best regards, Martin On 15.11.2014 02:03, Martine Lenders wrote: Hi Martin, 2014-11-14 15:23 GMT+01:00 Martin mailto:martin.landsm...@haw-hamburg.de>>: Hi Martine, I will change the interface and protocol IDs to `kernel_type_t` as you suggested. For the FIB handling perspective this seems also to be the best (and easiest) way to have the IDs unique on one RIOT/node. For protocol IDs I suggest `netdev_proto_t` [1]. Except you mean the routing protocol by this. It aims, at least regarding my design, to be the RIOT-global identifier for all network protocol RIOT supports. Cheers, Martine [1] https://github.com/RIOT-OS/RIOT/blob/038beb0f99215207c09fd862ac7712982cedb3ef/drivers/include/netdev/base.h#L57 ___ devel mailing list devel@riot-os.org <mailto:devel@riot-os.org> http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org <mailto: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 ° ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] FIB redesign
Hi Martine & Martin, following a personal discussion, the approach of multiple FIB tables (per IF / protocol) is off the table, now. There will and can be only one FIB. Important for the next steps are discussion and conclusion about a viable (internal) data structure for the FIB ... it seems there are trade-offs between memory and processing constraints. Marin shall present proposals for a thorough review discussion soon. Cheers, Thomas On 05.11.2014 15:10, Landsmann, Martin wrote: Hi all, I started a prototype implementation [1] under consideration of the diagram on the wiki page [2]. - It provides a generic address handling and access - a basic FIB table management (add, remove, update) - collision detection for next_hops and resolving the conflict based on a preference table - reactive RP signalling using `msg_send_receive()` This prototype is not included between any RP and the `get_next_hop()` right now. Best regards, Martin [1] git pull https://github.com/BytesGalore/RIOT add_fib [2] https://github.com/RIOT-OS/RIOT/wiki/Rough-sketch-of-a-possible-FIB-modularization On 04.11.2014 11:05, Martin wrote: Hi Martine, thx for the input :) > Are you planning to only consider stateless compression (Prefix is assumed link-local) or also stateful compression (Prefix is determined by a 4-bit context ID [1] ... I plan to make it more generic, e.g. allow for providing even proprietary "solutions" for FIB table entry compression. LOWPAN_IPHC provides wonderful mechanisms to save bytes in transmissions, but there are probably (most likely) more possibilities to save bytes on the individual nodes RAM when maintaining a FIB table. Eventually the FIB will "resolve" the applied compression to provide the type required by a `get_next_hop()` request. >... we might want to consider to put those information into the same data structure (so the later of my 2 suggestions above would be) Indeed, that would by great. That's the reason I want to outsource the "Generic address" from the FIB table entry. These blobs can be shared among processes, e.g. FIB, routing protocol and ND. Liftime invalidation and such is controlled by the individual process. For instance, an expired FIB table entry would mark its internal structure as invalid and decrease the usecount of the "Generic address". > Also: have you considered Mesh-under routing [5]? (Do we have to consider this here I wonder myself? We don't have support for it anyways, so far.) [6] states some requirements for this. No, I only considered to "play" at the network layer level for now. But I will have a look. Best Regards, Martin Hi, I finally came to it to read your suggestions, too. Regarding the fact that you keep 6LoWPAN header compression in mind, too: Are you planning to only consider stateless compression (Prefix is assumed link-local) or also stateful compression (Prefix is determined by a 4-bit context ID [1], disseminated through the PAN via the context identifier option in RS [2]). Since Neighbor Cache [3], Prefix Information [4], Forwarding information, and Context Information are all very related, and we may want to save memory, we might want to consider to put those information into the same data structure (so the later of my 2 suggestions above would be). Keep in mind though, that both Prefix Information Base and Context information Base have their own lifecycles (see regarding RFCs). Also: have you considered Mesh-under routing [5]? (Do we have to consider this here I wonder myself? We don't have support for it anyways, so far.) [6] states some requirements for this. Hope this was more helpful, than confusing ;-). Cheers, Martine [1] https://tools.ietf.org/html/rfc6282#section-3.1.2 [2] https://tools.ietf.org/html/rfc6775#section-4.2 [3] http://tools.ietf.org/html/rfc4861#section-5.1 [4] https://tools.ietf.org/html/rfc4861#section-4.6.2 [5] https://tools.ietf.org/html/rfc4944#section-11 [6] http://tools.ietf.org/html/rfc6606 ___ 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 ° ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel