Re: [riot-devel] Save the date: RIOT Summit 2018

[Carsten Bormann]

Guten Tag Matthias,

wir wollten gerade mal die Hotels für den RIOT-Summit buchen.

Denkste.  https://show.ibc.org

Das nächste mal nehmt Ihr Hannover während der HMI?
Berlin während der Grünen Woche oder der ITB?

Ich befürchte, das wird diesmal ohne uns stattfinden.
Sorry, das mir das nicht früher aufgefallen ist…

Grüße, Carsten


> On Mar 14, 2018, at 11:34, Matthias Waehlisch  
> wrote:
> 
> Dear RIOTers,
> 
>  after very successful RIOT Summits in 2016 and 2017, the third RIOT 
> Summit is scheduled for September 13-14, 2018 in Amsterdam.


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] CAN license question

[Carsten Bormann]

On Jul 28, 2018, at 13:12, Gunar Schorcht  wrote:
> 
> In this case, should no CAN device driver be available to prevent
> license violation by RIOT users?

We are not the patent police.   Having the software in a repository is not 
practicing any invention that may be under patent protection.  How people use 
this software is their decision.

(Compare the MP3 patents, which were used as a scarecrow for a while but really 
never have been in the way of open-source implementations.)

> Or should I implement the CAN device
> driver and give an important note as it is done by Espressif?

Now that is more interesting.

I am not a patent lawyer, and I have no idea if any of the patents that could 
potentially be relevant here are still in force in any jurisdiction we care 
about.  I’m not sure if there are people in the RIOT project that know more.  
We should definitely not be making legal representations that such patents 
exist, are still in force or are valid in the first place.  We don’t even know 
which jurisdiction a potential user of the software would fall under…  (Note 
that software patents are still formally illegal in Europe [1], this is just 
implemented in the narrowest way possible [actually, more narrow] by the 
courts.)

The only valid advice would be to say that there appears to be a heavy patent 
thicket around CAN and users might need to find out whether their usage of CAN 
in conjunction with the driver might be covered by any valid, still in-force 
patents in their jurisdiction.  That doesn’t help anyone very much (because we 
can’t), but at least avoids setting up a trap.

Espressif has deeper pockets and may be more in the need of “cover your ___” 
phrases.   (They may not actually *need* them, but may follow advice by a 
lawyer that they should include them just in case they might turn out to be 
useful.)

[Besides the potential patent claims, there may also be a trademark issue 
around CAN.]

Grüße, Carsten

[1] 
https://en.wikipedia.org/wiki/Software_patents_under_the_European_Patent_Convention

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] RIOT Summit is being streamed

[Carsten Bormann]

https://jitsi.tools.ietf.org/riot-berlin

Use Chrome (or Firefox) to join.

Please don’t forget to mute unless you want to ask a question!

Grüße, Carsten

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Ethos in Mac OS

[Carsten Bormann]

On 30 Jan 2017, at 18:03, Kaspar Schleiser <kas...@schleiser.de> wrote:
> 
> Hey,
> 
> On 01/30/2017 05:28 PM, Carsten Bormann wrote:
>>> Are you aware that ethos basically does the same as slipmux?
>> 
>> No, I wasn’t aware that it proposes to replace the unstructured “shell” 
>> interface with CoAP.
> 
> Well, actually it doesn't. It just allows to multiplex different
> channels over one serial interface, currently ethernet and a serial stream.

Right, in that sense it is similar to slipmux )except that we focused on IP 
packets instead of Ethernet packets — not yet sure why you’d want to do the 
latter).


> 
>> But maybe adding an Ethernet frame encapsulation to slipmux would be a good 
>> thing.
>> Beyond ICN, what are the applications for Ethernet frame encapsulation over 
>> serial?
> 
> It provides a simple method to get networking between a node connected
> via serial and the host box. CoAP can then be done on top (with probably
> IPv6 in between).

The point of doing CoAP over serial, with no IP in between, is that you can use 
it to configure the node, including IP.
(There is nothing in slipmux that would stop you from also doing CoAP over IP, 
of course, but the latter is not useful for initial basic node configuration, 
and IP may also get in the way of certain management and diagnostic operations 
that CoAP over serial would do well.)

Grüße, Carsten

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Ethos in Mac OS

