gnrc_rpl: old routes are not deleted #19423
Labels
Area: network
Area: Networking
Area: security
Area: Security-related libraries and subsystems
Type: bug
The issue reports a bug / The PR fixes a bug (including spelling errors)
A simple test with 4 nrf52dk boards (flashed with gnrc_networking example) probably shows several routing and related issues. The steps are:
Start ble advertising on board 4.
Scan for bleriot on board 2 and connect.
In some time (to speed up, use
rpl send dis
on non-root boards) the routing table on board 1 will be populated with downward routes to boards 2 and 3 directly and to board 4 through board 2, usenib route show
to view the forwarding table.Reset board 4 and re-initialize:
Scan for bleriot on board 3 and connect.
With
nib route show
on boards 2 and 3 observe that both of them have downward routes to board 4, and they distribute this route in RPL DAO messages to board 1 with approximately 60 seconds intervals. On board 1, the route to board 4 will be replaced with the one in the latest DAO received with either actual, from board 3, or stale, with board 2 as the next hop.I think this is not the desired behaviour, and RPL, as described in RFC 6550, has some mechanisms to mitigate distribution of stale routes - but it seems none of them work in RIOT. Actually, the routes were distributed for a very long time, more than an hour in one of the experiments, so probably even route deletion from the forwarding table after a timeout does not work as intended.
Even more, a No-Path in DAO messages (a Transit Information option with a Path Lifetime equal to 0) leads to a contrary result - the FT entry is created by calling
gnrc_ipv6_nib_ft_add
with 0 timeout, resulting in a permanently stored entry.Basically, the main question is: has anyone tested RIOT's RPL implementation in any decent-sized network with some dynamics, where nodes change parents? Probably the stale routes issue was never noticed on 802.15.4-based networks (and the test facilities like FIT IoT LAB let all nodes reach each other), but the connection-oriented link layer of BLE requires the routing table to be more or less up-to-date.
The text was updated successfully, but these errors were encountered: