On Tue, 2008-12-09 at 03:13 +0100, Markus Kittenberger wrote:
> On Tue, Dec 9, 2008 at 1:30 AM, Bernd Petrovitsch <bernd@firmix.at>
> wrote:
[...]
>         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,..

Good - we think then more or less in the same direction.
But that is where IMHO the fun begins since we must analyze and decide
what to do in which situation, e.g.
- root `ip route del`s a route (for whatever reason).
  Should olsrd simply add it again?
The simple approach IMHO is (and we actually doing that IMHO now) is:
olsrd is the master of "it's" routing table - be it the default one or
another.
But then, administrative actions (like "never route traffic to/via $IP1
via $IP2") must obviously go through olsrd (or one adds iptables rules
to make olsrd "think" that way. But that is IMHO a very hacky workaround
as one must know a lot of things - e.g. the behavior of olsrd - to get
it done right).

The other approach is: The admin (or cron or ...) can also add/delete
routes. And we learn these and take these implicitly as "administrative
action" and honor it.
Apart from the implementation for the running daemon, it adds the
question of what to do at startup?
That boils IMHO down to "we should better remember that actions" in some
persistent file.

But I'm not adminning nearly enough real and central nodes to know what
administrative behavior/features the people in the field really
need/want/..... to specify that.
And it makes no sense to implement a solution and then search for a
problem to solve with it - the world has for too much of them.

>         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

ACK. That was even strange to me;-)

>  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?

Good question. A full log (not from the same run but it is similar) is
on http://bernd.petrovitsch.priv.at/olsr-ng/olsrd-7.log.bz2
Feel free (and everyone else) to suggest where (file, line, ...) and
what should be logged additionally. BTW the above is generated by help
of http://bernd.petrovitsch.priv.at/olsr-ng/debug-kernel-routes.

> i asume you digged in the RIB already?

Nope. That would be the logical next step for me to learn where and why
(and why not;-) the changes are generated.

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

Apart from the kernel itself, only olsrd changes that routingtable
(AFAIK - and I'm the only root there</disclaimer>;-).
E.g. I didn't check if it makes a difference that I run /32 IPv4
addresses which implies that the kernel doesn't create a route to the
network.

>         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 

Yup. But others have a kernel_routes.c file too.

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

No problem with me - I'm just reminding all others that Linux is not the
only OS.
To sell that feature I would see/declare it as the first step in that
direction and other OSs will follow;-)

> and if we just fix the ordering of route inserts any os will benefit

ACK.

>         And poll-and-compare the routing table is IMHO not a really
>         sane
> i never talked about polling it,..

ACK. I was was just exploring alternative ways to implement that. And
the IMHO every OS has a "route" command (whatever you call it). But for
that, a snapshot is IMHO enough.

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

Yup.

> 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? )-;

No way - you really don't want to make a locking design, get people to
agree on it, deploy the locking throughout the daemon, fix all deadlocks
*and* than use threads in the core olsrd. And no, there is not other
sane or even remotely working way to add locking - especially not
salami-tactic like "we do it stepwise", "we add it as we see problems",
etc.
The 2 or 3 Seg-Faults from the last weeks are far easier to find and fix
than race conditions with locking.

Just add that (non-blocking) socket to the other sockets and read into a
local buffer if there is something to read (and act on the buffer if
it's filled enough. Given that netlink has no real hardware underneath,
I expect that only whole messages are sent anyways. But I won't count on
that as it may change tomorrow).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




