http://permalink.gmane.org/gmane.network.quagga.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.network.quagga.devel/9388 <pre> Hm. It seems to me that Jorge's patch is more complete and fixes the same issue in a more consistent way in the proper place. Comments? If I don't hear anything I'll pick up Jorge's patch and consider Stephen's as superseded. -David </pre> David Lamparter 2012-05-22T23:16:29 http://permalink.gmane.org/gmane.network.quagga.devel/9387 <pre> Actually, that ends up being the idea of "bgpd: don't advertise routes with peer address as nexthop"; I'll go respin that using peer-&gt;nexthop as I've commented already. After reading RFC4271 5.1.3 I'm confident that's actually the correct thing to do. -David </pre> David Lamparter 2012-05-22T22:46:22 http://permalink.gmane.org/gmane.network.quagga.devel/9386 <pre>[...] Merged 22 of 25, Thanks! Not merged werre: -David </pre> David Lamparter 2012-05-22T22:34:00 http://permalink.gmane.org/gmane.network.quagga.devel/9385 <pre> I'll pick it up after rechecking the BGP remote ID thing. I think the check is actually 100% wrong and removing it was the correct fix in the first place, but I'll recheck. Dropping Jorge's 25/25 for now; remainder inbound on master. -David </pre> David Lamparter 2012-05-22T22:29:23 http://permalink.gmane.org/gmane.network.quagga.devel/9384 <pre>El 22/05/2012 20:52, David Lamparter escribió: Sure! That's why the series was a RFC one :-) </pre> Jorge Boncompte [DTI2] 2012-05-22T19:01:52 http://permalink.gmane.org/gmane.network.quagga.devel/9383 <pre> Changing this to 64 since the maximum function name length specified by ISO C99 is 63. Also makes the value less arbitrary ;) -David </pre> David Lamparter 2012-05-22T18:52:25 http://permalink.gmane.org/gmane.network.quagga.devel/9382 <pre> Since with this, Receive_UPDATE_message is not triggered at all anymore, does anyone have a good reason for not removing it altogether? -David </pre> David Lamparter 2012-05-22T18:35:14 http://permalink.gmane.org/gmane.network.quagga.devel/9381 <pre>On Tue, 22 May 2012 18:24:54 +0200 Torsten Luettgert &lt;st-quagga&lt; at &gt;luettgert.de&gt; wrote: Be careful, if you remove this quagga may get out of sync with a full route table and a link flap. Did you test that? </pre> Stephen Hemminger 2012-05-22T16:51:17 http://permalink.gmane.org/gmane.network.quagga.devel/9380 <pre> Torsten Luettgert &lt;st-quagga&lt; at &gt;luettgert.de&gt; writes: Do you understand how the netlink socket was supposed to work? Can you explain why this is a quagga bug vs. a Linux bug? (I'm not saying I think it *is* a Linux bug, just that I don't see an explanation of how things ought to be and why, and your putting fix in quotes make me suspicious that the change is a workaround rather than a fix.) I would think all notifications from the kernel that state is changing should be parsed. But I have also heard that netlink is unreliable, and I had the (very vague) impression that messages to the kernel were acted on to work around that. Really what I'm trying to say is that it would be good if someone really understood what was going on here, so we could be sure that any changes were actually right. </pre> Greg Troxel 2012-05-22T16:44:20 http://permalink.gmane.org/gmane.network.quagga.devel/9379 <pre>Hi list, under linux &gt; 2.6.18, quagga (all versions) would not remove the "directly connected" state routes when IP addresses were removed from interfaces in vtysh. My "fix" was to remove the block checking if the message has the same pid as the command interface. I hope this doesn't make zebra parse lots of irrelevant messages. The patch is attached to bug #721, where this is also discussed in greater detail. I'll also attach it to this mail. Best regards, Torsten </pre> Torsten Luettgert 2012-05-22T16:24:54 http://permalink.gmane.org/gmane.network.quagga.devel/9378 <pre>Hi! Due to the serious problems[1] with ospfd in Quagga &gt;0.99.17 we've decided at Westermo to downgrade to 0.99.17 for our upcoming WeOS[2] 4.9.0 release. Contrary to earlier releases of WeOS I've decided to personally steal some corporate time to communicating our efforts and publicizing our patches at GitHub[3]. https://github.com/troglobit/quagga/tree/security/0.99.17 https://github.com/troglobit/quagga/tree/westermo/0.99.17 So far I've setup the repository, created a security/0.99.17 branch, with patches from the official security/0.99.20 tree, and added the Westermo patches (including Stephen Hemminger's Zebra route manager patch! :) to a westermo/0.99.17 tree. Before our own WeOS release I hope to add CVE fixes from Debian[4], at the very least CVE-2011-3325 and CVE-2011-3326, i.e., DSA-2316-1 see[5] for more details. Maybe someone else is interested in this effort. Iirc Joakim Tjernlund also use 0.99.17 as a baseline for Transmode ... Regards /Joachim [1] - http://lists.quagga.net/</pre> Joachim Nilsson 2012-05-21T18:16:31 http://permalink.gmane.org/gmane.network.quagga.devel/9377 <pre>OoO En ce début d'après-midi ensoleillé du lundi 21 mai 2012, vers 15:27, David Lamparter &lt;equinox&lt; at &gt;opensourcerouting.org&gt; disait : I will update the OSPFv3 part then. Then, I may propose to use AgentX instead of SMUX. This should be easy enough if I am allowed to put some code around select() in thread.c. Most of the code outside smux.c will be left untouched. </pre> Vincent Bernat 2012-05-21T16:07:13 http://permalink.gmane.org/gmane.network.quagga.devel/9376 <pre> removed 14 &amp; 19, looking through it right now, expecting to push onto master in a few hours. [branch on git: volatile/jp_bgp_120507] Btw, feel free to create a public git tree &amp; send git pull requests :) -David </pre> David Lamparter 2012-05-21T14:30:15 http://permalink.gmane.org/gmane.network.quagga.devel/9375 <pre>[...] It might be more useful to put p-&gt;nexthop.v6_global (or _local? I always get confused by these...) here. That way it'll also work when exchanging IPv6 routes over an IPv4 MBGP session. -David </pre> David Lamparter 2012-05-21T13:54:21 http://permalink.gmane.org/gmane.network.quagga.devel/9374 <pre> Probably not, the whole SNMP code is outdated; it still uses SMUX instead of AgentX and nothing much has really been updated or maintained on that end. -David P.S.: lldpd rocks. </pre> David Lamparter 2012-05-21T13:27:29 http://permalink.gmane.org/gmane.network.quagga.devel/9373 <pre> Converted into a full delete instead of #if 0 &amp; applied, thanks. </pre> David Lamparter 2012-05-21T13:36:54 http://permalink.gmane.org/gmane.network.quagga.devel/9371 <pre>Hi! Implementation of OSPFv3-MIB in Quagga is incomplete and outdated: it uses an experimental MIB instead of the one from RFC 5643 and only ospfv3AreaLsdbTable is implemented. Is someone working on a more current implementation? </pre> Vincent Bernat 2012-05-17T09:03:30 http://permalink.gmane.org/gmane.network.quagga.devel/9370 <pre> I too have noticed this issue. Looks like there is some problem in the ospf6_intra_brouter_calculation() logic. It removes the border-router's and adds them back and in this process deletes the border router. After which it deletes the as-external route as there is no route to the ASBR entry. May be this logic has to be re-written similar to OSPFv2 where copy the existsing brouters from brouter_table in ospf6 structure to a temperory table and do all the checks without any route addition deletion hooks. Once done, check for any route changes (new additions or deletions or modifications). Add/remove/modify only those routes in the ospf6-&gt;brouter_table. I have seen a similar issue when the DUT is an ABR and I try to redistribute a static or a connected route. An INTER ROUTER LSA goes out which is immediately followed by another INTER ROUTER LSA but with AGE = 3600. So due to this, the AS External LSA is not accepted on the receiving end. Should THE DUT(ABR) be sending the inter-router lsa</pre> narender 2012-05-16T14:46:53 http://permalink.gmane.org/gmane.network.quagga.devel/9369 <pre>Hi, I was wondering if in the function - ospf6_route_remove_all() Are we not accessing freed memory (route) while trying to get the route next using ospf6_route_next(). Similar is the case in ospf6_intra_brouter_calculation() function. We are freeing the memory in ospf6_route_remove()--&gt; ospf6_route_unlock() and on return to get the next route entry we use the same memory freed memory again. Is it not an issue. Regards Narender </pre> narender 2012-05-16T14:32:55 http://permalink.gmane.org/gmane.network.quagga.devel/9368 <pre> On Tue, May 15, 2012 at 04:39:38PM +0200, David Lamparter wrote: And I forgot the link: http://confluence.isc.org/display/osr/Compliance+Test+Summary </pre> David Lamparter 2012-05-15T14:48:06 http://permalink.gmane.org/gmane.network.quagga.devel/9367 <pre> The OSR has several hardware test boxes that ship with various test suites for routing protocols, but, alas, being hardware boxes, they can't be made available through tests/. The next Quagga release (0.99.22) will be run through the entirety of it and the reports made public. A close git cousin of 0.99.21 has already been run through, but the test setup wasn't final yet (versions of the test boxes changed, test scripts were still worked on, etc.) so the test reports are of less useful beta quality with glitches &amp; co. If you need something particular tested, the idea is to occasionally pull feature branches into testing as they fit. On the other hand, yes, extending tests/ is very much needed. Patches welcome ;). I believe that some parties are already getting their heads on this, but if I remember correctly that was all still in the "hmm we should do something here" state without much realisation yet. -David </pre> David Lamparter 2012-05-15T14:39:38 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.network.quagga.devel