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

[René Herthel]

Hello all,

 a little time has passed since I wrote the last mail about eliding 
 checksums of UDP packets for the GNRC network stack.
 There are two general requirements:

 1. We need to pass the information to elide the checksum of a packet 
 through the stack. The netapi is not able to pass additional 
 informations of a packet through the stack.

 2. An application layer protocol that doesn't allow to receive packets 
 where checksums have been elided, shouldn't see any of them.

 My proposed solution for the first problem is to insert a new member in 
 the gnrc_pktsnip_t structure. This member holds the information to 
 authorize a packet, which is a precondition to elide the UDP checksum. 
 This way we can carry around that information through the network stack, 
 for each packet.

 My proposal for the second problem is quite similar:
 Adding a new member to the gnrc_netreg_entry_t structure with the 
 information that the corresponding module (or application) is (not)
 allowed to receive packets with elided checksums.

 In addition one could probably use these newly introduced struct members 
 for different kinds of information, or just don't compile it if it's not 
 needed. Any ideas on that?
With my proposed solution one does not need to change the netapi but 
 enhance some functions to handle the additional information.

 Looking forward to get some feedback from your side!

 Best
 René Herthel
---

> Date: Tue, 12 Jan 2016 14:52:40 +0100
> From: c...@tzi.org
> To: devel@riot-os.org
> Subject: Re: [riot-devel] gnrc udp-hc support for elided checksum
> 
> 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 
> > 

Re: [riot-devel] RIOT Release 2016.04

[Thomas Eichinger]

Congratulations to everybody for their awesome work! 

Best, Thomas 

> On Apr 22, 2016, at 4:33 PM, Hauke Petersen  
> wrote:
> 
> Dear RIOT developers and users,
> 
> we are happy to announce the seventh official release of the RIOT:
> 
> --- * RIOT 2016.04 * 
> ---
> 
> This release adds support for two additional network stacks: lwIP and emb6.
> A bunch of additional protocols are now available, P2P-RPL in the GNRC
> network stack, Ethernet-over-Serial (ethos). Murdock, the new, blazing fast
> RIOT CI is now available to significantly speed up code merging procedures.
> 
> This release also adds support for a number of new boards and sensors and a 
> new
> tool for automated border router setup is now provided which greatly 
> simplifies
> that setup for newbies as well as for old-timers. Last but not least: this
> release includes a number of bug fixes, mostly about stabilizing and enhancing
> the networking capabilities of RIOT.
> 
> About 470 pull requests with about 1196 commits have been merged since the 
> last
> release and 127 additional issues have been solved. 55 people contributed code
> in 124 days. 1521 files have been touched with ~91700 insertions and ~42200
> deletions.
> 
> You can download the RIOT release from Github by cloning the repository [1] 
> or by
> downloading the tarball [2], and look up the release notes for further 
> details [3].
> 
> Thanks everyone for your contributions, discussions, testing efforts, and 
> keep RIOTing!
> 
> Cheers,
> Hauke
> 
> [1] https://github.com/RIOT-OS/RIOT/releases/tag/2016.04
> [2] https://github.com/RIOT-OS/RIOT/archive/2016.04.tar.gz
> [3] https://github.com/RIOT-OS/RIOT/blob/master/release-notes.txt
> ___
> 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] PowerProfiler

[Michael Andersen]

I'm back on Monday, I'll set it up ASAP for you when I arrive.
On Apr 22, 2016 3:09 PM, "Emmanuel Baccelli" 
wrote:

> Hi Michael,
> thanks for the proposal. It seems there is interest. When are you back
> approximately?
> I'm asking because some of us are working on a deadline (beginning of May)
> for which energy measurements might be very welcome ;)
> cheers,
> Emmanuel
>
> On Thu, Apr 21, 2016 at 4:16 PM, Michael Andersen 
> wrote:
>
>> I would be more than happy to start it up again and maintain it if it
>> would be of use to the community. I'll do so as soon as I finish my
>> post-IPSN Vienna tour :)
>> On Apr 21, 2016 3:46 PM, "Emmanuel Baccelli" 
>> wrote:
>>
>>> Great, and overlooked indeed.
>>> Is this setup still up and running?
>>> Cheers,
>>> Emmanuel
>>>
>>> On Thu, Apr 21, 2016 at 3:43 PM, Oleg Hahm  wrote:
>>>
 Dear really-low-power IOTlers,

 reading through https://github.com/RIOT-OS/RIOT/pull/2309 I stumbled
 across
 Michael Andersen's PowerProfiler [1] and was literally shocked that
 such a
 nice tool/setup has been gone unnoticed for so long. At least I was not
 aware
 of this setup and checking with some other people on IM, it seems that
 I'm not
 alone.

 This looks like a really cool and promising solution to get an
 understanding
 of the power consumption for RIOT applications. Great work, Michael!

 Cheers,
 Oleg

 [1] https://github.com/PowerProfiler/TestApplications
 --
 panic("Yeee, unsupported cache architecture.");
 linux-2.6.6/arch/mips/mm/cache.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
