[Olsr-dev] Poor routing performance

Markus Kittenberger (spam-protected)
Wed Nov 10 11:07:16 CET 2010

hmm regarding your log,..

in future you can remove the supsect partitioning messages,.. *g

On Wed, Nov 10, 2010 at 6:51 AM, Octav Chipara <(spam-protected)> wrote:

> Tonight I was actually able to get some routes. All 3 nodes are in my
> office. I am still getting strange multi-hop routes in this settings. See
> attached log for what's going on. There still is the error that it fails to
> set routes. The log captures stdout and stderror.

so your log file combines routing log + olsrd stdout and stderr? (cause i
see no olsrd messages ?)

so there where no olsrd routing error messages, during this log!?
or did i get this wrong?

to have any chance to find something useful, i`d need a log of all olsrd
stderr messages (with timestamps) and the route monitoring log
(or both combined into one logfile)

of an full olsrd run that starts on an empty routing table, an that
definetely has routing errors!

> There is nothing strange on syslog.

ok, hmm but why did your olsrd doesn`t even`t have neighbours (from time to

> I think that what's going on is that the implementation of oslrd assumes
> that it always sets the routes successfully.
Yes it does so ,.. (definitely on bsd/mac and windows, and partly on linux)

As failing to write a kernel route is no easy situation to handle, there are
imho only 3 options,..

A: ignore it (and print an error)

B: shut down corresponding olsrd links on such routing errors, as imho it`s
an inacceptable siutation, to keep running and announcing itself an an olsrd
router, while not being (fully) able to route,.. (so at least the olsrd
instance should stop other mesh nodes from routing traffic over his own
malfunctionig node)

this does not solve the local problems, but it raises awareness (of the user
(and neighbours) that there is a problem), and tries to limit the global
impacts of local problems (but might just makes things (much) worse aswell
-> e.g. destroy a "mostly" working mesh completely)

C: olsrd could try to (mis-)use its root priviledges to e.g. delete
conflicting routes, (or just overwrite them)
that unfortunately includes deleting routes it potentially did not create,
which is nasty
(and could easily lead to an endless deletion-"war" between olsrd an another
routing daemon or script,..)

imho every option is problematic,..

A used to be the only implemented "option" for olsrd on all plattforms,
only the linux specific routing code does since a while a bit of C,

but above "options" are only targeted to resolve problems that where not
caused by olsrd itself,..
of course it should not be buggy, and e.g. fail to write a route, because it
forgot to delete a route to the same target,.. or cause it did even more
stupid things,..

imho i`m quite sure that it`s no bug in the (os-unspecific) olsrd core,
i guess it`s either olsrd's bsd routing code (which is more or less
unmaintained since years,..) and/or your "system" that has some new
"feature" that now breaks things,..

Note that when I kill oslrd, it tries to remove all routes, however some of
> them remain in the routing table ...

ACK, this is a bad sign *G

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20101110/cc172fda/attachment.html>

More information about the Olsr-dev mailing list