Re: [riot-devel] RPL DAO target concat from fib

[Oleg Hahm]

Hey Rahul,

On Thu, Oct 19, 2017 at 07:25:19PM +0530, Rahul Jadhav wrote:
> > > > But with the addition of a proper
> > > > 6lowpan fragmentation, we dropped that functionality.
> > >
> > > [RJ] 6lo frag is not a good option to use and should be avoided as far as
> > > possible.
> >
> > Is this your personal opinion or some IETF consensus?
> 
> 
> [RJ] In IETF98, Pascal had presented the problem stmts related to 6lo
> fragmentation and post-session there was a discussion (
> https://www.ietf.org/mail-archive/web/6lo/current/msg02355.html).
> Also my experience with regards to 6lo frag also points to problems similar
> to what were mentioned during that session.

Thanks for the pointer.
 
> > I agree that fragmented ICMPv6 messages are somewhat pointless, but to
> > rely on IPv6 fragmentation for link layers that do not support the minimum
> > MTU for IPv6 and do not offer fragmentation (like IEEE 802.15.4) it still
> > seems to be the best choice to me.
> > Can you elaborate a bit?
> 
> [RJ] i think i didnt appropriately word my stmts. I never suggested to not
> support or disable 6lo fragmentation. In my experiment i have disabled it
> just to check if there are any reasons why RIOT should result in 6lo
> fragmentation. I found this (DAO) case and thought, may be, this  is not a
> good candidate to result in 6lo frag and can be avoided and hence the mail.

Thanks for the clarification. That makes absolutely sense - and I agree that
fragmented DAOs are not a good idea.

Cheers,
Oleg
-- 
fs_dprintk (FS_DEBUG_INIT, "Ha! Initialized OK!\n");
linux-2.6.6/drivers/atm/firestream.c


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

Re: [riot-devel] rtc alarm running with threads

[Oleg Hahm]

Dear Paula,

can you share the code of your application somewhere? That might help to find
the issues. I would suppose that the interrupt handler is faulty or consumes
too much memory or something like this.

I think start debugging with a basic application that just prints some text
whenever a message from the RTC interrupt is received is a smart idea. Now, we
need to figure out what exactly triggers the kernel panic. Are you compiling
your application with the DEVELHELP macro enabled? And which port are you
using? Maybe you can use `make debug` to get more information.

Cheers,
Oleg
-- 
/* Fuck, we are miserable poor guys... */
linux-2.6.6/net/xfrm/xfrm_algo.c


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

Re: [riot-devel] Jimini Board support announcement

[Oleg Hahm]

Dear Josua,

On Thu, Oct 19, 2017 at 02:38:35PM +, Arndt, Josua wrote:
> I'm happy to announce the support of a new board develop at the IAS of the
> RWTH Aachen. The initial PR is ongoing, it will be followed by driver and
> module PRs soon. Have a closer look at the wiki page to get an overview and
> insight of our development state.

cool, this sounds great. I particular appreciate the efforts you've spent in
creating the wiki page for the board and updating relevant information!

Thanks a lot and keep up the good work,
Oleg
-- 
T he bes thin gabou tTCPfl owcontr oljokesi sthatthey knowwhento backo ff


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

[riot-devel] rtc alarm running with threads

[Paula Ortega Cancino]

Hi,

I've been working on an application that activates rtc alarms every few
seconds, when the alarm is activated it sends a message to a thread. This
msg is used in a thread that in its turn sends messages over gnrc. However,
after a while sending messages, it stops and the  mcu only gets in in the
rtc alarm, without returning to the thread context.

I tested a basic thread, that just puts some serial message, and a rtc
alarm showing another message. The program starts running the thread but
every time the rtc alarm activates i get a Riot Kernel panic: HARD FAULT
HANDLER and then reboots the system.

I imagine there is a problem when both functions are supposed to run at the
same time and it gets a kernel panic, or some kind of problem with the
context switcher. Any thoughts on why this is happening, advice on how to
workaround it, etc. would be much appreciated. Cheers,

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

[riot-devel] Jimini Board support announcement

[Arndt, Josua]

Hello All,

I'm happy to announce the support of a new board develop at the IAS of the RWTH 
Aachen. The initial PR is ongoing, it will be followed by driver and module PRs 
soon. Have a closer look at the wiki page to get an overview and insight of our 
development state.

A quick status: we have a working link to an RPI3 which has a Atmel transceiver 
board from Openlabs connected. It works as boarder router running radvd. As we 
are facing the problem of global IP drop as described in issue #5790 we decided 
to start pushing what we got, to also avoid parallel implementation.

While I was at it I did some changes to the wiki which a want to announce as it 
is proposed in the howto's.

  *   The addition of support for the Jimini board. Wiki page is added, PR is 
ongoing .

https://github.com/RIOT-OS/RIOT/wiki/Board%3A-Jiminy-atmega256rfr2

  *   Minor changes to the wiki page  eclipse added  7. Code convention  
configuration also provided an eclipse code style convention to import. 
(checks, amendment or improvement welcome)

https://github.com/RIOT-OS/RIOT/wiki/Using-the-Eclipse-IDE-for-C-and-CPP-Developers%2C-Howto

  *   sidebar changed to level structured Family/ Board layout to increase 
overview. (comments welcome) and added Jimini Board to ATmega family

https://github.com/RIOT-OS/RIOT/wiki

  *   Tabular for supported platforms, Minor changes to line break in tabular 
and consistency of Family Name

https://github.com/RIOT-OS/RIOT/wiki/RIOT-Platforms

  *   Added link to development procedure as tip under the porting guide

https://github.com/RIOT-OS/RIOT/wiki/Porting-Guide

Thank you all for working on Riot.
Especially all who help working through the PRs.

Best regards,
Josua Arndt
[rwth_ias_bild_rgb_logo]

Josua Arndt, M.Sc.
RWTH Aachen University
Integrated Analog Circuits and RF Systems
Kopernikusstraße 16, ICT Cube North, Room 209, D-52074 Aachen
Email: josua.ar...@ias.rwth-aachen.de
Phone: +49 241 / 80 - 27750



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

Re: [riot-devel] RPL DAO target concat from fib

[Rahul Jadhav]

Hi Oleg,

Pls find my comments inline.

Regards,
Rahul

On 19 October 2017 at 17:12, Oleg Hahm  wrote:

> Hey Rahul,
>
> another clarification question:
>
> On Thu, Oct 19, 2017 at 11:16:17AM +0530, Rahul Jadhav wrote:
>
> > > But with the addition of a proper
> > > 6lowpan fragmentation, we dropped that functionality.
> >
> > [RJ] 6lo frag is not a good option to use and should be avoided as far as
> > possible.
>
> Is this your personal opinion or some IETF consensus?


[RJ] In IETF98, Pascal had presented the problem stmts related to 6lo
fragmentation and post-session there was a discussion (
https://www.ietf.org/mail-archive/web/6lo/current/msg02355.html).
Also my experience with regards to 6lo frag also points to problems similar
to what were mentioned during that session.

I agree that fragmented
> ICMPv6 messages are somewhat pointless, but to rely on IPv6 fragmentation
> for
> link layers that do not support the minimum MTU for IPv6 and do not offer
> fragmentation (like IEEE 802.15.4) it still seems to be the best choice to
> me.
> Can you elaborate a bit?
>

[RJ] i think i didnt appropriately word my stmts. I never suggested to not
support or disable 6lo fragmentation. In my experiment i have disabled it
just to check if there are any reasons why RIOT should result in 6lo
fragmentation. I found this (DAO) case and thought, may be, this  is not a
good candidate to result in 6lo frag and can be avoided and hence the mail.


> Cheers,
> Oleg
> --
> panic("Oh boy, that early out of memory?");
> linux-2.2.16/arch/mips/mm/init.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] RPL DAO target concat from fib

[Rahul Jadhav]

I have disabled 6lo frag just to  check which all cases results in
fragmentation and to check if an alternative is available/possible.
"6lo frag is mandatorily needed", no doubt (and its must as per specs). It
s just best to avoid it if possible.
One reason (which also is applicable in the DAO scenario discussed) is, any
loss of single 6lo fragment results in complete pkt retransmission.
Assume if we have the DAO mechanism (like discussed in this mail chain),,
any single loss of DAO should result only in its retransmission (turns out
it also is trivial to implement).

Regards,
Rahul

On 19 October 2017 at 17:25, Carsten Bormann  wrote:

> On Oct 18, 2017, at 20:30, Rahul Jadhav  wrote:
> >
> >  i do not have 6lo fragmentation enabled.
>
> Rahul,
>
> 6LoWPAN does not give you that choice.
> If you need interoperability, you need to support adaptation layer
> fragmentation.
>
> Grüße, Carsten
>
> ___
> 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] RPL DAO target concat from fib

