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?

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
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).
The relevant interfaces are:
----  snip  ----
{909}ip a
[...]
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:40:63:d8:1c:2c brd ff:ff:ff:ff:ff:ff
    inet 193.238.156.51/32 scope global eth0
    inet6 fe80::240:63ff:fed8:1c2c/64 scope link 
       valid_lft forever preferred_lft forever
[...]
7: tap0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:ff:95:b9:5a:18 brd ff:ff:ff:ff:ff:ff
    inet 193.238.156.57/32 brd 193.238.156.57 scope global tap0
    inet6 fe80::2ff:95ff:feb9:5a18/64 scope link 
       valid_lft forever preferred_lft forever
[...]
----  snip  ----

>  down, replies you get,
> maybe we should also consider to let the kernel (via rtnetlink
> messages) inform olsrd about external 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.
And poll-and-compare the routing table is IMHO not a really sane
approach.

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



