[Olsr-dev] Stuck TC-Edge entries in orphaned olsrd

[Hannes Gredler]

Joerg Pommnitz wrote:
> Hannes,
> looking through the code I found something that might explain what I'm
> seeing regarding the stuck TC-Edge entry in an orphaned olsrd:
> 
> 1) The TC entry in question seems to be tcmyself from olsr_init_tc(void):
> tc_myself = olsr_add_tc_entry(&olsr_cnf->main_addr);
> 
> 2) My gut feeling is, that the tc-edge entry comes from 
>    void olsr_calculate_routing_table (void):
> 
>       if (!tc_edge) {
>         tc_edge = olsr_add_tc_edge_entry(tc_myself, &neigh->neighbor_main_addr,
>                                          0);
>       } else {
> 
> Now I'm really not familiar enough with the olsrd code base, but this
> is where something might go wrong. What kills this entry when the neighbor
> is gone?

the reason why we do need it at all is because the SPF code relies on a tc_entry
as representation of a node in the graph. each node needs to have a
representation, including ourselves.

ok, so the interesting question to ask is *why* should it go away ? -

not removing this does not cause any harm (as an edgeless node (which it becomes once
the last neighbor goes away)) is not explored during SPF calculation,
so the SPF calculation will terminate immediately and causing not any
new routes getting installed and old ones flushed from the RIB.

keeping it up forever (w/o any validity timer running) may avoid some ugly race
conditions and churn.

if you feel this is not right, pls submit a patch where the tc_entry for ourselves
is getting properly refreshed (read tunning timer) on every generation of a
fresh tc_entry.

/hannes