[Carsten Bormann]

On Oct 18, 2017, at 20:30, Rahul Jadhav  wrote:
> 
>  i do not have 6lo fragmentation enabled. 

Rahul,

6LoWPAN does not give you that choice.
If you need interoperability, you need to support adaptation layer 
fragmentation.

Grüße, Carsten

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

Re: [riot-devel] RPL DAO target concat from fib

[Oleg Hahm]

Hey Rahul,

another clarification question:

On Thu, Oct 19, 2017 at 11:16:17AM +0530, Rahul Jadhav wrote:
 
> > But with the addition of a proper
> > 6lowpan fragmentation, we dropped that functionality.
> 
> [RJ] 6lo frag is not a good option to use and should be avoided as far as
> possible.

Is this your personal opinion or some IETF consensus? I agree that fragmented
ICMPv6 messages are somewhat pointless, but to rely on IPv6 fragmentation for
link layers that do not support the minimum MTU for IPv6 and do not offer
fragmentation (like IEEE 802.15.4) it still seems to be the best choice to me.
Can you elaborate a bit?

Cheers,
Oleg
-- 
panic("Oh boy, that early out of memory?");
linux-2.2.16/arch/mips/mm/init.c


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

Re: [riot-devel] RPL DAO target concat from fib

[Oleg Hahm]

