Open MichelRottleuthner opened 5 years ago
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 ;-)
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...
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.
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.
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.
Ping @MichelRottleuthner?
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.
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.
@benpicco could you check if this was maybe fixed with one of your many NIB fixes?
That sounds a lot like the same problem described in https://github.com/RIOT-OS/RIOT/pull/16988.
https://github.com/RIOT-OS/RIOT/pull/16988/commits/bed34daa61bfa6273f95e9e86cf90e448a8ed67e should fix it by joining the solicited node multicast group.
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
withUSEMODULE += 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 runsudo 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) usingUSEMODULE += 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