Release 2015.09 - RC2

[OlegHahm]

This issue lists the status of all tests for the Release Candidate 2 of the 2015.09 release.

Specs tested:

• 01-CI
• 02-Tests
• 03-Single Hop IPv6 ICMP
  • Task 01: 1000 packets transmitted, 1000 received, 0% packet loss, time 10.06171217 s
  • Task 02: 1000 packets transmitted, 1000 received, 0% packet loss, time 100.06128933 s
  • Task 03: 3600 packets transmitted, 3600 received, 0% packet loss, time 3599.06917114 s
• 04-Single Hop 6LoWPAN ICMP
  • Task 01: 1000 packets transmitted, 1000 received, 0% packet loss, time 18.06335692 s
  • Task 02: 1000 packets transmitted, 999 received, 1% packet loss, time 109.06740717 s
  • Task 03: 1000 packets transmitted, 993 received, 1% packet loss, time 276.06342833 s
  • Task 04: 10000 packets transmitted, 9998 received, 1% packet loss, time 1313.06892156 s
• 05-Single Hop Route
  • Task 01: 100 packets transmitted, 100 received, 0% packet loss, time 1.0614627 s
  • Task 02: 100 packets transmitted, 100 received, 0% packet loss, time 16.068110 s
  • Task 03: 10 packets transmitted, 10 received, 0% packet loss, time 0.0692516 s
• 06-Single Hop UDP
• 07-Multi Hop
• 08-Interop
  • For Linux testing a patched version of radvd is required, otherwise it won't send the SLLAO in the router advertisements.

[miri64]

• For Linux testing a patched version of radvd is required, otherwise it won't send the SLLAO in the router advertisements.

Can you offer a how-to for that?

[OlegHahm]

see http://www.spinics.net/lists/linux-wpan/msg03147.html

[miri64]

Thanks.

[miri64]

Packet buffer for task 3.1 is not empty and contains very short snips:

First runthrough:

packet buffer: first byte: 0x808a160, last byte: 0x808b960 (size: 6144)
~ unused: 0x808a160 (next: 0x808a4d8, size:  872) ~
================ chunk   0 (size:   16) ================
000000 08 00 00 00 08 00 00 00 3c 63 eb 52 3c 63 eb 52
~ unused: 0x808a4d8 (next: (nil), size: 5256) ~

Second runthrough:

packet buffer: first byte: 0x808a160, last byte: 0x808b960 (size: 6144)
~ unused: 0x808a160 (next: 0x808a4d8, size:  872) ~
================ chunk   0 (size:   16) ================
000000 08 00 00 00 08 00 00 00 3c 63 eb 52 3c 63 eb 52
~ unused: 0x808a4d8 (next: (nil), size: 5256) ~

Third runthrough:

packet buffer: first byte: 0x808a160, last byte: 0x808b960 (size: 6144)
~ unused: 0x808a160 (next: 0x808a208, size:  156) ~
================ chunk   0 (size:   12) ================
000000 fe ff ff ff 3c 63 eb 52 ff ff ff ff
~ unused: 0x808a208 (next: 0x808a360, size:  336) ~
================ chunk   1 (size:    8) ================
000000 01 00 00 00 08 00 00 00
~ unused: 0x808a360 (next: 0x808a390, size:   40) ~
================ chunk   2 (size:    8) ================
000000 08 00 00 00 08 00 00 00
~ unused: 0x808a390 (next: 0x808a3c0, size:   40) ~
================ chunk   3 (size:    8) ================
000000 18 00 00 00 08 00 00 00
~ unused: 0x808a3c0 (next: 0x808a414, size:   76) ~
================ chunk   4 (size:    8) ================
000000 08 00 00 00 08 00 00 00
~ unused: 0x808a414 (next: 0x808a444, size:   40) ~
================ chunk   5 (size:    8) ================
000000 08 00 00 00 08 00 00 00
~ unused: 0x808a444 (next: (nil), size: 5404) ~

Though the make-up seems to be quite random, the data in them seems to have some system to them. (0x08000000 appears quite often as well as 0x3263eb52 (which is part of the of the nodes MAC address 86:a4:3c:63:eb:52 or link-local IPv6 address fe80::84a4:3cff:fe63:eb52 respectively))

[OlegHahm]

01-CI fails because gcc is complaining for the ARM7 platforms:

unittests:msba2:
Building application "unittests" for "msba2" with MCU "lpc2387".

/home/oleg/git/RIOT/sys/ubjson/ubjson-read.c: In function '_ubjson_read_length':
/home/oleg/git/RIOT/sys/ubjson/ubjson-read.c:153:14: error: 'len64' may be used uninitialized in this function [-Werror=maybe-uninitialized]
     else if ((ssize_t) len64 < 0) {
              ^
cc1: all warnings being treated as errors

I don't really understand why this only happens for these platforms, but I guess we should "fix" this nevertheless.

[miri64]

The leaks in #5 (comment) are very race conditiony... And after 4h of debuging I still don't have any clue how this comes into being. Do we just want to mark this as a known issue, since that test case is somewhat fringy (at least in my opinion)?

[miri64]

(you don't usually ping all-nodes in a system that is just running, is what I wanted to say with "fringy")

[miri64]

It's leaking in 04 too btw if you use 3 nodes.

[OlegHahm]

That's bad. I couldn't find a leak even with 5 nodes in 04. How did you test?

[OlegHahm]

Pinged in the IoT-LAB with 5 nodes from one node to ff02::1 (1000 times, no delay, no payload) and all packet buffers stayed empty.

[OlegHahm]

Superseded by #6.

[OlegHahm]

Hm, okay, with a payload of 100 bytes, I can see some fragments. :-(

[OlegHahm]

Damn, I can create memory leaks even with just two nodes and unicast pings.

[cgundogan]

shouldn't your comments go to #6 ? Or are you testing with RC2 right now?

[OlegHahm]

RC3 doesn't really change anything on this matter.

[OlegHahm]

Though the make-up seems to be quite random, the data in them seems to have some system to them. (0x08000000 appears quite often as well as 0x3263eb52 (which is part of the of the nodes MAC address 86:a4:3c:63:eb:52 or link-local IPv6 address fe80::84a4:3cff:fe63:eb52 respectively))

The 0x0008 seems to be the IPv6 length field.