[Olsr-dev] Idea for small OLSR improvement

[Markus Kittenberger]

> hmm maybe i will code something like this now *G

i did so, and it seems i already found a bug, .. (or maybe duplicate ips) in
our mesh,.. ((or coded rubbish))
(i found some ips that report low vtimes more often than possible,..

10909: vtime of tc entry from 78.41.113.136 was already down at 72%! (old:
362004 new: 496000)
12670: vtime of tc entry from 78.41.113.136 was already down at 72%! (old:
361952 new: 496000) but after 2 seconds its down at ~ 362 seconds again
15131: vtime of tc entry from 78.41.113.136 was already down at 72%! (old:
361752 new: 496000) and again,..
18098: vtime of tc entry from 78.41.113.136 was already down at 72%! (old:
362051 new: 496000)
20909: vtime of tc entry from 78.41.113.136 was already down at 72%! (old:
361550 new: 496000)

11365: vtime of tc entry from 78.41.112.149 was already down at 71%! (old:
356160 new: 496000) same here, and i have about 5 ips (of ~ 500) doing so in
total,..
13676: vtime of tc entry from 78.41.112.149 was already down at 71%! (old:
356763 new: 496000)
16641: vtime of tc entry from 78.41.112.149 was already down at 71%! (old:
356610 new: 496000)
21512: vtime of tc entry from 78.41.112.149 was already down at 72%! (old:
357166 new: 496000)

whatever attached patch will write to syslog/stdout whenever a tc comes in
that pushes the vtime too much,..

Markus



> > As I started this thread it is obvious that I do not see any problems
>  > with routes being left in place even if they do not work anymore. :-)
>
> but i do, and imho some/many other people do aswell,...
>
> but if u don`t care, just set a vtime of virtually infinite for everything
> on every node, but please do not whine if u don like the results,.. *G
>
> btw: setting vtime to infinite is not the same as having the last route
> forever.
>
> Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100425/06eb93ac/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tc_vtime_warn.patch
Type: application/octet-stream
Size: 2583 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100425/06eb93ac/attachment.obj>