[Olsr-dev] segfault in -r3 reproduced

[Markus Kittenberger]

On Tue, Dec 9, 2008 at 1:30 AM, Bernd Petrovitsch <(spam-protected)> wrote:

> Trimmed To:, Cc:
>
> On Mon, 2008-12-08 at 14:19 +0100, Markus Kittenberger wrote:
> [...]
> > i think the key to fix is lies in handling rtnetlink errors properly,
> >  and reacting apropriate on destination unreachable, interface is
>
> Hmm, assume that an add-route because of destination unreachable failed:
> What should one do?


insert the route to the gateway immediately (-;

maybe check whether the interface is down,..

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,..

or find out what happened to the route to the gateway,..why it wasn`t
inserted before, or why it`s changed, removed,..

>
>
> And currently we try to insert *lots* of route and it doesn't work (and
> I'm logging also the successful operations):
> http://bernd.petrovitsch.priv.at/olsr-ng/olsrd-6.log

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,..
does similar happens also while oslr is running, or just on startup?
i asume you digged in the RIB already?

> <http://bernd.petrovitsch.priv.at/olsr-ng/olsrd-6.log>
> But actually I don't know where to dig further why we want to add a
> route via 193.238.156.204 (in line 10) long before adding a route to it
> (IMHO at line 1046).

for sure we should fix/find these problems,
maybe above shoudl be done before considering handling external generated
problems,
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,..


> Portability alert: That may work for Linux but all the others use
> ioctl()s for route handling and AFAIK there is no channel back similar
> to Linux-netlink.

the kernel_routes.c is in /linux

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,..
and if we just fix the ordering of route inserts any os will benefit

>
> And poll-and-compare the routing table is IMHO not a really sane

i never talked about polling it,..

>
> approach.

other routing daemons suites, do listen to rtnetlink multicast messages,
informing them about updated/deleted routes, ...

in fact rtnetlink was mostly made for user space routing daemons,..
and this doesn`mean polling, as the kernel sends the messages (anyways) when
it happens, olsrd just has to listen,..
same can/should be done with interface state and ip adresses
generally i prefer using events instead of polling,..
of course listening to rtnetlink may require having threads? )-;
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20081209/f2a3d915/attachment.html>