tests/gnrc_rpl: add automated test for gnrc_rpl

[benpicco]

Contribution description

This adds an automated test for gnrc_rpl that spawns several native instances connected by ZEP dispatcher to simulate a mesh network.
The idea is that this can be run automatically by CI.

Testing procedure

Run make test in tests/gnrc_rpl.

Issues/PRs references

[benpicco]

I also tried to see if RPL recovers from a lost node, but apparently it doesn't

--- a/tests/gnrc_rpl/tests/01-run.py
+++ b/tests/gnrc_rpl/tests/01-run.py
@@ -147,6 +147,7 @@ def test_alternative_route(factory):
     # create native instances
     nodes = factory.get_shells(5)
     A = nodes[0]
+    B = nodes[1]
     D = nodes[3]
 
     # add prefix to root node
@@ -167,6 +168,25 @@ def test_alternative_route(factory):
     # 1 intermediate hop, 64 - 1
     assert result['replies'][0]['ttl'] == 63
 
+    # remove a node from the DOGAD
+    B.stop_term()
+    nodes.remove(B)
+
+    # wait for the the DODAG to recover, dummy ping the root
+    D.ping6(root_addr)
+    time.sleep(10)
+
+    # try to reach the root node again
+    result = parser.parse(D.ping6(root_addr))
+
+    print(result)
+    # assert packetloss is under 10%"))
+    assert result['stats']['packet_loss'] < 10
+    # assert at least one responder
+    assert result['stats']['rx'] > 0
+    # 2 intermediate hops, 64 - 2
+    assert result['replies'][0]['ttl'] == 62
+
     # terminate nodes
     for n in nodes:
         n.stop_term()

This is likely related to #17327

Also any suggestions to make this more pythonic are of course welcome 😉

[chrysn]

Just having looked at the Python parts (without particular knowledge of riotctrl), no show stoppers there.

The automated checks already complained about the whitespace (Python likes spaces around = at assignments, but not in named arguments).

My inline comments are all minor.

The "get shells" code might make sense to refactor up into riotctrl.

[aabadie]

The Python code seems good to me but I don't feel confident enough on the network part. I was also wondering if this test could fall under the test-with-config case but apparently, on native, no preliminary configuration is required. On hardware, I guess that's another story (which is skipped by the use of TEST_ON_CI_WHITELIST, not sure that's a good thing).

[benpicco]

On hardware, I guess that's another story (which is skipped by the use of TEST_ON_CI_WHITELIST, not sure that's a good thing).

I don't think it's currently possible to have an automatic test that uses several hardware nodes on Murdock 😉
The network part is really just adding dual-stack support to ZEP dispatcher because Murdock does not support IPv6.

[aabadie]

I don't think it's currently possible to have an automatic test that uses several hardware nodes on Murdock

On Murdock, that would be difficult indeed. But in theory, with riot_ctrl, it's possible to run a test script with several hw nodes. Some of the release test do that already. But that would need some setup and thus fall under the test-with-config case.

[kaspar030]

Suggested change

[kaspar030]

ACK.

Python looks fine.