[Olsr-users] Maybe problem when disabling all olsr network interfaces

[Joerg Pommnitz]

Hannes,
I gave this latest patch a try as well. It doesn't cause regressions,
but I'm not sure it causes any improvements either. Sometimes the
routes really vanish immediately, but sometimes they linger around
for some time (I have seen 13 sec, using the default LQ olsrd.conf).

So I'm not sure that this is really different from what I saw
previously.

BTW, doing this testing I observed something else that smells like
a misfeature (good software doesn't have bugs :-)):
I have two nodes in my test setup:
172.16.0.5 is the one I'm using to enable and disable the interface,
172.16.0.6 is there to provide some routes itself and two HNA,

If 172.16.0.5 vanishes, than 172.16.0.6 keeps an entry in the TC table

Src          Dst        LQ           ETX
172.16.0.6   172.16.0.5 0.600/0.749  2.225

Everything else is empty. This TC entry will not change until the
other node (172.16.0.5) comes back.

-- 
Regards
       Joerg


--- Hannes Gredler <(spam-protected)> schrieb am Mi, 2.7.2008:

> Von: Hannes Gredler <(spam-protected)>
> Betreff: Re: [Olsr-users] Maybe problem when disabling all olsr network interfaces
> An: (spam-protected)
> CC: (spam-protected), "olsr-dev" <(spam-protected)>
> Datum: Mittwoch, 2. Juli 2008, 15:00
> Joerg Pommnitz wrote:
> > Hannes,
> > with this patch things look much better. The routes
> get deleted, but 
> > sometimes it takes some time until the routing
> calculation gets called.
> > This is something I can live with. So, if this where
> the Linux kernel,
> > I would add a "Tested-by:
> (spam-protected)". 
> 
> thanks, appreciate the testing time.
> 
> this is due to the periodic SPF update, which gets things
> right after some time.
> the attached patch should force a SPF calculation on the
> next scheduler run.
> 
> > BTW: olsrd doesn't crash anymore when disabling
> the interface. This 
> > used to happen because the interface structures where
> freed in 
> > 
> > int
> > chk_if_changed(struct olsr_if *iface)
> 
> we need to convert this to a clean refcount model.



      __________________________________________________________
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com