Re: [riot-devel] 35C3 CfP

[Simon Brummer]

Hi Martine,

I would like to be part of a RIOT assembly. ;)

Cheers Simon

Am 2018-09-19 18:04 schrieb Martine Lenders:

Hi,

FYI, the CfP for 35C3 is out [1] since last week.

My current plan is to represent the RIOT community there with an
high-level introductory talk on ICN within the Science track there.

As every year: If we get enough people together, I would like to start
a RIOT assembly.

Kind regards,
Martine

[1]
https://events.ccc.de/2018/09/11/35c3-call-for-participation-and-submission-guidelines/

___
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] TCP on RIOT OS

[Simon Brummer]

Hi Theresa,

I would recommend waiting for tuesday.

Cheers Simon

Am 2018-05-22 16:29 schrieb Theresa Müller:

Hi Simon,

thanks for your reply!
I would like to use TCP on RIOT for a project at my university which
is related to my bachelor thesis, so would you rather recommend
waiting until Tuesday since it would be better if I use a stable
version for it?

Best regards
Theresa

GESENDET: Dienstag, 22. Mai 2018 um 14:35 Uhr
 VON: "Simon Brummer" <simon.brum...@posteo.de>
 AN: "RIOT OS kernel developers" <devel@riot-os.org>
 BETREFF: Re: [riot-devel] TCP on RIOT OS
Hi Theresa,

 Martine is right, link local adresses don't currently work with gnrc
tcp
 (even with the mandatory interface specifier).
 This is a known issue, I am currently working on it. I intend to
merge
 it on the next Hack'n'Ack (next Tuesday).

 If you need it faster, there is a development branch for the fix on
 github.
 It should compile and work however, it could have some undesired side
 effects.

 Kind regards

 Simon

 Am 2018-05-22 14:03 schrieb Martine Lenders:
 > Hi Theresa,
 >
 > were you using link local addresses (i.e. are they prefixed
 > `fe80::/64`) for your trials? If yes, newer versions require to
also
 > provide an interface with that (as it is the case e.g. also on
Linux)
 > so this might be your problem. The client and server needs to be
fixed
 > then of course to have the interface provided or warn the user that
it
 > is missing..
 >
 > Best regards,
 > Martine
 >
 > 2018-05-22 9:37 GMT+02:00 "Theresa Müller" <theresa2...@web.de>:
 >
 >> Hi everyone,
 >>
 >> I am currently trying to use TCP on RIOT, but I'm having problems
 >> with it, since the "gnrc_tcp_server" and "gnrc_tcp_client" tests
are
 >> not working on the latest version of RIOT. I tried to run these
 >> tests on the 2017.01 release where they were added the first time
 >> and everything works fine here, but when I run them on the 2018.01
 >> or 2018.04 release, wireshark doesn't show any TCP pakets and the
 >> client always receives a timeout after a while, so somehow the
 >> client and the server aren't able to establish a connection. Maybe
 >> one of you knows what caused this change in behaviour and how this
 >> could be fixed.
 >>
 >> Thanks a lot for your help!
 >>
 >> Best regards,
 >> Theresa
 >> ___
 >> devel mailing list
 >> devel@riot-os.org
 >> https://lists.riot-os.org/mailman/listinfo/devel [1] [1]
 >
 >
 >
 > Links:
 > --
 > [1] https://lists.riot-os.org/mailman/listinfo/devel [1]
 >
 > ___
 > devel mailing list
 > devel@riot-os.org
 > https://lists.riot-os.org/mailman/listinfo/devel [1]
 ___
 devel mailing list
 devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel [1]

Links:
--
[1] 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

Re: [riot-devel] TCP on RIOT OS

[Simon Brummer]

Hi Theresa,

Martine is right, link local adresses don't currently work with gnrc tcp 
(even with the mandatory interface specifier).
This is a known issue, I am currently working on it. I intend to merge 
it on the next Hack'n'Ack (next Tuesday).