[Carsten Bormann]

On 30 Jan 2017, at 17:23, Kaspar Schleiser  wrote:
> 
> Are you aware that ethos basically does the same as slipmux?

No, I wasn’t aware that it proposes to replace the unstructured “shell” 
interface with CoAP.

But maybe adding an Ethernet frame encapsulation to slipmux would be a good 
thing.
Beyond ICN, what are the applications for Ethernet frame encapsulation over 
serial?

Grüße, Carsten

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Semihosting

[Carsten Bormann]

On 21 Jan 2017, at 19:40, Anthony Merlino  wrote:
> 
>  I don't have an available UART on this board 

Hi,

I’m not sure I completely understand your question, but I have a question on my 
own:

We wrote the slipmux spec

https://tools.ietf.org/html/draft-bormann-t2trg-slipmux-00

so we can do diagnostics, configuration (including a form of shell access), as 
well as packet transfer over a single UART port.

Would that help in your case?

Grüße, Carsten

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] L2 Netstats

[Carsten Bormann]

Please have a look at RFC7388 when doing this:

     Definition of Managed Objects for IPv6 over Low-Power Wireless
     Personal Area Networks (6LoWPANs). J. Schoenwaelder, A. Sehgal, T.
     Tsou, C. Zhou. October 2014. (Format: TXT=53451 bytes) (Status:
     PROPOSED STANDARD) (DOI: 10.17487/RFC7388) 

The writing on the package says its SNMP, but the important thing is the 
definition of the counters, which have wider applicability.

Grüße, Carsten

On 1 November 2016 at 16:04:46, Oleg Hahm (oliver.h...@inria.fr) wrote:

Dear reckoning IOTlers,  

in https://github.com/RIOT-OS/RIOT/pull/5985 we started a discussion about  
what should count for which statistic when using the netstats_l2 module.  

My rationale for the "old style" of counting was that L2 is the lowest layer  
where we can analyze traffic from the node's perspective. Hence, I'd like to  
count every byte/packet the node receives. However, I realized that this might  
be a bad idea, given different transceiver capabilities. Old or very cheap  
transceivers leave most packet parsing and error handling to the driver  
developer. Hence, here the driver will receive a lot more packets than for  
more advanced transceivers. Hence, we should probably agree that only  
successful received packets, i.e., packets with header information and correct  
checksums (if any) targeted to the receiving node (matching destination  
address) are counted as successful received packets. All other packets may go  
into an additional "RX error" field of the statistics.  

However, I would vote that packets that are dropped by the driver, e.g.,  
because of insufficient memory, should _not_ count as "RX error" for L2. We  
could consider adding another field, e.g. "RX dropped" for this purpose.  

What do you think?  

Cheers,  
Oleg  
--  
printk("autofs: Out of inode numbers -- what the heck did you do??\n");  
linux-2.0.38/fs/autofs/root.c  
___
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

Re: [riot-devel] weird(?) rom section origin in stm32f103cb.ld

[Carsten Bormann]

On 24 October 2016 at 17:01:35, Olaf Bergmann (bergm...@tzi.org) wrote:
Is there a specific reason why the ISR vector table is placed at address 
0x08005000 instead of 0x0800 as usual? 

“As usual” = as in the other related cpu specs, say, stm32f103c8.ld or 
stm32f103rb.ld.
Has anyone ever actually tried the cb variant?  
I don’t even understand how it could work; those vectors need to be at 
0x0800.

Grüße, Carsten

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] mqtt-sn, multicast and riot

[Carsten Bormann]

Alexander Aring wrote:
> But for constrained networks, so far I know there is also no implementation
> for MPL in RIOT. :-/

Indeed, if somebody has some time to spare, implementing MPL would be a
very good way to make use of that (and probably a much better one than
trying to beat a dead horse like MQTT-SN).
(And, of course, there is also draft-bergmann-bier-ccast waiting for a
non-Contiki implementation.)

Grüße, Carsten
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Exchange CoAP messages between 2 boards

[Carsten Bormann]

Hi ALESSANDRO,

In Berlin we talked about a number of CoAP implementations, including a new one 
specifically for riot called gcoap. Cant dig out the references right now, but 
Google for t2trg and riot.  

Grüße, Carsten  
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Oneway-Malloc

