gnrc_ipv6: only discard invalid source when assigned to interface

[miri64]

Contribution description

While it is correct to not use an invalid address as a source address, it is incorrect to assume that addresses not assigned to the interface (idx == -1 in the respective piece of code) are invalid: Other than classic forwarding via a FIB, forwarded packets utilizing a IPv6 routing header will pass this check, like any other packet sent by this node. The source address for these is not on the given node, so e.g. source routing is not possible at the moment.

Testing procedure

Testing procedures from #11970 should still work (was unable to test this atm due to lacking hardware).

With #12440 merged tests/gnrc_rpl_srh passes (requires dist/tools/tapsetup/tapsetup to be called before and also must be called with sudo).

Issues/PRs references

Follow-up to #11970
Fixes parts of #12436
Accompanies #12440

[miri64]

Rebased to current master to include now merged #12440.

[kb2ma]

At this point, tests/gnrc_rpl_srh should work, correct? Instead b5b52c7 results like below for me:

Traceback (most recent call last):
  File "/home/kbee/dev/riot/repo/tests/gnrc_rpl_srh/tests/01-run.py", line 384, in <module>
    sys.exit(run(testfunc, timeout=1, echo=False))
  File "/home/kbee/dev/riot/repo/dist/pythonlibs/testrunner/__init__.py", line 29, in run
    testfunc(child)
  File "/home/kbee/dev/riot/repo/tests/gnrc_rpl_srh/tests/01-run.py", line 368, in testfunc
    run(test_forward_uncomp)
  File "/home/kbee/dev/riot/repo/tests/gnrc_rpl_srh/tests/01-run.py", line 361, in run
    raise e
  File "/home/kbee/dev/riot/repo/tests/gnrc_rpl_srh/tests/01-run.py", line 357, in run
    func(child, tap, hwaddr_dst, lladdr_dst, lladdr_src)
  File "/home/kbee/dev/riot/repo/tests/gnrc_rpl_srh/tests/01-run.py", line 265, in test_forward_uncomp
    assert(IPv6ExtHdrRouting in p)
AssertionError

[cgundogan]

Interestingly, 7 out of 10 times I get a SUCCESS. However, the other 3 times I see the same error described by @kb2ma

[cgundogan]

Sometimes, I even hit another assert:

Traceback (most recent call last):
  File "/tmp/RIOT/tests/gnrc_rpl_srh/tests/01-run.py", line 384, in <module>
    sys.exit(run(testfunc, timeout=1, echo=False))
  File "/tmp/RIOT/dist/pythonlibs/testrunner/__init__.py", line 29, in run
    testfunc(child)
  File "/tmp/RIOT/tests/gnrc_rpl_srh/tests/01-run.py", line 366, in testfunc
    run(test_multicast_addr)
  File "/tmp/RIOT/tests/gnrc_rpl_srh/tests/01-run.py", line 361, in run
    raise e
  File "/tmp/RIOT/tests/gnrc_rpl_srh/tests/01-run.py", line 357, in run
    func(child, tap, hwaddr_dst, lladdr_dst, lladdr_src)
  File "/tmp/RIOT/tests/gnrc_rpl_srh/tests/01-run.py", line 227, in test_multicast_addr
    assert(len(p) == 0)
AssertionError

[miri64]

Ok, then it is still flakey. I will have another look if it is related or yet another regression introduced since last release.

[miri64]

Ok, a quick sniff with Wireshark during a test run confirmed to me, that this is the same sniffer syncing issue I already described in the testing procedures of #10392 (the packets are forwarded as they should, but they are not picked up by the scapy sniffer). So this is a bug in the test, not in the network stack. If I find the time, I will port these tests to scapy automata, similar as I did for emcute in #11823, but for this release I think we can go as is.

[miri64]

For the other observation by @cgundogan, I think it picks up a packet previously on the medium, so a syncing issue again.

[miri64]

(I don't see any ICMPv6 error messages nor second UDP packet on the TAP interface during the run of those specific tests, even when they fail)

[cgundogan]

The fix is sensible and tests/gnrc_rpl_srh runs successful (excluding the sporadic failures due to scapy sniffer running out-of-sync)

[miri64]

Testing procedures from #11970 should still work (was unable to test this atm due to lacking hardware).

Has someone retested this as well?

[cgundogan]

From #11970:

Classic ND should work as expected. To test this I used radvd on my host system with the following config

interface tapbr0 {
    AdvSendAdvert on;
    prefix 2001:db8:0:1::/64
    {
         AdvOnLink on;
         AdvAutonomous on;
    };
};

If using native (with dist/tools/tapsetup/tapsetup to create the TAP interfaces) the 2001:db8:0:1:: address of the node should become valid a few seconds after the node started.

The address is still set to VAL on native for me.

I try to get my hands on a pi for the 6lo-nd test

[cgundogan]

I confirm now that this PR does not change the following behaviour:

• RasPi BR announces ABROs. RIOT node configures a global address with TNT[3] set. Ping does not work.
• Pinging in above setup works, when compiling with GNRC_IPV6_NIB_CONF_SLAAC=1

[miri64]

Thanks for the review and testing!

[miri64]

Backport provided in #12458