[Olsr-dev] [olsr-dev] Quagga plugin fixes

[Sven-Ola Tuecke]

Hannes,

compiled a debug version (with #define DEBUG in src/process_routes.c) with 
and without spf applied and run it on a real node. I'll attach the output to 
this posting. As you can see, the calculated "hops" value is different. We 
have software, which depends on the hops value inserted into the routing 
table as metric value (e.g. fftrace or OLSR-VIZ).

You may also notice the error msgs regarding 104.129.44.7/255.0.0.0, which 
obviously is a misconfigured node currently spamming our logs with that 
wrong HNA4 config.

Ah - here's a traceroute to an arbitrary node to verify the hops count 
determinded by the spf-less code:

(spam-protected):~# traceroute -w 2 -n 104.193.0.42
traceroute to 104.193.0.42 (104.193.0.42), 30 hops max, 40 byte packets
 1  104.65.0.37  5.917 ms  8.16 ms  2.886 ms
 2  104.0.0.5  3.625 ms  3.694 ms  3.368 ms
 3  104.0.0.9  6.106 ms  12.025 ms  11.293 ms
 4  104.0.4.65  20.216 ms  8.162 ms  24.186 ms
 5  104.0.0.51  10.128 ms  22.253 ms  22.241 ms
 6  104.135.0.1  11.359 ms  10.417 ms  45.901 ms
 7  104.192.192.225  21.499 ms  13.117 ms  14.088 ms
 8  104.192.192.81  16.874 ms  26.452 ms  21.689 ms
 9  104.193.0.42  50.032 ms  20.169 ms *

HTH, Sven-Ola

"Hannes Gredler" <(spam-protected)> schrieb im Newsbeitrag 
news:(spam-protected)
>
>
> Bernd Petrovitsch wrote:
>> On Mon, 2007-07-02 at 10:25 +0200, Sven-Ola Tuecke wrote:
>> [...]
>>
>>>the routing-cleanup-Patch changes the old function-table-hookup method of
>>>quagga to a more simple approach (_one_ function pointer suitable for
>>>chaining). This may need mergeing.
>>>
>>>Because of several fixes I change the status of the routing-cleanup and
>>>policy-routing patches from "experimental" to "recommended-for-testing". 
>>>My
>>>current patchset for olsr-0.5.0 is located here (100* - 170*):
>>>
>>>http://download.olsrexperiment.de/sven-ola/nylon/packages/olsrd/files/
>>
>>
>> 120-bmf-1.5.patch and 130-httpinfo-bufsizefix.patch are in (and
>> 100-cvs.patch trivially too).
>> 160-nameservice-cleanup.patch changes only whitespace (or not)?
>>
>> Perhaps Immo can comment on 140-routing-cleanup.patch and put it in his
>> SVN repo.
>> Or someone in Vienna looking after the border router can merge the most
>> recent version from the SVN repo and the above patch and use it in RL.
>>
>> 150-policy-routing.patch includes two functions from busybox - which is
>> GPL. So I'm quite reluctant to merge it into the CVS. I'm more thinking
>> about converting (at least for Linux) the ioctl() to netlink sockets
>> even if it doesn't allow using a different routing table than the
>> default one. And IIRC it didn't work for me the last time I tested it.
>> Have to try again.
>>
>> 170-olsrd-nameservice-latlon.patch looks simple and nice.
>>
>>
>>>One note: 110-spf-refactoring is excluded currently due to wrong metric
>>>calculation (which is a minor bug - we maybe simply tolerate this, CPU
>>>saving is approved and fine).
>>
>>
>> Hmm, Hannes, can we fix that minor bug?
>
> i am still not 100% sure what the problem is.
> i got an email from sven-ola and i interpret it either as
>
> 1. routes with a hopcount of > 3 should not be installed in the kernel
> 2. routes with a hopcount > 3 should be installed with a metric of 3 in 
> the kernel
> 3. something completely else
>
> sven-ola - can pls you clarify ?
>
> /hannes
>
> -- 
> Olsr-dev mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-dev 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: olsrd-debug-withspf.txt.gz
Type: application/octet-stream
Size: 6504 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20070703/be2fb6b9/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: olsrd-debug-nospf.txt.gz
Type: application/octet-stream
Size: 4973 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20070703/be2fb6b9/attachment-0001.obj>