[Carsten Bormann]

Carsten Bormann wrote:
> https://twitter.com/c4bo/status/676393852798922752

OK, that may have been a bit opaque :-)

http://www.barrgroup.com/Embedded-Systems/How-To/Malloc-Free-Dynamic-Memory-Allocation
http://www.embedded.com/design/programming-languages-and-tools/4416457/EMB-tm-6-15-13-Dynamic-memory-and-heap-contiguity
http://stackoverflow.com/questions/1725923/how-bad-is-it-to-use-dynamic-datastuctures-on-an-embedded-system
http://www.nongnu.org/avr-libc/user-manual/malloc.html

If you really need dynamic memory for some algorithm, consider an arena
allocator.
https://en.wikipedia.org/wiki/Region-based_memory_management

Grüße, Carsten
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Oneway-Malloc

[Carsten Bormann]

https://twitter.com/c4bo/status/676393852798922752

:-)

Grüße, Carsten


Sam Kumar wrote:
> Hello,
> I noticed that there is a "oneway-malloc" module in RIOT OS. It appears
> to be a thin wrapper around sbrk that only supports allocating memory,
> not freeing it.
> 
> I am doing some development using RIOT OS, and dynamic memory allocation
> would be useful to me. Is there already a module that implements dynamic
> memory allocation suitable for general-purpose use in the kernel and in
> user programs?
> 
> If such a module does not already exist, I am willing to contribute a
> lightweight implementation of malloc, realloc, calloc, and free to
> replace the oneway-malloc module.
> 
> Sam Kumar
> 
> ___
> 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

[riot-devel] Skimpy make-do streaming of RIoT summit plenary

[Carsten Bormann]

https://hangouts.google.com/hangouts/_/bomthsflordmhfhplund2imm64e

You cannot see the slides there; copies of the slides are slowly
gathering at http://www.tzi.de/~cabo/riot-summit/

If you join the hangout, please send feedback to #riot=os
(irc.freenode.net).

Grüße, Carsten
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Web and IoT discussion

[Carsten Bormann]

Emmanuel Baccelli wrote:
> The CoAP discussion is going to be a break-out session on Saturday, with
> a relatively small number of participants, so remote participation would
> be easier to organize.

We will try to get something going for the T2TRG/RIOT session, probably
based on Google Hangouts or some other WebRTC scheme.  Stay tuned...
Announcement will be on #riot-os.

Grüße, Carsten
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] exhausted Travis

[Carsten Bormann]

Have you looked at CircleCI?
This seems to be the rage for IETF repos at this point.
(ISTR I couldn't get it to work for my repos, but I probably just didn't
try hard enough.)

Grüße, Carsten
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] gnrc udp-hc support for elided checksum

[Carsten Bormann]

RFC 6282 UDP checksum elision is a textbook example of a "cross-layer"
optimization that seems cheap to implement but has non-trivial
architectural costs.

In order for an application to indicate that the UDP checksum can be
elided, or for an application to accept UDP datagrams that have had
their UDP checksum elided, this information really needs to be carried
down and up with each single datagram.  There is no shortcut that would
allow making these decisions within the adaptation layer.

There actually is a significant use case for UDP checksum elision: DTLS.
 A DTLS implementation should indicate that the UDP checksum can be
elided when sending datagrams if they have been integrity-protected by
DTLS -- not so for a few handshake packets.  Similarly, a DTLS
implementation should accept datagrams where the UDP checksum has been
elided only if the content of that datagram is then subject to integrity
protection.  When initiating the listening, it will need to signal that
it is prepared to accept UDP datagrams with that information attached
and that it is willing to deal with the information.

So to implement this, you have to:
-- implement it in the adaptation layer (RFC6282 implementation);
-- enhance the interfaces so a "checksum can be/has been elided" bit can
be carried around with a datagram;
-- implement that bit in DTLS, and create the necessary signaling;
-- make sure that unsuspecting applications (that don't know about that
bit) never see packets where the bit is set.

Grüße, Carsten