Hi Rahul!

Just a small remark regarding one of your comments:

On Thu, Oct 19, 2017 at 11:16:17AM +0530, Rahul Jadhav wrote:
> 2. RIOT does not handle L2 retry-count feedback to maintain RPL metric (for
> e.g. ETX).
> Pls correct if i m wrong.

One problem here is that not all radio devices report back the number of L2
retries if this is implemented by the device itself. In some cases it is
possible to deactivate this feature and take care of L2 ACK handling and
retries as part of the device driver, but this is currently not implemented
for all drivers.

Cheers,
Oleg
-- 
HTTP Error 413: That’s what she said!


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

Re: [riot-devel] RPL DAO target concat from fib

[Landsmann, Martin]

Hey Rahul, Cenk, Koen,


> 6lo frag is not a good option to use and should be avoided as far as possible.
right, but as we all know it cannot be achieved all the time.

> Supporting target aggregation in DAO without depending on 6lo frag
I think that would be the right direction for mitigating the symptom of sending 
elidable redundant information in DAOs options, which exceed the MTU.

I don't remember exactly if the rfc6550 et al. restrict the behaviour of 
constructing and distributing DAO transit/target options to parents in solely a 
single packet.
If splitting the downward information does not violate the RFCs, then taking 
the MTU into account up to a cetrain degree, would be just an implementation 
specific detail and probably the way to go (again).

But I would always prefer letting the underlying layer to provide fragmentation 
over an customized approach.


Best regards,

Martin

