search

contiki-os / contiki

The official git repository for Contiki, the open source OS for the Internet of Things
http://www.contiki-os.org/
Other
3.71k stars 2.58k forks source link

Not all Neighbor State Changes are notified to RPL #1379

Open pablocorbalan opened 8 years ago

pablocorbalan commented 8 years ago

The uIPv6 uip-ds6-nbr.c provides a callback called NEIGHBOUR_STATE_CHANGED that notifies (in the current implementation) the addition or removal of a new neighbor to RPL. However, within the uip_ds6_neighbor_periodic function, the state of a neighbor can be changed and not be notified to RPL. These changes with the default current configuration (NDP disabled) may put a REACHABLE neighbor to DELAY or STALE state, i.e., we may have an uncertain link with a neighbor due to no message has been received from the neighbor to refresh its entry in the routing table.

My question then is, should we also call the NEIGHBOUR_STATE_CHANGED function within the uip_ds6_neighbor_periodic function and purge the rank and routes that we may have to those nodes? Do you think that this may have any implications in the current RPL behaviour?

I could create a PR to solve this, but I do not know if this is known and is let this way intentionally.

joakimeriksson commented 8 years ago

I think it would be a good thing if RPL can act upon these changes (e.g. REACHABLE => STALE, etc). Not saying I exactly now how it should act, but one option would probably be to probe that parent/child and if the probe gets a response RPL could set back the state to REACHABLE if it was not (this would allow RPL to keep that as a valid neighbour / route, etc - even with NS/NA turned off). As it is today I guess a configuration like the one you mention is a really bad combination since that will cause disconnects as soon as RPL is stable (e.g. trickle timers are sending less often).