[Ns-bugs] [Bug 780] OLSR doesn't converge

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=780


Gustavo J. A. M. Carneiro <gjcarneiro at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gjcarneiro at gmail.com




--- Comment #3 from Gustavo J. A. M. Carneiro <gjcarneiro at gmail.com>  2009-12-21 06:28:02 EDT ---
Tom's patch does not take into account that 2-hop neighbor tuples may exist in
an "expired" state.  Also modified to use the existing operator << for printing
the tuples, so that all fields are printed.  The result at t=150 is:

150s -1 [node 0] OlsrRoutingProtocol:Dump(): Dumping for node with main address
10.1.1.1
150s -1 [node 0] OlsrRoutingProtocol:Dump():  Neighbor set
150s -1 [node 0] OlsrRoutingProtocol:Dump():  
NeighborTuple(neighborMainAddr=10.1.1.2, status=NOT_SYM, willingness=3)
150s -1 [node 0] OlsrRoutingProtocol:Dump():  
NeighborTuple(neighborMainAddr=10.1.1.3, status=SYM, willingness=3)
150s -1 [node 0] OlsrRoutingProtocol:Dump():  Two-hop neighbor set
150s -1 [node 0] OlsrRoutingProtocol:Dump():  Routing table
150s -1 [node 0] OlsrRoutingProtocol:Dump():   dest=10.1.1.3 --> next=10.1.1.3
via interface 1
150s -1 [node 0] OlsrRoutingProtocol:Dump(): 

So, basically node 0 has _no_ 2-hop neighbors whatsoever.  Moreover, there's a
symmetric link to node 10.1.1.3, therefore it is added to the routing table,
but the link to node 10.1.1.2 is not symmetric, i.e. we can hear them but they
can't hear us.  The problem is not in the routing table computation, it is
elsewhere.  Link sensing is failing...

-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.