Neighbor Discovery not working after router reboot when using SLAAC

[MichelRottleuthner]

Description

When using the GNRC_IPV6_NIB_CONF_SLAAC option a network connection to a riot node doesn't recover to a working state after a router reboot.
Actually this doesn't seem to be a real bug in riot but more an iterop problem between riot and linux.
After offline discussion with @smlng I'm adding it here mostly for documentation and discussion with more people.
Since linux-wpan is basically the goto-solution when setting up a linux based border router it would be nice if we could somehow avoid/improve/workaround this problem, any opinions on that?

Steps to reproduce the issue

Requirements: a riot board with radio and a border router (e.g. raspi) with ssh access.
Use examples/gnrc_networking replace USEMODULE += gnrc_ipv6_router_default with USEMODULE += gnrc_ipv6_default.

Compile with CFLAGS=-DGNRC_IPV6_NIB_CONF_SLAAC BOARD=whatever make all flash term

After that reboot the riot board and observe that everything looks ok with ip neigh show dev lowpan0 on your border router.
Then perform a router reboot (or run sudo ip neigh flush dev lowpan0 on it to get the same effect) and then try to ping the global address of the board -> this will fail with destination unreachable.

Only way to get it back to a working state is to reboot the riot board.

This problem does not appear if either:
a) NOT using CFLAGS=-DGNRC_IPV6_NIB_CONF_SLAAC
b) using USEMODULE += gnrc_ipv6_router_default

The reason seems to be that the router is sending the Neighbor Solicitation to the solicited node multicast address but riot is not handling it in this specific configuration.

Expected results

Riot node is reachable via it's global address after a router reboot.

Actual results

Riot node is unreachable via it's global address after a router reboot.

Versions

current master
Related: #4353

[miri64]

Alternatively run without classic DAD and set the ABRO in the router advertisements within the radvd config. It's even documented in @smlng's tutorial ;-)

[MichelRottleuthner]

The ABRO is already set in the radvd config and classic DAD is performed with gnrc_ipv6_router_default enabled, right? The problem I have then is that the global address of the riot node is marked tentative which I'd also like to avoid...

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[benemorius]

Is this still an issue? I used to encounter it but I haven't in a while and just now I did a quick reboot test and I wasn't able to reproduce the problem. I could be accidentally masking the bug somehow.

[miri64]

Ping @MichelRottleuthner?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[miri64]

@benpicco could you check if this was maybe fixed with one of your many NIB fixes?

[benpicco]

That sounds a lot like the same problem described in #16988.

bed34da should fix it by joining the solicited node multicast group.