<div>hmm regarding your log,..<br><br>in future you can remove the supsect partitioning messages,.. *g<br></div><div><br></div><div class="gmail_quote">On Wed, Nov 10, 2010 at 6:51 AM, Octav Chipara <span dir="ltr"><<a href="mailto:ochipara@gmail.com">ochipara@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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. </blockquote>
<div>so your log file combines routing log + olsrd stdout and stderr? (cause i see no olsrd messages ?)</div><div><br></div><div><div>so there where no olsrd routing error messages, during this log!?</div><div>or did i get this wrong?</div>
<div><br></div><div>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<br>(or both combined into one logfile)<br></div><div><br></div><div>
of an full olsrd run that starts on an empty routing table, an that definetely has routing errors!</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">There is nothing strange on syslog.</blockquote>
<div>ok, hmm but why did your olsrd doesn`t even`t have neighbours (from time to time,..)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>

<br><div>I think that what's going on is that the implementation of oslrd assumes that it always sets the routes successfully. </div></div></blockquote><div>Yes it does so ,.. (definitely on bsd/mac and windows, and partly on linux) </div>
<div><br></div><div>As failing to write a kernel route is no easy situation to handle, there are imho only 3 options,..<br><br><div>A: ignore it (and print an error)</div><div><br></div>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)</div>
<div><br></div><div>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)<br>
<br>C: olsrd could try to (mis-)use its root priviledges to e.g. delete conflicting routes, (or just overwrite them)<br>that unfortunately includes deleting routes it potentially did not create, which is nasty<br><div>(and could easily lead to an endless deletion-"war" between olsrd an another routing daemon or script,..)<br>
</div><br>imho every option is problematic,..</div><div><br></div><div>A used to be the only implemented "option" for olsrd on all plattforms, <br>only the linux specific routing code does since a while a bit of C,<br>
 <br>but above "options" are only targeted to resolve problems that where not caused by olsrd itself,..<br>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,..<br>
</div><div><br></div><div>imho i`m quite sure that it`s no bug in the (os-unspecific) olsrd core, <br>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,..<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div>Note that when I kill oslrd, it tries to remove all routes, however some of them remain in the routing table ...</div>
</div></blockquote><div><br>ACK, this is a bad sign *G</div><div><br></div><div>Markus</div></div>