Bug 1930

Created attachment 1849 [details]
mercurial patch to the reported issue (created with hg export)

In the olsr implementation, neighbor tuples are removed when their link tuples are removed due an expiration timer. The function which does this is:

> void RoutingProtocol::RemoveLinkTuple (const LinkTuple &tuple)

It removes the link tuple first and then the neighbor tuple:

> m_state.EraseLinkTuple (tuple);
> m_state.EraseNeighborTuple (GetMainAddress (tuple.neighborIfaceAddr));

The tuple reference "const LinkTuple &tuple" passed to RemoveLinkTuple is usually a reference on the link tuple itself, not a copy of it. The first statement, the call to the EraseLinkTuple function, erases the original, however.

Since the link tuples are stored in a std::vector, which is implemented as an array and partly resorted after erasing an element, the reference usually points to *another* link tuple after the original link tuple is erased.

The effect is that the right link tuple is deleted, but the *wrong* neighbor tuple will be removed.

A check like the following can be used to show the error:

> Ipv4Address a = tuple.neighborIfaceAddr;
> m_state.EraseLinkTuple (tuple);
> NS_ASSERT(a == tuple.neighborIfaceAddr);
> m_state.EraseNeighborTuple (GetMainAddress (tuple.neighborIfaceAddr));

Possible fixes are to change the order or to keep a copy of the address and give it to the EraseNeighborTuple function instead. The first fix is attached to this report.

Note that we had wrong simulation results without this fix, it does affect routing decisions since good neighbors keep disappearing from the neighbor set, especially with moving nodes.