[Olsr-dev] Bug in timing out stale TC entries

Erik Tromp (spam-protected)
Sun Feb 24 17:03:17 CET 2008

> removing edge entries from the lsdb is not mandatory as long 
> as we "do the right thing", which is to ignore this link 
> during SPF computation.


> it would be interesting to see if the offending edges (or the inverse
> edges) are marked down using the OLSR_TC_EDGE_DOWN flag.
> (pls add some instrumentation code to verify).


By the way, according to the next constant I would expect the edges
to dissapear within 15 seconds:
 * Garbage collection time for downed edges
#define OLSR_TC_EDGE_GC_TIME (15*1000) /* milliseconds */

> the reason we are just marking the edge as down and not 
> immediately removing it is b/c of the TC fragmentation bug 
> where a TC message spans across 2 packets. (if we would 
> eliminate all TC edges immediately then you get a whole lot 
> of malloc() churn.
> b/c a couple of ms later the next packet is being processed 
> and then the tc_edge is reinserted again.

Sounds sensible.

If an edge is marked 'down' in some way or another, it would
be nice to see that in the debug info.

I guess I'll have to make an update in the bmf code now...


More information about the Olsr-dev mailing list