The problem seems to be that the parent is not being correctly marked as a parent in the ZED's neighbour table (it gets marked as a sibling instead), meaning that the entry for the parent can be overwritten. We've found that setting mDefaultReuseAddressPolicy_c to TRUE in the End Device seems to mitigate the problem initially (i.e. the parent is marked with the correct relationship when it is joined for the first time), but when we turn the original parent off and force the ZED to do a NWK Rejoin it will change over to a new parent and mark this new parent as a 'sibling' in the NT. From then onwards we get the same problem where the parent entry in the NT (the one that is incorrectly listed as a sibling) is overwritten by incoming Link Status messages from neighbouring routers.
We think we can get around this by manually modifying the parent's NT entry to be a parent if we observe the NT change - that might come with its own baggage but at least it's a possible way forward.
This also makes us wonder about the Freescale ZED implementation and orphan rejoining (which we are not using at the moment) - we've never been able to work out what orphan rejoining is for or how it works ... or why FS implemented this at all. But given that the ZED maintains a list of parent candidates in its neighbour table (using Link Status messages), is it the case that orphan rejoin uses those existing entries without doing a scan, and that's what makes it useful?
