[Olsr-users] Problems with the quagga plugin

[Damien Miliche]

Hi,

I kept on with my investigations:

>  - a specific "show ip route olsr" makes the zebra daemon crash (connection
>    closed for the telnet, and the daemon is stopped);

The crash also occurs for other protocols/codes (ospf, connected, ...);
it seems it happens only when zebra contains routes for the
corresponding protocol/code. However, this is then not related to the
quagga plugin. So forget about this problem.


Anyway:

>  - the olsr routes are marked as "inactive" in quagga;
>  - these routes are not redistributed to the kernel;
>  - these routes are not redistributed to other OSPF nodes.

It seems that these problems are linked and have a common cause.
As I realized, while reading the post on
http://www.gossamer-threads.com/lists/quagga/dev/17522, the olsr routes
that are marked as inactive actually miss a valid route for the "via
field" (gateway/nexthop): "When the nexthop is not reachable (from zebra
point of view), the route stays inactive".

In my case, the missing routes should be directly reachable olsr nodes,
that is to say that in the kernel routing table, they would appear as
host entries with a /32-mask, without the G-flag and with a gateway
(normally not used) of 0.0.0.0.
However, the httpinfo or txtinfo plugins of olrd show these entries
with a gateway IP corresponding to the /32-IP of the node. Though, while
searching a bit, I found out that there would be a "bug" in Quagga,
which would not accept the routes where the destination is the same than
the gateway.
This bug is obvioulsy known, as we can read somewhere in the source code
of the quagga plugin (quagga.c):
/* Quagga BUG workaround: don't add routes with destination = gateway
   see http://lists.olsr.org/pipermail/olsr-users/2006-June/001726.html
*/
The workaround is indeed to return from the function before adding the
corresponding route.

A question, then: as the problem comes from the fact that destination =
gateway, and that in the case of a host-entry the gateway should not be
used, why does olsrd use the destination IP as gateway, and not 0.0.0.0
as the kernel does for the /32 entries?
I don't know if this gateway field is used somewhere else by olsrd, but
it could solve the problem and replace the workaround.


Given all that, I was wondering: has anyone ever had a successful
experience with this quagga plugin?
because as olsrd always creates /32 entries, the problem should have
appear everytime, at any try of the plugin.
Have I missed/misunderstood something?


Thanks in advance for your reactions and for your help.

Best regards,

-- 
Damien Miliche