RPL adds routes for own address via remote node

[GoogleCodeExporter]

What steps will reproduce the problem?
I am unsure of the exact conditions which cause this issue, but I can 
reasonably reliably reproduce it with four nodes daisy-chained (nodes 
restricted so they can only hear their direct neighbors).

Take the scenario A-B-C-D, then remove B temporarily, before bringing it back 
in. Inspect the routing table of node C, and you might see something like the 
following:
$ nc6 -u fd00:b81e:1::4 2000
route
key destination     gateway     iface
 2  fd00:b81e:1::5/128      fe80::f8de:ff:fe00:5        pan
 3  fd00:b81e:1::3/128      fe80::f8de:ff:fe00:3        pan
 4  fd00:b81e:1::4/128      fe80::f8de:ff:fe00:5        pan
 1  ::/0        fe80::f8de:ff:fe00:3        pan
^C

Here node A has address x::1, B is x::3, C is x::4 and D is x::5. Note that the 
routing table on node C contains a route for itself via node D!

When this happens on both nodes C and D, it appears this somehow causes packets 
destined for either to be forwarded back and forth, a lot. I don't see why it 
should do that even with these routes in place, but it seems to nevertheless.

What is the expected output? What do you see instead?
I would never expect to see a route for a local IP address listed via a remote 
node.

What version of the product are you using? On what operating system?
TinyOS 2.x trunk as of a few weeks ago.

Please provide any additional information below.
When enabling the MRHOF feature, the A-B-C-D scenario fails to converge 
properly, routing wise. I haven't investigated that further as we can live 
without that feature, but I was seeing a lot route-for-own-IP-via-remote-node 
entries with MRHOF enabled.

Original issue reported on code.google.com by jmatts...@dius.com.au on 20 Dec 2011 at 11:44

[GoogleCodeExporter]

Original comment by sdh...@gmail.com on 11 Jan 2012 at 5:03

[GoogleCodeExporter]

The change for this is done now.

Original comment by jeonggil...@gmail.com on 17 Jan 2012 at 9:11

• Changed state: Fixed