01-CI: Task-4: Assertion Failed: with DEBUG_ASSERT_VERBOSE, the following is added to the output:

sys/net/gnrc/netreg/gnrc_netreg.c:45 => 0x8001a49

I tested this remotely on IoT-LAB.

from release-specs.

Reminder to myself: 05-Task 1 descriptions needs adaption

from release-specs.

@PeterKietzmann see #56

from release-specs.

Tested 05-Task 1. It works (when compiled with -DGNRC_NETIF_IPV6_GROUPS_NUMOF=5), but with the changes in NIB it is a little bit non-sensical now: Since ifconfig add doesn't allow for setting the flags of the prefix (and shouldn't IMHO) and since the interface is a non 6Lo interface, the prefix is marked on link. This causes the NIB to look-up beef::1 in the neighbor cache (which is completely legal behavior) instead of searching for a route first, since due to the flag it knows, that beef::1 is a direct neighbor. An alternative could be to deactivate router advertisements all together before the test starts. But for this the description needs to be updated.

from release-specs.

I don't completely understand your explanation (I'm no NDP expert and wasn't involved in either the NIB or NDP rework).

• who/which instance sets the prefix flags now and why is it different now than before?
• IMO -DGNRC_NETIF_IPV6_GROUPS_NUMOF=5 should at least go in the experiment description, if it is necessary
• I think we should try to reflect what was intended with this test before. I don't exactly know what that is but for me it seems like different static routes without routers. As for the router stuff, this is tested in task 7&8 right?

@smlng other opinions?

from release-specs.

• who/which instance sets the prefix flags now and why is it different now than before?

The "admin" (in this case the user, using ifconfig add 😉), as to why it is different than before: because the look-up sequence was way more complicated before (looking in the FIB, nope, looking in the NC, nope, looking in the FIB again...). Now this is way more stream-lined (looking if address could be neighbor, nope, looking in the FIB).

• IMO -DGNRC_NETIF_IPV6_GROUPS_NUMOF=5 should at least go in the experiment description, if it is necessary

If router advertisements are deactivated as proposed, this is not necessary (because beef:: isn't advertised as a prefix anymore so it isn't assumed to be a direct neighbor, and a lookup in the FIB is done). However, there is a fix required for that, as final router advertisements (when the router seizes to be an advertising interface it sends 3 final router advertisements with lifetime == 0) are not dealt with correctly at the moment. See RIOT-OS/RIOT#8393 for that.

• I think we should try to reflect what was intended with this test before. I don't exactly know what that is but for me it seems like different static routes without routers. As for the router stuff, this is tested in task 7&8 right?

I'm not sure what you mean by that... Maybe stems from some misunderstanding from what I wrote before? The nodes are still routers in any case. They just don't advertise themselves as such with the proposed fix (see fixup in #56). Since we are using static routes anyway, it is not necessary for the router advertisements to be advertised.

from release-specs.

Task 01.01 is not fully successful, there is a linker error in tests/pkg_fatfs_vfs see RIOT-OS/RIOT#8408 - curios why Murdock didn't report that.

from release-specs.

01-CI: Task-4: Assertion Failed: with DEBUG_ASSERT_VERBOSE, the following is added to the output:

Well.... Why is DEVELHELP activated for the unittests anyway?

from release-specs.

was discussed and enabled in RIOT-OS/RIOT#8080

from release-specs.

The problem with that is, that the unittests are using mock values. So that particular assert checks, if a message queue is set for a thread that doesn't even exist... I rather would keep it this way, because this way the unittests can test corner cases (what they are supposed to do).

from release-specs.

@miri64 can you give me step-by-step guidance how you tested task-05? What did you configure on both instances? I'm not able to reproduce what I intended...

from release-specs.

@miri64 can you give me step-by-step guidance how you tested task-05? What did you configure on both instances? I'm not able to reproduce what I intended...

You asked for step-by-step 😜

Preperation

Merge RIOT-OS/RIOT#8393 into RC1:

cd ${YOUR_RIOTREPO}
git fetch --tags git://github.com/RIOT-OS/RIOT
git checkout 2018.01-RC1
git fetch git://github.com/RIOT-OS/RIOT refs/pull/8393/head
git merge FETCH_HEAD

Task 5.1

Compile examples/gnrc_networking for native and set-up TAP bridge (if not done already)

make -C examples/gnrc_networking
dist/tools/tapsetup/tapsetup

Start 2 native instances (called A and B in the following):

make -C examples/gnrc_networking term
# in another terminal
PORT=tap1 make -C examples/gnrc_networking term

Within A:

# disable router advertisements
ifconfig 6 -rtr_adv

Within B:

# disable router advertisements
ifconfig 6 -rtr_adv
# add GUA
ifconfig 6 add beef::1
# check link-local address and if GUA is set
ifconfig

Within A again

# configure default route to B
nib route add 6 :: <link-local address of B>
# check if route is set
nib route
# start actual test
ping6 100 beef::1 1024 10

Task 5.2

Compile examples/gnrc_networking for iotlab-m3 and and start an experiment on IoT-LAB

BOARD=iotlab-m3 IOTLAB_SITE=<choose one> IOTLAB_NODES=2 IOTLAB_DURATION=5 make -C examples/gnrc_networking iotlab-exp iotlab-term

In the following the allocated nodes are called m3-x and m3-y (just replace with the corresponding number):

# check which node is which + which link-layer addresses to choose
ifconfig
# set affe::1/120
m3-x;ifconfig 7 add affe::1/120
# set beef::1/64
m3-y;ifconfig 7 add beef::1
# set route on m3-x
m3-x;nib route add :: via <link-layer address of m3-y>
# set route on m3-y
m3-y;nib route add :: via <link-layer address of m3-x>
# start actual test
ping6 100 beef::1 1024 10

Task 5.3

Compile examples/gnrc_networking for native and set-up TAP bridge (if not done already)

make -C examples/gnrc_networking
dist/tools/tapsetup/tapsetup

Start 2 native instances (called A and B in the following):

make -C examples/gnrc_networking term
# in another terminal
PORT=tap1 make -C examples/gnrc_networking term

Within A:

# disable router advertisements
ifconfig 6 -rtr_adv

Within B:

# disable router advertisements
ifconfig 6 -rtr_adv
# add GUA
ifconfig 6 add beef::1
# check link-local address and if GUA is set
ifconfig

Within A again

# configure route to B
nib route add 6 beef::/64 <link-local address of B>
# check if route is set
nib route
# start actual test
ping6 10 beef::1 1024 10

from release-specs.

@aabadie I also checked https://github.com/RIOT-OS/Release-Specs/blob/master/01-ci/01-ci.md#task-04 and can confirm your finding. However it seems the failed assertion is caused by wrong ordering of preprocessor if-else, fix is in RIOT-OS/RIOT#8439.

I also found that unittests/tests-littlefs fails on pba-d-01-kw2x and samr21-xpro with:

2018-01-25 14:43:07,234 - INFO # main(): This is RIOT! (Version: 2018.04-devel-mobi25.inet.haw-hamburg.de-HEAD)
2018-01-25 14:43:07,238 - INFO # .lfs error: Corrupted dir pair at 0 1
2018-01-25 14:43:07,242 - INFO # lfs error: Invalid superblock at 24773 22755
2018-01-25 14:43:07,248 - INFO # lfs error: Corrupted dir pair at 0 1
2018-01-25 14:43:07,253 - INFO # lfs error: Invalid superblock at 1936090476 22723
2018-01-25 14:43:07,261 - INFO # .lfs error: Corrupted dir pair at 0 1
2018-01-25 14:43:07,265 - INFO # lfs error: Invalid superblock at 16777215 20
2018-01-25 14:43:07,274 - INFO # .lfs error: Corrupted dir pair at 0 1
2018-01-25 14:43:07,278 - INFO # lfs error: Invalid superblock at 16777215 10575
2018-01-25 14:43:07,287 - INFO # lfs warn: No more free space 4
2018-01-25 14:43:07,288 - INFO # 
2018-01-25 14:43:07,295 - INFO # littlefs_tests.tests_littlefs_write (tests/unittests/tests-littlefs/tests-littlefs.c 177) exp 11 was -28
2018-01-25 14:43:07,300 - INFO # .lfs warn: No more free space 8
2018-01-25 14:43:07,301 - INFO # 
2018-01-25 14:43:07,310 - INFO # littlefs_tests.tests_littlefs_unlink (tests/unittests/tests-littlefs/tests-littlefs.c 209) exp 11 was -28
2018-01-25 14:43:07,318 - INFO # .lfs warn: No more free space 12
2018-01-25 14:43:07,319 - INFO # 
2018-01-25 14:43:07,328 - INFO # littlefs_tests.tests_littlefs_readdir (tests/unittests/tests-littlefs/tests-littlefs.c 235) exp 0 was -28
2018-01-25 14:43:07,335 - INFO # .lfs warn: No more free space 16
2018-01-25 14:43:07,335 - INFO # 
2018-01-25 14:43:07,346 - INFO # littlefs_tests.tests_littlefs_rename (tests/unittests/tests-littlefs/tests-littlefs.c 317) res == sizeof(buf)
2018-01-25 14:43:07,351 - INFO # .lfs warn: No more free space 20
2018-01-25 14:43:07,351 - INFO # 
2018-01-25 14:43:07,361 - INFO # littlefs_tests.tests_littlefs_statvfs (tests/unittests/tests-littlefs/tests-littlefs.c 369) res == sizeof(buf)
2018-01-25 14:43:07,363 - INFO # 
2018-01-25 14:43:07,365 - INFO # run 7 failures 5
2018-01-25 14:43:24,283 - INFO # Exiting Pyterm

from release-specs.

However it seems the failed assertion is caused by wrong ordering of preprocessor if-else, fix is in RIOT-OS/RIOT#8439.

They are not wrongly ordered and your fix can cause false negative assertions, e.g. with gnrc_sock.

from release-specs.

task 04-06 fails with packet loss of 20 - 30 %in either direction

from release-specs.

task 04-06 fails with packet loss of 20 - 30 %in either direction

For task05 I did not encounter that. Neither for Ethernet nor for IEEE 802.15.4 oO

from release-specs.

just to clarify I meant https://github.com/RIOT-OS/Release-Specs/blob/master/04-single-hop-6lowpan-icmp/04-single-hop-6lowpan-icmp.md#task-06-experimental, while 04-task-05 works fine for me, too

from release-specs.

Ah. Well they are marked as experimental, though it might be worth investigating for the next release why fragmentation causes a lower PDR for the cc2538.

from release-specs.

for 01-ci, task 04 only tests-littlefs constantly fails, the netreg tests succeeds with DEVELHELP=0

from release-specs.

RC2 is out, please help out there #58

from release-specs.

outdated by RC2 in #58

from release-specs.