If you need it faster, there is a development branch for the fix on 
github.
It should compile and work however, it could have some undesired side 
effects.


Kind regards

Simon

Am 2018-05-22 14:03 schrieb Martine Lenders:

Hi Theresa,

were you using link local addresses (i.e. are they prefixed
`fe80::/64`) for your trials? If yes, newer versions require to also
provide an interface with that (as it is the case e.g. also on Linux)
so this might be your problem. The client and server needs to be fixed
then of course to have the interface provided or warn the user that it
is missing..

Best regards,
Martine

2018-05-22 9:37 GMT+02:00 "Theresa Müller" :


Hi everyone,

I am currently trying to use TCP on RIOT, but I'm having problems
with it, since the "gnrc_tcp_server" and "gnrc_tcp_client" tests are
not working on the latest version of RIOT. I tried to run these
tests on the 2017.01 release where they were added the first time
and everything works fine here, but when I run them on the 2018.01
or 2018.04 release, wireshark doesn't show any TCP pakets and the
client always receives a timeout after a while, so somehow the
client and the server aren't able to establish a connection. Maybe
one of you knows what caused this change in behaviour and how this
could be fixed.

Thanks a lot for your help!

Best regards,
Theresa
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel [1]




Links:
--
[1] 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

Re: [riot-devel] RIOT assembly at 34C3

[Simon Brummer]

Since I haven't got a Ticket this year I can't be part of an potential 
assembly, but I'll appreciate the Idea.

I think it's a great place to get in touch with Hobbyists.

Cheers Simon

Am 2017-11-04 21:52 schrieb Martine Lenders:

Hi,

I'm going to 34C3 [1] this year. Anyone interested forming a RIOT
assembly [2] there this year?

Cheers,
Martine

[1] https://www.ccc.de/en/updates/2017/34C3-in-leipzig [1]
[2] https://events.ccc.de/2017/11/04/people-34c3/ [2]

Links:
--
[1] https://www.ccc.de/en/updates/2017/34C3-in-leipzig
[2] https://events.ccc.de/2017/11/04/people-34c3/

___
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] Greetings from the 33c3 and Pointer to an interesting USB talk

[Simon Brummer]

Dear fellow RIOTers,

today is an interesting Talk about a low speed USB implementation 
written in Software. It might be interesting for us RIOTers.


Here is the Abstract: 
https://fahrplan.events.ccc.de/congress/2016/Fahrplan/events/8031.html
And there should be the Stream at 16:00 : 
https://streaming.media.ccc.de/33c3/hallg



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

Re: [riot-devel] char* to int and vice versa

[Simon Brummer]

You can do that with snprintf an its Format specifires

Am 05.09.2016 6:40 nachm. schrieb "Adeel Mohammad Malik" <
adeel.mohammad.ma...@ericsson.com>:

> atoi() converts from a string to an int. I want to convert an int to a
> string.
>
>
>
> /Adeel
>
>
>
> *From:* devel [mailto:devel-boun...@riot-os.org] *On Behalf Of *Simon
> Brummer
> *Sent:* Monday, September 05, 2016 6:36 PM
> *To:* RIOT OS kernel developers
> *Subject:* Re: [riot-devel] char* to int and vice versa
>
>
>
> Ah okay. You are looking for atoi() ;)
>
>
>
> Am 05.09.2016 6:18 nachm. schrieb "Adeel Mohammad Malik" <
> adeel.mohammad.ma...@ericsson.com>:
>
> The char * is a string here. Basically what I want is the equivalent of
> sprintf().
>
>
>
> /Adeel
>
>
>
> *From:* devel [mailto:devel-boun...@riot-os.org] *On Behalf Of *Simon
> Brummer
> *Sent:* Monday, September 05, 2016 6:10 PM
> *To:* RIOT OS kernel developers
> *Subject:* Re: [riot-devel] char* to int and vice versa
>
>
>
> Well, in c any Pointer is an integer. If you want the plain numeric value,
> you can just cast the pointer to int. There is no conversion function
>
>
>
> Am 05.09.2016 5:58 nachm. schrieb "Adeel Mohammad Malik" <
> adeel.mohammad.ma...@ericsson.com>:
>
> Hi,
>
>
>
> A quick question, what functions should I use to convert between a char *
> and int in RIOT?
>
>
>
> /Adeel
>
>
> ___
> 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
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] char* to int and vice versa

