gnrc_ipv6_nib: don't autoconfig IPv6 address without L2 addr

[miri64]

Contribution description

If the interface's link-layer doesn't use link-layer addresses it obviously doesn't make sense to auto-configure an IPv6 address from it. Moreover, I think the address fe80:: is actual illegal, but I couldn't find any references for it.

Testing procedure

Try running an application with slipdev. The interfaces should not have an auto-configured IPv6 address with this PR. Without this PR an address fe80:: (and the respective solicited nodes multicast address) show up.

Issues/PRs references

Unrelated but found when debugging #10480.

[miri64]

Ping? Maybe @gebart also could review, as he tested with #10480.

[jnohlgard]

Change makes sense. Will test on actual hardware

[miri64]

@gebart did you?

[miri64]

@kb2ma might you have time to have a look into this?

[kb2ma]

Tested on samr21-xpro. On current master I see the output below from ifconfig. When using this PR, the fe80:: line goes away as expected. I can still send and receive a CoAP message across the tunslip interface.

2019-04-05 06:29:05,297 - INFO # Iface  8 
2019-04-05 06:29:05,300 - INFO #           MTU:65535  HL:64  RTR  
2019-04-05 06:29:05,302 - INFO #           RTR_ADV  
2019-04-05 06:29:05,305 - INFO #           Link type: wired
2019-04-05 06:29:05,309 - INFO #           inet6 addr: fe80::  scope: local  VAL
2019-04-05 06:29:05,312 - INFO #           inet6 group: ff02::2
2019-04-05 06:29:05,315 - INFO #           inet6 group: ff02::1
2019-04-05 06:29:05,318 - INFO #           inet6 group: ff02::1:ff00:0

Please rebase. I'll retest and confirm I see the debug message in the code.

[miri64]

Please rebase. I'll retest and confirm I see the debug message in the code.

Which debug message? I'm not quite sure why I need to rebase.

[kb2ma]

I asked for a rebase because the PR is 4 months old. I don't know if any updated code in other parts of the network stack might impact the functionality in this PR. At any rate, not necessary now. I rebased myself for testing.

This PR still tests fine. My only question is when DEBUG is on in this module. I see the sequence of messages below. Is it confusing to see both line 2 and line 3, which was added by this PR? I don't know enough about debugging the network layer to give an opinion.

INFO # nib: add address based on fe80::/64 automatically to interface 7
INFO # nib: add address based on fe80::/64 automatically to interface 8
INFO # nib: interface 8 has no link-layer addresses

[miri64]

I asked for a rebase because the PR is 4 months old. I don't know if any updated code in other parts of the network stack might impact the functionality in this PR. At any rate, not necessary now. I rebased myself for testing.

Since murdock is doing this as well before compiling, I guess this isn't necessary at all ;-).

This PR still tests fine. My only question is when DEBUG is on in this module. I see the sequence of messages below. Is it confusing to see both line 2 and line 3, which was added by this PR? I don't know enough about debugging the network layer to give an opinion.

INFO # nib: add address based on fe80::/64 automatically to interface 7
INFO # nib: add address based on fe80::/64 automatically to interface 8
INFO # nib: interface 8 has no link-layer addresses

Ah, will move the check above the first DEBUG. This way it is less confusing, I hope.

[miri64]

Ah, will move the check above the first DEBUG. This way it is less confusing, I hope.

Done.

[kb2ma]

Apologies for the delay, @miri64. I missed your fixup message.

Now I see the debug messages below. This definitely is clearer. ACK, please squash.

2019-04-18 21:09:08,535 - INFO #  nib: add address based on fe80::/64 automatically to interface 7
2019-04-18 21:09:08,539 - INFO # nib: interface 8 has no link-layer addresses

[miri64]

Squashed

[miri64]

@danpetry I think this should be backported. Do you agree?