Von: devel [devel-boun...@riot-os.org]" im Auftrag von "Koen Zandberg 
[k...@bergzand.net]
Gesendet: Donnerstag, 19. Oktober 2017 08:19
An: devel@riot-os.org
Betreff: Re: [riot-devel] RPL DAO target concat from fib


Hey Rahul,

Unfortunately I don't have time right now to read and comment on your email in 
depth :(
About the ETX metrics for RPL, please have a look at #6873 and #7450.

I want to take a better look at your ideas and proposal in the weekend.

Regards,
Koen Zandberg

#6873: https://github.com/RIOT-OS/RIOT/pull/6873
#7450: https://github.com/RIOT-OS/RIOT/pull/7450

On 10/19/2017 07:46 AM, Rahul Jadhav wrote:
Thanks Cenk for giving a clear picture. Some comments inline...
In general, I feel this is important to be handled, since even in small network 
this would result in DAO fragmentation and will impact its performance.

Also there are some other points i wanted to understand/clarify:
1. Currently RIOT does not handle L2 ACK for determining whether L2 send was 
successful or not.  This feedback is not used at RPL/6lo layer. Scenario: A 
node receives a DIO from parent and sends a DAO. But lets say this DAO could 
not reach the parent. In this case L2 ACK would have failed and the child node 
could have handled it to switch parent. Even if K bit is set in the DAO, and if 
DAO-ACK is not received, the child node wont come to know since there is no 
state/timer maintained to handle this. Essentially this will lead to child node 
believing that it is connected to the network but the downstream path is never 
actually established.
2. RIOT does not handle L2 retry-count feedback to maintain RPL metric (for 
e.g. ETX).
Pls correct if i m wrong.

Thanks,
Rahul

On 19 October 2017 at 01:00, Cenk Gündoğan 
mailto:list-r...@cgundogan.de>> wrote:
Hey Rahul,

you are correct. The current RPL DAO building routine does not take
into account the MTU size, which is IMO the appropriate approach,
because on that level (ICMPv6) there is usually no knowledge about the
link-layer in use.

[RJ] True.

If I understand you correctly, then you basically
want to move the fragmentation from the 6lowpan layer up to the
ICMPv6/RPL layer (and only for DAOs).

[RJ] Thats exactly what I had in mind.

I think in one of the older
iterations of our RPL implementation we once had a functionality to
limit the number of Target Options in the DAO to a specific number
(configurable on compile-time).

[RJ] This would have been a real nice feature. Supporting target aggregation in 
DAO without depending on 6lo frag. In the future, proposing/implementing prefix 
eliding (the way 6loRH does for SRH or by simply using 6lo CID) between target 
containers and standardising it would make sense ! Considering that DAO 
consumes the most amount of RPL control traffic, i feel this can be fairly 
important.

But with the addition of a proper
6lowpan fragmentation, we dropped that functionality.

[RJ] 6lo frag is not a good option to use and should be avoided as far as 
possible.


I may take a look at it during the weekend. If I remember correctly,
then we used to have a further parameter to the "send_DAO" function that
tracked the number of already sent Target Options. Further calls to
"send_DAO" would then add the next Target Options. If such functionality
is needed (@bergzand, @BytesGalore, @smlng any comments on this?) then
we should aim to come up with an unintrusive approach to activate /
deactivate such a behaviour with compile flags.

[RJ] Wouldn't a simple compile-time flag such as DAO_TARGET_CONCAT_NUM=X be 
sufficient, where X could be 0 (no concat, send only 1 target container which 
will be node self IP addr), -1(for full concat, current implementation), and 
anything else which means non-self target container count. The other way to 
define such a flag would be DAO_TARGET_CONCAT_SZ=Ybytes ... which defines 
number of bytes instead of target count.


Cheers,
Cenk Gündoğan

On 17-10-19 00:00:34, Rahul Jadhav wrote:
> Hello RIOT team,
>
> While experimenting with RIOT i found the RPL module implementation
> behaviour