[Simon Brummer]

Well, in c any Pointer is an integer. If you want the plain numeric value,
you can just cast the pointer to int. There is no conversion function

Am 05.09.2016 5:58 nachm. schrieb "Adeel Mohammad Malik" <
adeel.mohammad.ma...@ericsson.com>:

Hi,



A quick question, what functions should I use to convert between a char *
and int in RIOT?



/Adeel

___
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] Condition Variables

[Simon Brummer]

Hi Sam,

The hole message passing avoidance is actually a pretty good point. I
prefer message passing because I can handle the hole User Function call
Timeout Handling with it as well. It would be interesting if a condition
change could occur based on the expiration of a Timer.

Just my thoughts on that.

Cheers Simon

Am 18.08.2016 6:42 nachm. schrieb "Sam Kumar" :

Thanks for the advice, Simon, Martin, and Kaspar!

For now, I'll use a mutex together with thread_flags. Using message
passing, as Simon suggested, would work for me as well; the reason I find
thread_flags preferable is that I need to block application threads that
call send() and receive(), that may already be using message passing.

If people don't mind, and they think it would be useful, I'm also willing
to contribute a lightweight condition variable to the core module. I think
it could be implemented simply as a queue, just like the current mutex
implementation.

Sam

On Wed, Aug 17, 2016 at 10:19 AM, Kaspar Schleiser 
wrote:

> Hey,
>
> On 08/16/2016 09:49 PM, Sam Kumar wrote:
> > If not, I want to learn if there is another structured way to
> > block a thread until an event, that I should use instead.
>
> maybe thread_flags work for your use-case.
>
> Kaspar
> ___
> 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

Re: [riot-devel] Condition Variables

[Simon Brummer]

Dear fellow TCP implementor,

The common way implement something like this in RIOT is Message
passing. Your thread simply blocks by calling msg_receive() until it
received a message from another thread. As soon as you receive a
Packet, send a message to the via msg_send() function to wake the
blocked thread. 

Cheers 
   Simon Brummer

Am Dienstag, den 16.08.2016, 12:49 -0700 schrieb Sam Kumar:
> Hello,
> I was looking at the synchronization primitives in RIOT OS. I noticed
> that there is a mutex implementation, but I was unable to find a
> condition variable.
> 
> I am currently porting the TCP logic from the FreeBSD operating
> system to RIOT as part of the research work I am doing. I am
> implementing the "conn" API for TCP, and I need to be able to block
> the current thread until a packet is received, to implement some of
> the functions.
> 
> I read the IPC implementation (msg.c), which also has a blocking API,
> and saw that it interacts with the scheduler manually in order to
> block and resume threads. Before I did the same thing for the conn
> API (or perhaps implement/contribute my own condition variable), I
> wanted to ask whether there are condition variables for RIOT, in case
> I was just looking in the wrong place. If not, I want to learn if
> there is another structured way to block a thread until an event,
> that I should use instead.
> 
> Thanks,
> 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] Disable 15.4 Acknowledgements

[Simon Brummer]

Hello Everybody,

Currently I am testing my TCP implementation between two samr21 Boards
and a Raspberry Pi as sniffing Probe in between.

My measured network dump contains a few unexpected retransmissions and
i am unable to distinguish between retransmissions caused by 15.4 and
retransmissions caused by TCP. Is there a way to disable the 15.4
acknowledgement and retransmission mechanism?

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