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

[Aaron Kaplan]

please also make sure that the route cleanup patch is included.

Because currently we run olsrd on subway (which incidentally also  
runs quagga and has full feed 300k routing entries...). So if olsrd  
leaves some stray routes there it is pretty awkward.
Hehe, recently I very confidently announces (luckily only to two  
people verbally) that CVS -HEAD is actually rather stable because we  
test the patches before. So...

please... could we check this bevor we cvs commit ?
We can simulate on texas before if we ask wolfgang nicely if he can  
help us to get the full BGP feed (at least in snooping/listening mode!)

thanks
a.


On Jul 2, 2007, at 6:51 PM, Hannes Gredler wrote:

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

---
there's no place like 127.0.0.1
until we found ::1 -- which is even bigger