<br><br><div class="gmail_quote">On Tue, Dec 9, 2008 at 1:30 AM, Bernd Petrovitsch <span dir="ltr"><<a href="mailto:bernd@firmix.at">bernd@firmix.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Trimmed To:, Cc:<br>
<br>
On Mon, 2008-12-08 at 14:19 +0100, Markus Kittenberger wrote:<br>
[...]<br>
<div class="Ih2E3d">> i think the key to fix is lies in handling rtnetlink errors properly,<br>
>  and reacting apropriate on destination unreachable, interface is<br>
<br>
</div>Hmm, assume that an add-route because of destination unreachable failed:<br>
What should one do?</blockquote><div> </div><div>insert the route to the gateway immediately (-;<br><br></div><div>maybe check whether the interface is down,..<br><br>or remove the problematic link from topo, or at least change its cost, in fact it should be made sure that if adding a route fails permanently/regulary, this link (ot the link to the gateway) can not be announced, like everything is fine with it,..<br>
<br></div><div>or find out what happened to the route to the gateway,..why it wasn`t inserted before, or why it`s changed, removed,..</div><div></div><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
And currently we try to insert *lots* of route and it doesn't work (and<br>
I'm logging also the successful operations):<br>
<a href="http://bernd.petrovitsch.priv.at/olsr-ng/olsrd-6.log" target="_blank">http://bernd.petrovitsch.priv.at/olsr-ng/olsrd-6.log</a></blockquote><div>it`s really strange why 5 times/seconds thers seem to be a route to this host, before we even kno its gateway, maybe there has to be a minimum of messages received from an host before it`s considered valid, and this one is more communcative than others,..</div>
<div></div><div>does similar happens also while oslr is running, or just on startup?</div><div></div><div>i asume you digged in the RIB already?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<a href="http://bernd.petrovitsch.priv.at/olsr-ng/olsrd-6.log" target="_blank"></a><br>
But actually I don't know where to dig further why we want to add a<br>
route via <a href="http://193.238.156.204" target="_blank">193.238.156.204</a> (in line 10) long before adding a route to it<br>
(IMHO at line 1046).</blockquote><div>for sure we should fix/find these problems, </div><div></div><div>maybe above shoudl be done before considering handling external generated problems, <br>but maybe its makes finding them easier (as you can clealry distinguish between internally and externally caused problems) when olsrd (or an external rtnetlink logging tool) monitors all route updates,..</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Portability alert: That may work for Linux but all the others use<br>
ioctl()s for route handling and AFAIK there is no channel back similar<br>
to Linux-netlink.</blockquote><div>the kernel_routes.c is in /linux <br><br></div><div>so i see no problem if olsrd under linux handles its kernel routing operations reliable, while on other oses it`s a bit less reliable,..</div>
<div></div><div>and if we just fix the ordering of route inserts any os will benefit</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
And poll-and-compare the routing table is IMHO not a really sane</blockquote><div>i never talked about polling it,..</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
approach.</blockquote><div>other routing daemons suites, do listen to rtnetlink multicast messages, informing them about updated/deleted routes, ...<br><br></div><div>in fact rtnetlink was mostly made for user space routing daemons,..</div>
<div></div><div>and this doesn`mean polling, as the kernel sends the messages (anyways) when it happens, olsrd just has to listen,..</div><div></div><div><div>same can/should be done with interface state and ip adresses</div>
<div>generally i prefer using events instead of polling,..</div><div></div><div>of course listening to rtnetlink may require having threads? )-;</div></div><div></div><div>Markus</div></div>