Oleg Hahm wrote:
> Hi René!
> 
> On Mon, Jan 11, 2016 at 05:14:31PM +0100, René Herthel wrote:
>> i would like to implement the support (TODO [1]) for elided checksum of
>> compressed udp pakets on the gnrc.
> 
> Thanks for offering your help regarding this topic.
> 
>> So therefore i have some questions:
>> Is someone already working on it?Is there any reason why this is not
>> implemented before?Are there some things i should definitely know? ( like
>> other work/PR's which have to be done first, or something else..)
> 
> I think there exist some reasons why this hasn't been implemented yet. While
> decompressing packets with elided UDP checksum shouldn't be problematic,
> for the compression itself some considerations has to be taken:
> 1.) RFC 6282, Section 4.3.2 [2] specifies that the upper layer must authorize
> the header compression module to elide the checksum. This is only possible
> if tunneling (like IPsec Encapsulating Security Payload tunnel mode) or
> another message integrity check (such as IPsec Authentication Header) is
> present in the UDP payload. Since IPsec has not yet been implemented for
> RIOT and to the best of my knowledge also no other tunneling or additional
> integrity checking mechanism for UDP payloads exists in GNRC, there is
> currently no immediate use case for UDP checksum elision. Also note that
> this features is optional.
> 2.) Since 6LoWPAN and IPHC/NHC operates asynchronously to any upper layer, it
> is not trivial to determine for which packets the checksum may be elided.
> A node may communicate over UDP to several services or hosts concurrently,
> where one connection may use something like IPsec and authorize the NHC
> module to elide the checksum, while for another connection this should not
> be allowed. I think with the current netapi calls (send and setting of
> netopts) this is not easy to implement. Maybe other GNRC knowledgeable
> persons such as Martine, Hauke, Cenk, Peter or Johann may have an idea.
> 
>> [1] 
>> https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/network_layer/sixlowpan/iphc/gnrc_sixlowpan_iphc.c#L506
>>
> 
> Cheers,
> Oleg
> 
> [2] https://tools.ietf.org/html/rfc6282#section-4.3.2
> 
> ___
> 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

Re: [riot-devel] Iotivity, AllJoyn, Thread, Ipso Alliance

[Carsten Bormann]

Oleg Hahm wrote:
  I (and I guess I'm speaking for most of us) want a
 (R)IOT device being able to be connected _directly_ to anything. Be it another
 RIOT powered device, a Contiki device, my home gateway, my smartphone, or any
 server in the Internet. 

That's why it's called Thing-to-thing research group!

 Protocols for the IoT should not rely on the fact that
 there is something more powerful that translates their messages to the rest of
 the world.

There is nothing wrong with factoring in something more powerful for
setup, human interface etc.  But for doing their job, where
thing-to-thing communication is the appropriate mode for that job, we
should be able to do it.  It's the Internet way...

I'm also looking forward to the IoTivity and AllSeen talks today.
Too bad we couldn't find someone from Thread to talk.

Grüße, Carsten
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Switch to BSD?

[Carsten Bormann]

Emmanuel Baccelli emmanuel.bacce...@inria.fr writes:

 Hi Carsten, 
 on the topic of rewriting history ;) it would be interesting to know
 if you have an estimation of the proportion of RIOT code your people
 would have developed that would have been contributed back to the
 master branch, over the last 1,5+ years, taking into account the
 constraints of your customers over that period of time? (assuming RIOT
 code was, say, MIT licensed).

Hi Emmanuel,

this would be a more useful question if I were the only person on earth
who looks at licensing issues before adopting some technology.  I can
assure you I'm not.

But to answer the question anyway: Honestly, I don't know.  I don't know
because, without a reasonable platform, we simply did not procure work
in this space.  On the university side, the work on ccast
(draft-bergmann-bier-ccast) might have gone into RIOT instead of Contiki
(unfortunately, the hacks we needed to make this work in Contiki are
probably too gross to make it back into mainline there).  I also know
that I could have steered the student project that started in October
towards something that uses RIOT, and I didn't (they now have a
different subject).  We had some other ideas in 2013 that would have
benefitted from RIOT that we didn't pursue because we didn't have a
suitable platform.  On the company side, there was a potential
opportunity in the summer of this year that we let pass, but that was a
somewhat longer shot.

So, it could have been substantial, or it could have been trivial.
What I was aiming at with my throwaway comment was that there are lots
of opportunities withering on the vine, and aggressively waiting (for
what?) is not the bold move that will remove this roadblock.

Gruesse, Carsten
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel