Release 2016.07 - RC1

[kYc0o]

This issue lists the status of all tests for the Release Candidate 1 of the 2016.07 release.

Specs tested:

• 01-CI
  • Task 01 [SUCCESS]
  • Task 02 [SUCCESS]
  • Task 03 [SUCCESS]
  • Task 04 [SUCCESS]
• 02-Tests
  • Task 01 [SUCCESS, cf. https://github.com/02-tests/task 01 Release 2016.07 - RC1 #22]
  • Task 02 [SUCCESS, cf. https://github.com/02-tests/task 02 Release 2016.07 - RC1 #23]
  • Task 03 [SUCCESS, cf. https://github.com/02-tests/task 03 Release 2016.07 - RC1 #24]
• 03-Single Hop IPv6 ICMP
  • Task 01
  • Task 02
  • Task 03
• 04-Single Hop 6LoWPAN ICMP
  • Task 01 [SUCCESS]
  • Task 02 [FAIL https://github.com/at86rf2xx: lost interrupts RIOT#5486]
  • Task 03 [SUCCESS]
  • Task 04 [SUCCESS]
• 05-Single Hop Route
  • Task 01 [SUCCESS]
  • Task 02 [FAIL https://github.com/at86rf2xx: lost interrupts RIOT#5486]
  • Task 03 [SUCCESS]
• 06-Single Hop UDP [SUCCESS]
• 07-Multi Hop
  • Task 01 [SUCCESS]
  • Task 02 [SUCCESS]
  • Task 03 [SUCCESS]
  • Task 04 [SUCCESS]
• 08-Interop
  • Task 01
  • Task 02
  • Task 03
  • Task 04
  • Task 05
  • Task 06
  • Task 07
  • Task 08 [FAIL https://github.com/lwip: initialize link-local address correctly RIOT#5718 + interop problems from lwIP's side]
  • Task 09
  • Task 10 [FAIL https://github.com/lwip: initialize link-local address correctly RIOT#5718 + interop problems from lwIP's side]

[BytesGalore]

Currently performing

• 02-Tests
  • Task 01

Observations:

• driver_dht compiles without warning runs and obviously fails
• driver_pir compiles without warning runs and obviously fails on GPIO access
• emb6 automatically sets samr21-xpro as target and fails on missing compiler

more to come :)

[BytesGalore]

I made #22 to discuss collect observations for 02-Tests/Task 01

[kYc0o]

Great! Thanks! :D

[PeterKietzmann]

I will start with with 03-Single Hop IPv6 ICMP

[PeterKietzmann]

I will continue with 04-Single Hop 6LoWPAN ICMP

[kYc0o]

Can you edit the comment to update if the tests were successful?

[PeterKietzmann]

04-Single Hop 6LoWPAN ICMP Task 03 gets stuck

[PeterKietzmann]

(tested with iotlab-m3 to iotlab-m3 and iotlab-m3 to samr21-xpro)

[miri64]

Uhm, where is the tag to test this against?

[kYc0o]

I didn't do it, can you? I don't know if I have rights.

[PeterKietzmann]

Just for the record: I tested with commit b5cb68bd6673abe02166f8af7782aa2745ca08cd

[miri64]

Mh come to think of it @OlegHahm you want to wait for RIOT-OS/RIOT#2071 to be merged before we create 2016.07-branch (on which RC1 would be)... so let's wait for it.

[kYc0o]

Yes @PeterKietzmann that's the last commit before the last PR was merged this afternoon. @miri64 I'd like to wait for that one too.

[miri64]

@kYc0o and when we backport it?

[kYc0o]

Performing Task 01

[PeterKietzmann]

Performing 06-Single Hop UDP now on the pre-RC

[BytesGalore]

I made #23 and #24 for the remaining 02-Tests/*

[kYc0o]

CI task 01 works only with launchpad versions of arm-none-eabi-gcc, and fails with embedded versions at least on Debian Jessie and Ubuntu 14.04.

edit: it was task 01.

[BytesGalore]

02-Tests succeeded

[kYc0o]

I'm going through 07

[PeterKietzmann]

04/Task 03 and 05/Task 02 are failing on a node (iotlab-m3). It seems the great payload size (1KB) is the problem

[miri64]

@PeterKietzmann at which side did you do your experiments. I had high packet loss in Grenoble because the nodes picked by default by the cli-tools are very close to a running experiment. Just tried 04/Task 03 in Grenoble Lyon and hand no problems (still running but should be >90% received)

[miri64]

Now it's done: it was it 0% packet loss in Lyon.

[PeterKietzmann]

Hmm. I've tested in Paris as well as on my desk.

[kYc0o]

Sorry I'm also using grenoble for RPL experiments. However theres someone abusing on the usage, maybe he's generating traffic and interferences.

[PeterKietzmann]

And you tried with ping6 100 <addy> 1000 0 10?

[PeterKietzmann]

PS: Paris was nearly unused at that time

[miri64]

No ping6 100 <addy> 1024 10 is the correct one. Forgot, what stats interval is, but its not needed for these tests.

[miri64]

Sorry I'm also using grenoble for RPL experiments. However theres someone abusing on the usage, maybe he's generating traffic and interferences.

@kYc0o for small payloads background traffic is no problem, but for 1024 B (when your IPv6 packet consists of >10 radio frames) or even smaller (in my tests problems started at around 550 B) the packet loss is naturally much higher.

[kYc0o]

Ok let's put it in the Release notes as a known issue, hoping to solve it for the next release.

[PeterKietzmann]

BTW: would you share a link to the WIP release notes? Maybe link it somewhere in the issue description above?

[kYc0o]

There is one since the beginning that I'd be sooo glad to get help with :)

[miri64]

I did the RIOT<=>RaspPi tests on a samr21-xpro, since my IoT-Lab nodes don't seem to be usable anymore (terminal does not react :(). Should be valid anyway.

[miri64]

Since I'm the one who introduced emb6 and lwIP I think its best if someone else does 8.8-10. @BytesGalore, what about you? You used the applications in Task 2 already ;-).

[miri64]

Oh and @kYc0o can you please do 8.3?

[kYc0o]

Yes I'll do it asap

[miri64]

I think tomorrow would suffice ;-)

[PeterKietzmann]

I will try 8.8-10 today. @BytesGalore scream if you already started testing.

[kYc0o]

I'd like to wait for #5698 before making lwip tests but it seems to fail with Murdock...

[PeterKietzmann]

@kYc0o #5698 is not a bugfix. Why should it go into the release branch?

[kYc0o]

Yes I know it's not a bugfix but lwip is intended to run on native, which would be able to compile the tests and if it fails we should fix it... But we can continue like this if you think it's not really an obstacle.

[PeterKietzmann]

I had some problems testing 08/08 and 08/10. For GNRC I used the default examples/gnrc_networking and for lwip tests/lwip. I sniffed the traffic in parallel to see what is going on.

1.1 GNRC to lwip
GNRC sends UDP packets but lwip does not react.

1.2 lwip to GNRC
Instead of directly sending the UDP packet to the link local address, the lwip sends a neighbour solicitation (NS) message to the GNRC node. GNRC answers with four neighbour advertisements (NA) (probably L2 retransmissions?). That NS, NA sequence occurs three times.

2.1 emb6 to lwip
emb6 simply sends out a UDP packet but the lwip does not (visibly) react on that.

2.2 lwip to emb6
Instead of simply sending a UDP packet, the lwip node sends a NA on which the em6 node responds with a NS. That happens three times

Additionally I tried lwip to lwip. That worked as expected. There one can see a sequence of NS, NA, UDP.

@miri64 "promised" to have a look at it later.

[PeterKietzmann]

@kYc0o if #5698 is needed to perform task 01/02 it would be fine with me.

[kYc0o]

I did the RIOT<=>RaspPi tests on a samr21-xpro, since my IoT-Lab nodes don't seem to be usable anymore (terminal does not react :(). Should be valid anyway.

Yes of course, the goal is to test interoperability between RIOT and RaspPi, so with a samr21 it's also valid.

[miri64]

So lwIP is the only one that is problematic? Do I see that right?

[PeterKietzmann]

From what I reported it seems that interoperability with lwip is the critical part, yes.

[miri64]

Okay, I digged into it now and basically this is the problem:

• this is the nodes EUI-64 5a:5a:5c:5c:87:92:76:0e
• and this is the generated link-local address from it: fe80::5c5c:5a5a:e76:9287

So somehow the bytes of the address get quite mixed up :-/, so the backtranslation RIOT does for link-local addresses does not work. I'll try to find out if that's a problem with my glue-code or a problem with lwIP itself. For now I would using vanilla-NDP with 6LoWPAN for interop with lwIP (which is "easy" with GNRC if you know your way around the dependencies gnrc_ipv6_router_default pulls in). No idea, why emb6 has a problem with that, but I suspect they implement this part of RFC 6775.

[miri64]

Okay another problem is that while parsing the IEEE 802.15.4 header lwIP is just "skipping" the source PAN not checking if source PAN compression is activated. So this is a bug on lwIP's side. For the order of the EUI-64 bytes I'll open a PR regardless, but I would just create a known issue, that lwIP's 6LoWPAN support is pretty insular for now.

[miri64]

though... that's a known issue for lwIP... not for us I would say.

[miri64]

For PR RIOT-OS/RIOT#5718.

[kYc0o]

Can we reference the failing tests to their corresponding issues?

[miri64]

Done

[kYc0o]

Great! so I need to finish the RPL stuff and then try Contiki interop and we should be done! :D

[PeterKietzmann]

Any progress?

[kYc0o]

No but I think I'll give up... I'll finish the release notes today and make the release announcement.

[miri64]

I'd like to have a look at the release notes, too and maybe find time to help in the afternoon.

[kYc0o]

OK let's wait to the afternoon to make the release ;)