>>>
>>>
>> ___
>> 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] PowerProfiler

[Emmanuel Baccelli]

Hi Michael,
thanks for the proposal. It seems there is interest. When are you back
approximately?
I'm asking because some of us are working on a deadline (beginning of May)
for which energy measurements might be very welcome ;)
cheers,
Emmanuel

On Thu, Apr 21, 2016 at 4:16 PM, Michael Andersen 
wrote:

> I would be more than happy to start it up again and maintain it if it
> would be of use to the community. I'll do so as soon as I finish my
> post-IPSN Vienna tour :)
> On Apr 21, 2016 3:46 PM, "Emmanuel Baccelli" 
> wrote:
>
>> Great, and overlooked indeed.
>> Is this setup still up and running?
>> Cheers,
>> Emmanuel
>>
>> On Thu, Apr 21, 2016 at 3:43 PM, Oleg Hahm  wrote:
>>
>>> Dear really-low-power IOTlers,
>>>
>>> reading through https://github.com/RIOT-OS/RIOT/pull/2309 I stumbled
>>> across
>>> Michael Andersen's PowerProfiler [1] and was literally shocked that such
>>> a
>>> nice tool/setup has been gone unnoticed for so long. At least I was not
>>> aware
>>> of this setup and checking with some other people on IM, it seems that
>>> I'm not
>>> alone.
>>>
>>> This looks like a really cool and promising solution to get an
>>> understanding
>>> of the power consumption for RIOT applications. Great work, Michael!
>>>
>>> Cheers,
>>> Oleg
>>>
>>> [1] https://github.com/PowerProfiler/TestApplications
>>> --
>>> panic("Yeee, unsupported cache architecture.");
>>> linux-2.6.6/arch/mips/mm/cache.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
>>
>>
> ___
> 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+ULAs: no router entry

[Alexander Aring]

Hi,

On Fri, Apr 22, 2016 at 01:31:04PM +0200, smlng wrote:
> Hi all,
> 
> I stripped down my 'radvd.conf' to a minimal of:
> 
> ---snip---
> interface lowpan0
> {
> AdvSendAdvert on;
> MinRtrAdvInterval 3;
> MaxRtrAdvInterval 10;
> AdvDefaultPreference low;
> 
> prefix fd4b:c597:5df5:0::/64
> {
> AdvOnLink off;
> AdvAutonomous on;
> AdvRouterAddr on;
> };
> };
> ---snap---
> 
> same behavior with RIOT. It still consistently configures an (ULA) IP with 
> provided prefix, but the routers entry is missing most of the time - 
> sometimes it's there for a couple of seconds -> until the next RS/RA round. 
> 

so far I know ABRO MUST BE there. radvd/6lowpan doesn't do anything with
that option it's a dummy only, but otherwise 6LoWPAN stacks will drop
it, see [0].

But it's "when RAs are used to propagate information between routers" only.
Not sure right now. :-)

- Alex

[0] https://tools.ietf.org/html/rfc6775#section-4.3
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT+ULAs: no router entry

[Alexander Aring]

On Fri, Apr 22, 2016 at 01:13:29PM +0200, smlng wrote:
> Hi Alex, and all,
> 
> my radvd.conf is the following:
> 
> ---snip---
> 
> interface lowpan0
> {
> AdvSendAdvert on;
> UnicastOnly on;
> AdvCurHopLimit 255;
> AdvSourceLLAddress on;
> 
> MinRtrAdvInterval 3;
> MaxRtrAdvInterval 10;

mhhh,

With MaxRtrAdvInterval 10 then the:

AdvDefaultLifetime

will be 3 * 10 = 30 seconds. Don't know if this is anything related to
it. It should be send another RA messages in the interval of 3-10, so
far I know. In this interval the route (on RIOT side) should be updated,
or?

I think in my setup I used a high value (9000) for this to make anything
working. :-) I can imagine this parameter will not fix this issue, so it
happens later only.

"Must be either zero or between MaxRtrAdvInterval and 9000 seconds."
see [0].

---

Also sending periodic RA messages is some optional feature [1], but if I
remember correctly I used also a periodic transmit, because my RIOT node
never send another RS messages after booting and after lifetime ends it
didn't work anymore and that was the reason for high lifetime. :-) 

So far my expierence. And newbie question: When it's needed to send RS
messages? Maybe it's [2], so far 6775 doesn't update it.

> 
> AdvDefaultPreference low;
> 
> prefix fd4b:c597:5df5:0::/64
> {
> AdvOnLink off;
> AdvAutonomous on;
> AdvRouterAddr on;
> };
> 
> abro fe80::1ac0:ffee:1ac0:ffee
> {
> AdvVersionLow 10;
> AdvVersionHigh 2;
> AdvValidLifeTime 2;
> };
> };
> 
> ---snap---

thanks, maybe I can reproduce it now.

btw: with recent kernel and linux-wpan/radvd -> 6lowpan branch you can
also use 6CO to add your prefix for stateful compression.

> 
> btw. I use your/linux-wpan fork of radvd. Again: RIOT does receive the RA 
> from radvd AND configures an IP with the provided prefix. Thus, the 
> processing of RS+RA up this point seems to be correct, what's missing is the 
> routers entry in RIOT. Further, RIOT does receive the COAP requests but it 
> cannot send any reply, as it does not know the LLaddr for the destination 
> (ULA) IP. As far as I remember my last digging into RIOTs NDP processing, 
> RIOT does the following:
> 
> 1. if DST_IP is link-local: extract LLaddr 
> 2. else if neighbor cache entry exist, use it
> 3. if no ncache: query (default) router for LLaddr
> 4. if no router: abort
> 
> I think I'm running into case 4, where no entry exists what so ever and thus 
> no COAP reply is send.
> 
> @Alex as you joined the discussion: I also have a question regarding the 
> Linux side. I currently use Raspbian with shipped Linux-Kernel 4.1.19. I 
> observed that Linux still does NS for link-local address via the nodes scoped 
> multicast address, instead of using 6lo 'shortcut' by extracting 
> LL/MAC-address from the link-local IP. Is this fixed in some recent version?
> 

There are currently pending patches for introducing neigh_ops, which is
a callback strucuture for send/recv NS/NA. After this is mainline it
should be easily to change this behaviour, or? What do you think?
See [3] - function "lowpan_ndisc_send_ns".

Can you show me the part in rfc6775 which describe that behaviour?
Also I need to admit that I am not an expert in 6LoWPAN-ND. :-)

- Alex

[0] http://linux.die.net/man/5/radvd.conf
[1] https://tools.ietf.org/html/rfc6775#section-6.4
[2] https://tools.ietf.org/html/rfc4861#section-6.3.7
[3] http://www.spinics.net/lists/linux-wpan/msg03716.html
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT+ULAs: no router entry

[smlng]

Hi Cenk, and all,

I'm running my tests with latest master and 2016.04-branch, same behavior. 
Minus the fact, that the router entry in RIOT is created or missing in a 
somewhat 'non-deterministic' fashion.

Best,
  Sebastian

> Am 22.04.2016 um 12:33 schrieb Cenk Gündogan :
> 
> 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

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

Re: [riot-devel] RIOT+ULAs: no router entry

[smlng]

Hi Alex, and all,

my radvd.conf is the following:

---snip---

interface lowpan0
{
AdvSendAdvert on;
UnicastOnly on;
AdvCurHopLimit 255;
AdvSourceLLAddress on;

MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;

AdvDefaultPreference low;

prefix fd4b:c597:5df5:0::/64
{
AdvOnLink off;
AdvAutonomous on;
AdvRouterAddr on;
};

abro fe80::1ac0:ffee:1ac0:ffee
{
AdvVersionLow 10;
AdvVersionHigh 2;
AdvValidLifeTime 2;
};
};

---snap---

btw. I use your/linux-wpan fork of radvd. Again: RIOT does receive the RA from 
radvd AND configures an IP with the provided prefix. Thus, the processing of 
RS+RA up this point seems to be correct, what's missing is the routers entry in 
RIOT. Further, RIOT does receive the COAP requests but it cannot send any 
reply, as it does not know the LLaddr for the destination (ULA) IP. As far as I 
remember my last digging into RIOTs NDP processing, RIOT does the following:

1. if DST_IP is link-local: extract LLaddr 
2. else if neighbor cache entry exist, use it
3. if no ncache: query (default) router for LLaddr
4. if no router: abort

I think I'm running into case 4, where no entry exists what so ever and thus no 
COAP reply is send.

@Alex as you joined the discussion: I also have a question regarding the Linux 
side. I currently use Raspbian with shipped Linux-Kernel 4.1.19. I observed 
that Linux still does NS for link-local address via the nodes scoped multicast 
address, instead of using 6lo 'shortcut' by extracting LL/MAC-address from the 
link-local IP. Is this fixed in some recent version?

Regards,
  Sebastian

> Am 22.04.2016 um 12:28 schrieb Alexander Aring :
> 
> Hi,
> 
> On Fri, Apr 22, 2016 at 12:19:36PM +0200, 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?
>> 
> 
> can you share your used radvd.conf?
> 
> - ALex
> ___
> 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+ULAs: no router entry

[Thomas C. Schmidt]

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] RIOT+ULAs: no router entry

[Cenk Gündogan]

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