[quagga-dev 16545] Re: Security list changes (Transparency?)

[Martin Winter]

On 13 Jan 2017, at 16:16, Paul Jakma wrote:


On Fri, 13 Jan 2017, Paul Jakma wrote:

I've noticed elsewhere that people seem to think NetDEF == Quagga. 
What have you been telling people at conferences?


I'd been waiting for you to announce your fork (and note, you can 
_not_ spam this list with marketing material on it; inc. 'heads up' 
stuff), but that reminds me:


You need to fix your website(s) and other material where reasonable to 
update references to the Quagga project so it is very clear Quagga is 
a different thing to NetDEF, and acknowledge the trademark[1] legibly. 
Where it's HTML, make "Quagga" go to https://www.quagga.net/ .


1. I registered that soon after I heard the first whispers of your
   fork, after the David issue.


No point to discuss this on the list. If there is a confusion at some 
page, then please
let me know in a private email the specifics (i.e. where and maybe a 
suggestion on how you

would like it changed) and I do my best to get it fixed.

I tried to make it clear in presentations and on the website that we are 
just a contributor
like everyone else. Maybe I screwed up somewhere and I apologize for 
this. Just asking for

a chance on getting it fixed.

- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16537] Re: Security list changes (Transparency?)

[Martin Winter]

On 11 Jan 2017, at 22:34, Michael H Lambert wrote:


On 11 Jan 2017, at 10:05, Nick Hilliard  wrote:

Usually forks happen after a breakdown of confidence and/or trust in 
the
original project.  Without prejudice to whatever changes may have 
been
made to the secur...@quagga.net email address, it looks like there 
has

been a serious breakdown of communications.

It would be helpful if there were some public discussion about what's
happened, and why.  There are a lot of people who depend on the 
quagga

code base, and trust in community projects depends on transparency.


Forks can also happen when developers decide they want to "monetize" 
the code.  Yes, it's still open source, but if you want updates in 
timely fashion you'll need to subscribe to a maintenance plan.  I 
agree that the community needs to be kept in the loop.


The problem was really getting the name picked. It was way more
painful than expected. And a lot of the work was done while it was
still called Quagga - and that would have caused a really bad confusion
(and most likely upset Paul for the right reasons).

The rename in the code just got done last weekend (finally).

There are absolutely no plans to monetize the code. There might be 
always
commercial spins (i.e. any vendor who provides Quagga or the fork on 
their
box) and they may try this, but I’m not sure how legal this is under a 
GPL

license.
And Quagga and all it’s forks are locked to GPLv2 or later as it’s 
probably
impossible to ever contact all contributors and get them to agree to a 
license

change.

Some of the organizational structure behind is still in the discussion
phase at this time. We are trying to find a model where there is no 
single

entity able to take over or lock others out of it.

But some of the key differences is trying a different model where 
patches
submitted or pull requests get automatically integrated into a 
development

branch. Based on what was discussed last year for Quagga.

Anyway, no need to discuss this here in details. Donald posted the list
for the fork. Feel free to join and ask questions there. Just don’t 
expect

it all be ready yet.

- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16536] Re: NetDEF Transparency?

[Martin Winter]

On 12 Jan 2017, at 18:40, Paul Jakma wrote:


On Thu, 12 Jan 2017, Martin Winter wrote:

I can direct you to a tax person who can explain you who needs o be 
listed or not.


The money out covers only your salary and my contracting.


And your point? This is a IRS tax document with weird requirements on 
what to list or not. I
can’t make up things or report different for you. I have to follow the 
IRS guidelines (and

we use professional help for this, because it’s weird for me too)

You could have read my other email. OpenSourceRouting is a project by 
NetDEF. Nothing else. Not another company and you should know this.


I have no idea anymore what you are.


I’m a person who wants a good high-quality open source routing stack 
and works full-time on it.


I ask again: Are you and/or Alistair and/or David officers, employees 
or contractors for any other companies, or have been over last few 
years?


And I ask again, what has this to do with a simple request to give a 
quick announcement on changes

of a security list?
Action should all what matters.

I just asked for transparency to mention who got removed from the 
security list. I didn’t question the reasons. I just wanted to be 
the community aware of the changes. Very simple requests. That’s 
what I call transparency in the community.


Again, you have your fork. Why not go enjoy it?!

I'm happy to continue to talk to you about technical stuff on a 
constructive basis.


However, if you come here making insinuations, and continue to try 
stir up trouble in Quagga, as you've been doing for a long while then 
you won't get a warm welcome. I may have been a very naïve idiot in 
the past (and have made other mistakes, no doubt) about things, but I 
can learn.


So, again: Go enjoy your fork! If we have to fight, let's do it by 
competing on the code.


But note very carefully: I'm no longer as naïve. I've learned, and I 
will be keeping one ready in the chamber from now on, in case you come 
back with more games.


Read me clear: Go enjoy your fork.

 BTW, when I started contracting for NetDEF, I was told Alistair was 
seed
 funding it. What was the amount of that seed funding, and how much 
other

 sponsorship came in and when?


Look up the public records if you care about this. It’s all in 
there.


I note that's a non-answer.


It’s NOT relevant for this discussion and you are just side-tracking 
the whole discussion.


I let this stand like this and suggest to everyone read the archives 
of the list.


I note that I David has the off-list email, and I bet you do too.

OpenSourceRouting is a PROJECT of NetDEF. What part is not clear 
here? It’s not a company, it’s just a single project.


Again, the question was: What _other_ companies do you have?


None. Zero. Nada. Happy now? Can we get back to the main subject?

By forking, we accepted Quagga to be your project and we all accepted 
your

wish on not changing the structure.

I’m accepting your wish to withdraw from Quagga testing as well if 
this is

really is your wish.

- Martin


The rest on this email is really pointless for me to even respond.
Feel free to hate me (and NetDEF and everyone else who works on the 
fork).

Again, I didn’t come for a fight, just for a clarification.


I only asked for transparency. I didn’t want to fight. You seem to 
be interested in it.


Did I go to your project and start trolling with insinuations about 
transparency? No.


Hey, you havn't even got a public forum AFAIK. Where's my slack 
invite?


I’ve asked on details of the changes to made public by someone who 
knows (i.e. you, maybe others), so the community is aware who is 
still working on security issues.


Wah wah wah.

Go enjoy your fork Martin. Why are you even here?

That’s all. I mentioned that this wasn’t about me and there is no 
need to argue how I had to be kicked out because I work for such an 
evil non-profit and dare to work on more than one open source 
project.


I have 0 problems with:

1. For profits working on software.

2. Non-profits working on software, free or other wise.

3. Special status, tax-exempt non-profits working on free software.

4. People being sponsored or employed to work on software.

It's a free world, and that's how I like it, esp. for categories 1 and 
2. Category 3 is special though.


My question here is:

- You and David have involved yourself in Quagga under the mantle of
  '3', but have you got significant other business interests under 
some

  category that you've not disclosed to the community?

If you won't answer that "transparently" (the word of the week), then 
my strong advice to you, again, is:


  Go and enjoy your code, and stop messing around here!

You could have just responded that you made the decision to clean up 
the list because you felt that this and this and this person was no 
longer useful or wanted. This would have been helpful for the 
community (The Quagga Community which I still care about a lot)


Wah wah wah.

How many

[quagga-dev 16517] Re: Security list changes (Transparency?)

[Martin Winter]

Nick,

sorry, forgot to answer the last part or your email about reason etc
on fork:

First of all, we haven’t announced it yet. We want to get it to “rc1”
quality first before making it public. And we had to get a name (which
was a painful slow process and we are still making sure this name isn’t
violating any trademarks etc).
Name is probably the more important as the github location will change
again if we have to rename again.

In general, the idea on the fork was to try a different model of developing
similar to what was discussed last year (and blocked by Paul’s veto) for
the Quagga community.

We hope to get a much faster turnaround of new features and fixes into the
code. There are several companies interested in Quagga, but see it as
abandoned because of the slow speed. We try to change this by automating
more, have more maintainers and simple processes on getting code into the
project.

But everyone is welcome to join.

- Martin

On 11 Jan 2017, at 22:05, Nick Hilliard wrote:

> Martin Winter wrote:
>> I don’t like to have this discussion in privacy - this isn’t about
>> me. Maybe I did something stupid or you (or community?) decided on
>> new rules for who should be on it. I think it would be beneficial to
>> everyone to have make it public on who is on the list and probably
>> why they are on the list (so it makes somehow the selection more
>> transparent.
>
> Martin,
>
> Quagga was forked recently: github.com/freerangerouting/frr
>
> The commit logs in FRR show a good deal of activity since the split, and
> the freerangerouting.com domain seems to have been registered by Netdef.
>
> Usually forks happen after a breakdown of confidence and/or trust in the
> original project.  Without prejudice to whatever changes may have been
> made to the secur...@quagga.net email address, it looks like there has
> been a serious breakdown of communications.
>
> It would be helpful if there were some public discussion about what's
> happened, and why.  There are a lot of people who depend on the quagga
> code base, and trust in community projects depends on transparency.
>
> Nick

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16516] Re: Security list changes (Transparency?)

[Martin Winter]

On 12 Jan 2017, at 14:47, Paul Jakma wrote:


On Thu, 12 Jan 2017, Martin Winter wrote:

as competition or any rule that I wasn’t supposed to work on 2 
projects

at the same time.


To be clear, I tried my best to reconcile. Even after it was made 
clear you were forking, I would probably have been grudgingly OK.


But, NetDEF (or... which company and what kind?) went behind my back 
to get contact details for my manager, and talk to him. Just to find 
out if my employer thinks and if it would sponsor the fork - nothing 
else, _of course_.


Maybe I'm just overly touchy, but I found that a bit low. I couldn't 
even open my Quagga mail folder for a while after that.


(That was begin Nov).


So that was the reason? Do you think we should have NOT contacted HP 
because you work there? Or have contacted you

instead?

I assume a company might appreciate such a heads-up for their own 
planning. Maybe not like it, but better to

be informed and able to plan about it.

- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16514] Re: Security list changes (Transparency?)

[Martin Winter]

On 12 Jan 2017, at 14:11, Paul Jakma wrote:


On Thu, 12 Jan 2017, Martin Winter wrote:

Full disclosure: I helped the OpenBGPd folks in the past as well with 
testing infrastructure. So I might be a repeated “offender” if 
this is a crime.


Testing other open-source routing is great.

Funnily enough, I met one of the OpenBGPd guys at the UKNOF in Glasgow 
recently. We discussed testing and he mentioned the difficulties of 
that. I mentioned your testing work to him, that he should get in 
touch with you. He said he had, and that he'd been told that wasn't 
possible without money.


Partially correct. I offered them access to our infrastructure to do 
their own testing with some of our tools.
I cannot use funding dedicated for specific work and use it to test 
their project. So I offered the best I could

do without much of my time.
They used some of our infrastructure to do some testing. Not sure how 
much…


I would love to help them more testing, but I need someone paying for 
the time to be able to afford this and so

far I’m unable to do this.

- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16497] Re: Security list changes (Transparency?)

[Martin Winter]

On 11 Jan 2017, at 16:24, Paul Jakma wrote:


Hi Martin,

I removed you.

I'd be glad to talk further on transparency with you.


I think it would be beneficial for everyone to have a open discussion on 
who should be on the list

or not.

I don’t like to have this discussion in privacy - this isn’t about 
me. Maybe I did something stupid
or you (or community?) decided on new rules for who should be on it. I 
think it would be beneficial
to everyone to have make it public on who is on the list and probably 
why they are on the list (so

it makes somehow the selection more transparent.

BTW: It seems it was some larger “cleanup” as more people got 
removed as well. Not just me.


So please, can you share your thoughts publicly?

Regards,

- Martin


On Wed, 11 Jan 2017, Martin Winter wrote:


For the ones here who are unaware:

There is a security list (secur...@quagga.net) which deals with 
security issues reported to Quagga: Assessing them, fixing them, 
provide the much needed disclosures etc. This is a closed list which 
had mostly “maintainers” and a few other selected individuals on 
it.


As part of our testing, I used to be on this list as well - until 
yesterday when I was taken off without explanation.


Not blaming anyone, but I was surprised on it - and wanted to get a 
public discussion on who is on the list and that I might no longer be 
able to test security fixes in private as part of this.


So who is still on the list? Or did the list get deleted? Or what 
happened?


Regards,

- Martin Winter

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev



--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
A university faculty is 500 egotists with a common parking problem.


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16495] Security list changes (Transparency?)

[Martin Winter]

For the ones here who are unaware:

There is a security list (secur...@quagga.net) which deals with security 
issues reported to Quagga: Assessing them, fixing them, provide the much 
needed disclosures etc. This is a closed list which had mostly 
“maintainers” and a few other selected individuals on it.


As part of our testing, I used to be on this list as well - until 
yesterday when I was taken off without explanation.


Not blaming anyone, but I was surprised on it - and wanted to get a 
public discussion on who is on the list and that I might no longer be 
able to test security fixes in private as part of this.


So who is still on the list? Or did the list get deleted? Or what 
happened?


Regards,

- Martin Winter

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16485] [PATCH] zebra: fix build on OpenBSD >= 5.9

[Martin Winter]

From: Renato Westphal 

RTF_XRESOLVE was removed from the OpenBSD tree recently.

Signed-off-by: Renato Westphal 
---
 zebra/kernel_socket.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/zebra/kernel_socket.c b/zebra/kernel_socket.c
index 5e68c56..64c6cbb 100644
--- a/zebra/kernel_socket.c
+++ b/zebra/kernel_socket.c
@@ -242,7 +242,9 @@ static const struct message rtm_flag_str[] =
 #ifdef RTF_CLONING
   {RTF_CLONING,   "CLONING"},
 #endif /* RTF_CLONING */
+#ifdef RTF_XRESOLVE
   {RTF_XRESOLVE,  "XRESOLVE"},
+#endif /* RTF_XRESOLVE */
 #ifdef RTF_LLINFO
   {RTF_LLINFO,"LLINFO"},
 #endif /* RTF_LLINFO */
-- 
1.9.3 (Apple Git-50)


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16410] Re: [quagga-users 14524] quagga 1.1 seems to have completely broken ospf6

[Martin Winter]

I’ve reproduced the issue and created a topology test for it.

Thanks to Jan Hugo Prins for his time to help me debug this. Don’t know
why this didn’t trigger an error in my RFC compliance tests)

Test is requires a Ubuntu 16.04 with Mininet installed

Python script for the test and documentation is in the git at
https://git.netdef.org/scm/netdef/topotests.git

I’m going to add this test to my CI system AFTER the code is fixed
(otherwise every patch submission will be flagged as bad)

Regards,
   Martin Winter


PS: I have not spent time in any bisect or any search for the bad
commit. I hope someone else here takes over…

PSS: I’m working on topology tests for some time and I’m planning to add
more to the automated tests. Working on some BGP tests as well and
want to add several tests with route-map and redistribution etc to it.
Suggestions welcome…


On 15 Nov 2016, at 23:51, Nicolas DEFFAYET wrote:

> On Tue, 2016-11-15 at 15:12 -0800, Martin Winter wrote:
>
> Hello Martin,
>
>> Can you clarify on the “broken” in 1.1.0?
>
> https://bugzilla.quagga.net/show_bug.cgi?id=885
> https://bugzilla.quagga.net/show_bug.cgi?id=886
>
>> - FreeBSD Version?
>
> FreeBSD 11.0 but it's not related to FreeBSD because users have reported
> the same issue on Linux.
>
>> - Broken = no neighbors formed? No routes in routing table?
>
> Neighbors are formed but no routes in routing table.
>
> Between 1.0.20160315 and 1.1.0 the following commit have been done:
> ospf6d: fix off-by-one on display of spf reasons
> ospf6d: don't access nexthops out of bounds
> ospf6d: Fix double increment of Sequence Number
> ospf6d: Fix loss of hello's on interface
> ospf6d: Adding the initialization check in ospfv3_clean()
> ospf6d: Fixing a couple of issues with ospf6_route_remo...
> ospf6d: LA (local-address) bit related inter-op fix.
> ospf6d: We should accept long form of "no redistribute"
> ospf6d: Add the missing ospf6 running check in show...
> ospf6d: Support for 'clear ipv6 ospf6 interface [ifname]
> opsf6d: Update router-LSA when nbr's interface-ID changes
> ospf6d, ripd, vtysh: Fix "no set metric" for ospf6...
> ospf6d: implement admin distance
>
> One of this commit break ospf6d.
>
> Thanks
>
> -- 
> Nicolas DEFFAYET
>

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16402] Re: [quagga-users 14444] Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release)

[Martin Winter]

On 14 Nov 2016, at 21:20, Alexis Rosen wrote:

On Oct 18, 2016, at 1:56 AM, Martin Winter 
<mwin...@opensourcerouting.org> wrote:

Security Advisory: Quagga Buffer Overflow in IPv6 RA handling
=

[...] The issue can be triggered on an IPv6 address where the Quagga
daemon is reachable by a RA (Router Advertisement or IPv6 ICMP 
message.


So... Nearly a month later, I'm deleting old mail and noticed this.

As far as I can tell, this is an editing error of some sort, and in 
fact you can NOT trigger the issue simply by having an IPv6 address 
reachable with an ICMP.


How about this wording:

A buffer overflow exists in the IPv6 (Router Advertisement) code in
	Zebra. The issue can be triggered on any interface with a reachable 
IPv6 address

by a RA (Router Advertisement) or IPv6 ICMP message.
The issue leads to a crash of the zebra daemon.


Later in the advisory, it says:

Usage of Quagga without running the 'zebra' daemon, or no
IPv6 neighbor-discovery are not affected.


What this should say:
The issue is in Zebra daemon. So you are safe without Zebra daemon (i.e. 
some users only using BGPd)

You are also safe if you have the IPv6 neighbor-discovery disabled.

So maybe just a missing comma?

Usage of Quagga without running the 'zebra' daemon, or no
IPv6 neighbor-discovery, are not affected.

A quick look at the code also suggests this is so, but my familiarity 
with this code is basically nil, and it would be very easy for me to 
get this wrong.


Can someone who is certain please clarify? And maybe update the CVE so 
the sentence makes sense (and has balanced parentheses)?


I’ll update if you can confirm that these 2 small rewrites clarify the 
issue.


- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16305] Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release)

[Martin Winter]

Security Advisory: Quagga Buffer Overflow in IPv6 RA handling
=

A buffer overflow exists in the IPv6 (Router Advertisement) code in
Zebra. The issue can be triggered on an IPv6 address where the Quagga
daemon is reachable by a RA (Router Advertisement or IPv6 ICMP message.
The issue leads to a crash of the zebra daemon.

CVE:
CVE-2016-1245

Document Version:
1.0

Posting date:
Oct 18, 2016

Program Impacted:
Quagga (zebra) on Linux, with IPv6 AND IPv6 neighbor-discovery on any
interfaced enabled.  Usage of Quagga without running the 'zebra' daemon, or no
IPv6 neighbor-discovery are not affected.

Versions affected:
   - All Versions of Quagga running on Linux

Versions not affected:
   - All Versions of Quagga on FreeBSD/NetBSD/OpenBSD/Solaris are not affected.
   - Brocade 5400 vRouter - Not impacted.
   - Brocade 5600 vRouter - Not impacted.
   - BigSwitch Big Cloud Fabric code is not affected.

Severity:
High

Exploitable:
Remotely.

Description:
A buffer overflow exists in the IPv6 (Router Advertisement) code. The code
which handles IPv6 RA and IPv6 ICMP Router Solicitation advertisement
messages uses a wrong constant to limit its size.  This does not affect *BSD
systems (FreeBSD/OpenBSD/NetBSD) or OpenSolaris, but at least all Linux
based systems.

For the exploit to work, the Quagga instance needs to be reachable over
IPv6.  Any interface with IPv6 enabled can trivially allow the 'zebra'
daemon to be crashed (Denial-of-Service) via a buffer overflow.  The issue
can be avoided by having the IPv6 Neighbor Discovery turned off (see
workaround), which is the default state.

Note: the neighbor discovery needs to be turned off on _ALL_ interfaces for
this to workaround to apply (not just the connected or active interfaces).

The bug is in the 'zebra' daemon (the main daemon). Deployments that do not
run the 'zebra' daemon (e.g.  only running 'bgpd') are not affected.

On Linux distributions which compile Quagga with GCC -fstack-protector, the
impact may be limited to a DoS, as the GCC inserted stack-check function
epilogue should detect the overflow and safely abort the process if the bug
is exploited.  Otherwise, the bug may allow arbitrary code execution by a
remote attacker.

Quagga supports running as a non-root user and with lowered privileges,
using capabilities on Linux, and this is highly encouraged.  On Linux
distributions which configure Quagga to run this way, any exploit code will
be limited to a non-root environment, with 0 effective capabilities. The
acquirable capabilities are limited to CAP_NET_ADMIN, CAP_NET_RAW and
CAP_SYS_ADMIN.

CVSS v3 Base Score: 9.3

CVSS Equation:
For more information on the Common Vulnerability Scoring System and to
obtain your specific environmental score please visit:
https://nvd.nist.gov/cvss/v3-calculator?vector=3DAV:N/AC:L/PR:N/UI:N/S:U/
C:N/I:H/A:H/E:F/RL:X/RC:C

Workarounds:
Disable IPv6 neighbor discovery announcements on all interfaces ("ipv6 nd
suppress-ra" configured under all interfaces).  Make sure to have it
disabled on ALL interfaces.

Active exploits:
None known in the public at this time. Internal Proof-of-Concept code
exists.

Fixed Versions:
TBD

Solution:
Upgrade to Quagga 1.0.20161017 or upgrade to latest GIT Master version or
apply patches located at the URL below to your source code.

Quagga can be downloaded from the following location:
http://www.nongnu.org/quagga/ or https://github.com/Quagga/quagga

Patch (Commit) for security fix is at
https://github.com/Quagga/quagga/commit/cfb1fae25f8c092e0d17073eaf7bd428ce1cd546

Document Revision History:
1.0  22 September 2016 - Initial (internal) draft
1.1  18 October 2016   - CVE release version

Acknowledgments:
The issue was uncovered by David Lamparter at OpenSourceRouting.org

References:
* Do you have Questions? Questions regarding this advisory should go to
secur...@quagga.net or secur...@opensourcerouting.org


signature.asc
Description: OpenPGP digital signature
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16286] Open Bugs on Master (new compared to last release)

[Martin Winter]

Here is my list from the tests of actual new bugs in quagga master:

———
Test ANVL-BGPPLUS-21.1:
ProtocolBGP IPv6
Reference   RFC RFC 4271, Sect. 4.5, p 20, NOTIFICATION message format)
Issue:
No BGP notification sent by Quagga on Protocol violation
In my tests, I configure a IPv6 BGP peer on Quagga. I then open the TCP 
connection
(TCP only, no BGP OPEN sent) and send a BGP Keepalive without any BGP 
Open.
Correct behavior for Quagga is to send a BGP Notification and then close 
the
TCP connection, but Quagga just closes the TCP connection without 
sending the

notification
———
Test ANVL-OSPFV3-19.11 (and 3 more failing tests)
ProtocolOSPFv3 (IPv6)
Reference   RFC 5340, s4.4.3.2 p27 Router-LSAs
Issue:
Interface-ID in OSPF Router Link Tuple is incorrectly set to 0
Should be set to the OSPF Interface-ID
———

I worry mainly about the OSPFv3 issue. If someone wants to guess where 
it

broke down (i.e. commit), then I can try to narrow it down to the actual
commit which broke it.

- Martin




___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16231] [PATCH] bgpd: rename new -S (--skip_runas) to -U (--no_user) command line option

[Martin Winter]

As mentioned in the earlier message (see [quagga-dev 16210]), I propose
to change the newly introduced "-S" to BGPd to "-U". 
I want to avoid to rename options after a release and while -S isn't
use yet, it makes much more sense to use it for "vty_socket" as
we already have a vty_addr (-A) and vty_port (-P) option. -S fits
nicely into this scheme.
Patch to add "-S" (and other required changes for building snap packages)
will be sent after the current proposed 8 is published

TIME SENSITVE:
I think this needs to go into master before the upcoming release or
rejected (if there are reasons against it, but it may not make sense
anymore after an updated code with "--skip_runas" as currently set
for -S is released.

Martin Winter (1):
  bgpd: rename new -S (--skip_runas) to -U (--no_user) command line
option

 bgpd/bgp_main.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

-- 
1.9.3 (Apple Git-50)


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16214] Re: Proposed 8 testing Update

[Martin Winter]

On 10 Oct 2016, at 3:17, Philippe Guibert wrote:


Hi all,

It is great that the master branch has been merged with
origin/volatile/patch-tracking/8/proposed/ff-2016100701.
I was wondering, when will the next release open ?


Not what the exact plans is, but I prefer either a release
branch started now or new commits which are not only bug fixes to
be held up for a week to let the code “settle” and give everyone
time to test.

Is the CI automatically taking master branch to apply newly received 
patches ?


Yes, the patches emailed to the list (and picked up by patchwork)
are always tested against the latest master.

But we should go back to a discussion on how this should be done.
Personally, I would prefer to never ever have such a large 
“proposed”

branch. Preferrably commits to master on a continuous way.

I think Paul felt the pain very well and I’m curious what his 
suggestion

is at this time on how to do this in the future.

Paul?

- Martin



On Fri, Oct 7, 2016 at 7:15 PM, Lou Berger  wrote:

Paul/All,

A couple of suggestions:

1) do the update to master now and release once the integration run
completes

2) start immediately on the next release

3) require any multipart pass pull+regression using dev/automerge 
branch

(you choose if only ack'ed patches should be pull requested or not.)

Lou

On 10/7/2016 12:44 PM, Paul Jakma wrote:

On Fri, 7 Oct 2016, Igor Ryzhov wrote:


Maybe you can also apply them and include into the release?

I'll have a look and see.

Though, be even better to get just to steady integration and 
releases.
There's no reason not to have releases every couple of months - 
assuming

there's new stuff to be released.

regards,



___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16212] Re: Proposed 8 testing Update

[Martin Winter]

On 10 Oct 2016, at 1:40, Paul Jakma wrote:


Hi,

On Sat, 8 Oct 2016, Martin Winter wrote:


Paul,

if you are planning with an actual release, then please declare it as 
a release candidate on the list (maybe new email with such a subject 
to make it clear to everyone) and give it at least a week to settle 
and give everyone a chance to object. (Preferably we would create a 
branch with it, so we can move on with master)


Well, 'master' is a release candidate, go forth and test. :)


I’m working on it. I have a few “anomalies” in my test results 
which I like to

address and wanted to look at some static analysis as well.
So about a week of only critical bug fixes (feature freeze on the 
release candidate)

would be good for me.

And I would welcome anyone else to test as well

- Martin

My experience is people who care to test devel will do so anyway; 
while distros aren't going to package anything till there's a release 
('rc' version numbers that do not sort lexographically in the same 
order as the version order historically were problematic for at least 
some distro package tools, and may still be), and many people won't 
test anything till there's a distro package.


So, I'd tend to getting a release out ASAP, so it can go into the 
'testing' channels of distros ASAP, which will bring the most testing.


We can always document the expected stability levels in the release 
notes, e.g.:


 "This is a major release with many changes to the code. While it has
  many improvements and bug fixes, it also has at least a couple of
  known regressions. Another point release may follow shortly with
  further fixes. Please consider this a feature preview release and
  test accordingly."

We have an 'Unlimited' subscription with the Sofware Version 
Assignment Board - we're not on the €100 per version number PAYG 
option - so there's no need to conserve on version numbers, AFAIK. ;)


If someone wanted to maintain stable point releases (subset of the 
commits in 'master') of Quagga, that could be nice. Though, 'stable' 
means different things to different people, and so it can be a bit of 
a thankless task this.


There are still a few errors from my compliance testing which I want 
to look into. Will know more once I had time to look at it if it’s 
anything important.


Ok.

regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Behind every great computer sits a skinny little geek.


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16210] New "-S" (skip_runas) for bgpd in master

[Martin Winter]

Late notice on my side.. should have kept track of this, so I don’t 
blame anyone just asking about suggestion.


Lou added a “-S” option to skip the runas to BGPd and this is now 
based on proposed-8 merged to master.


I’ve added a similar option, but to all daemons as part of getting a 
Snap package built for Quagga.
However, I did not YET submit this to the list (didn’t wanted to hold 
up proposed 8 merge with new changes)


In case someone wants to look at it, the git for it is here:
https://git.netdef.org/scm/osr/quagga-snap.git

As part of getting Quagga to work as a snap, there are a few security 
limitations (Snap’s are some kind

of a container - see http://snapcraft.io/ )
The key limitations are:
	- All processes run as root inside the container - not setuid or setgid 
allowed

- No file access to anything outside the container

So in my case, I’ve added a check for uid and gid and skip the change 
if the target uid/gid already
matches our current uid/gid. I think, this is a much simpler and cleaner 
change and didn’t require any

new command line option.
However, I use the -S for the VTY socket location for all daemons. I 
can’t use a compiled in location
as the actual location of the writeable container space isn’t know 
until the snap is loaded. So I use

this to override it.

Anyway, suggestion to fix this conflict?

Choices:
	A) I rename the -S to something else (Suggestion welcome - needs to be 
available for all daemons)

B) We remove the —S (skip_runas) and use my solution

My solution for this issue is here:
https://git-us.netdef.org/projects/OSR/repos/quagga-snap/commits/45c1ae1f62960399902c0710df3892cb2f86905c

(as a side note: The “skip_runas” as implemented by Lou doesn’t 
work for me as it’s only solves some
of the changes. There are still various setreuid() calls which are 
executed and would kill the Quagga

Snap with a security violation)

- Martin Winter


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16209] Re: Proposed 8 testing Update

[Martin Winter]

Paul,

if you are planning with an actual release, then please declare it as a 
release candidate
on the list (maybe new email with such a subject to make it clear to 
everyone) and

give it at least a week to settle and give everyone a chance to object.
(Preferably we would create a branch with it, so we can move on with 
master)


There are still a few errors from my compliance testing which I want to 
look into.
Will know more once I had time to look at it if it’s anything 
important.


- Martin

On 7 Oct 2016, at 9:18, Paul Jakma wrote:


On Thu, 6 Oct 2016, Lou Berger wrote:

 So, that'd be a release blocker, but not a 'ff master' blocker, 
right?



Agreed!


master forwarded.

$ git log 
remotes/quagga-gnu/volatile/patch-tracking/7/proposed/ff..remotes/quagga-gnu/master 
\

  | awk '/^Date/ { count[$6]++} \
 END { for (i in count) print i,count[i] }'
2007 1
2013 2
2014 7
2015 58
2016 103
$ git log 
remotes/quagga-gnu/volatile/patch-tracking/7/proposed/ff..remotes/quagga-gnu/master 
| grep ^commit | wc -l

171
$ git log 
remotes/quagga-gnu/volatile/patch-tracking/7/proposed/ff..remotes/quagga-gnu/master 
| grep ^Author | sort -u

Author: Andrej Ota 
Author: Avneesh Sachdev 
Author: Ayan Banerjee 
Author: Balaji 
Author: Boian Bonev 
Author: boris yakubov 
Author: Christian Franke 
Author: Christian Franke 
Author: Colin Petrie 
Author: Daniel Walton 
Author: David Lamparter 
Author: Denil Vira 
Author: Dinesh Dutt 
Author: Dinesh G Dutt 
Author: Donald Sharp 
Author: Evgeny Uskov 
Author: Igor Ryzhov 
Author: Jafar Al-Gharaibeh 
Author: James Li 
Author: kitty 
Author: Lou Berger 
Author: Matthieu Boutier 
Author: Olivier Dugeon 
Author: Paul Jakma 
Author: Paul Jakma 
Author: Paul Jakma 
Author: Pawel Wieczorkiewicz 
Author: Philippe Guibert 
Author: Piotr Chytła 
Author: Pradosh Mohapatra 
Author: Roman Hoog Antink 
Author: Udaya Shankara KS 
Author: Vipin Kumar 
Author: Vivek Venkatraman 
Author: vivek 

Release either over the weekend or else on monday, unless something 
else is deemed better.


regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Is it possible that software is not like anything else, that it is 
meant to
be discarded:  that the whole point is to always see it as a soap 
bubble?


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16193] Re: Proposed 8 testing Update

[Martin Winter]

I think something to address before a release, but not sure if we should
hold off merging to master because of it.

Lou, are you proposing to fix this before merging to master?

-  Martin

On 6 Oct 2016, at 6:30, Lou Berger wrote:

> Paul,
>
> On October 6, 2016 6:05:14 AM Paul Jakma  wrote:
>
> ...
>>
>> One change from the last release in BGP is ANVL-BGPPLUS-17.1 related to
>> address used for nexthop - NHT related? Is it serious?
>>
>> Looks acceptable generally.
>>
>
> One outstanding issue for the release is operation of BGP without zebra.
>  (The NHT change basically introduces a requirement to run BGP with
> zebra, while there are route server/reflector configs which are viable
> now running only BGP.)
>
> I suggest changing the NHT code to either (a) automatically operate /
> adjust to when zebra isn't present or (b) have a bgp config option to
> ignore NHT, e.g., 'no bgp nexthop-tracking'.
>
> Do you/anyone have a preference?  -- Mine is (a).
>
> I (or Paul Z.) can propose a patch for this change.
>
> Lou
>

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16192] Re: Proposed 8 testing Update

[Martin Winter]

There are a few OSPFv3 issues as well

ANVL-OSPFV3-8.5 & 19.11-19.16

I have not looked yet into the failure case (sorry busy this week).
I would vote to address them after the merge to master.

- Martin

On 6 Oct 2016, at 3:02, Paul Jakma wrote:


On Wed, 5 Oct 2016, Martin Winter wrote:


Paul,

Results are updated.

See 
https://drive.google.com/drive/folders/0B8W_T0dxQfwxZFdJd1lPOXo3bHM?usp=sharing


OSPFv2 issues are fixed.
I haven’t looked at all the other protocols, but overall they seem 
to be mostly

ok.


Yeah, mostly unchanged. couple of cases for OSPFv2 where a test that 
generally fails passed with the last (broken) head. Maybe that's a 
consequence of other things failing that made that particular test 
seem to pass though.


One change from the last release in BGP is ANVL-BGPPLUS-17.1 related 
to address used for nexthop - NHT related? Is it serious?


Looks acceptable generally.

regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
The most difficult thing in the world is to know how to do a thing and 
to

watch someone else doing it wrong, without commenting.
-- T.H. White


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16183] Re: Proposed 8 testing Update

[Martin Winter]

Paul,

Results are updated.

See 
https://drive.google.com/drive/folders/0B8W_T0dxQfwxZFdJd1lPOXo3bHM?usp=sharing


OSPFv2 issues are fixed.
I haven’t looked at all the other protocols, but overall they seem to 
be mostly

ok.

Let me know if there are any concerns regarding a specific issue and 
I’ll look into it,
but might both have much time this week anymore (as I’m at a 
conference)


- Martin


On 5 Oct 2016, at 2:40, Martin Winter wrote:


On 4 Oct 2016, at 6:42, Paul Jakma wrote:


On Tue, 4 Oct 2016, Paul Jakma wrote:

Ah, never mind. stupid mis-merge, managed to drop one little but 
important hunk on the "ospfd: Don't wait for state change to 
Exchange to start LSReq" patch.


Passes CI. Fingers crossed we really are done on this now. :)


I assume this is now ft-2016100401 (git sha 743dd42) ?

Queuing for the full run next… (Will know in 1..2 days)

- Martin Winter



___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16182] Re: Proposed 8 testing Update

[Martin Winter]

On 5 Oct 2016, at 3:24, Martin Winter wrote:


On 5 Oct 2016, at 2:56, Olivier Dugeon wrote:


Hello Martin,

As only OSPF is concern, is it possible to restrict the tests 
conformity to only OSPF to speed up the process and get result sooner 
?


Not really. I’m running each protocol on it’s own (in parallel) 
and OSPF is the one taking the longest time.
I’ve added approx 10 of the failed tests to the CI system and they 
are currently running


(see https://ci1.netdef.org/browse/QUAGGA-QMASTER30-2 - look for the 
Extra OSPF Tests)

These tests were all failing before, but should pass.

I assume having 2 days wait for everyone before merge shouldn’t be a 
big issue (and maybe

giving others a chance to do some testing as well)


And they just all passed!
https://ci1.netdef.org/browse/QUAGGA-QMASTER30-EXTRAV4OSPF-2/test

So I think we are on the right track.
The full run is already under way…

- Martin


Le 05/10/2016 à 11:40, Martin Winter a écrit :

On 4 Oct 2016, at 6:42, Paul Jakma wrote:


On Tue, 4 Oct 2016, Paul Jakma wrote:

Ah, never mind. stupid mis-merge, managed to drop one little but 
important hunk on the "ospfd: Don't wait for state change to 
Exchange to start LSReq" patch.


Passes CI. Fingers crossed we really are done on this now. :)


I assume this is now ft-2016100401 (git sha 743dd42) ?

Queuing for the full run next… (Will know in 1..2 days)

- Martin Winter


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev




___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16181] Re: Proposed 8 testing Update

[Martin Winter]

On 5 Oct 2016, at 2:56, Olivier Dugeon wrote:


Hello Martin,

As only OSPF is concern, is it possible to restrict the tests 
conformity to only OSPF to speed up the process and get result sooner 
?


Not really. I’m running each protocol on it’s own (in parallel) and 
OSPF is the one taking the longest time.
I’ve added approx 10 of the failed tests to the CI system and they are 
currently running


(see https://ci1.netdef.org/browse/QUAGGA-QMASTER30-2 - look for the 
Extra OSPF Tests)

These tests were all failing before, but should pass.

I assume having 2 days wait for everyone before merge shouldn’t be a 
big issue (and maybe

giving others a chance to do some testing as well)

- Martin


Le 05/10/2016 à 11:40, Martin Winter a écrit :

On 4 Oct 2016, at 6:42, Paul Jakma wrote:


On Tue, 4 Oct 2016, Paul Jakma wrote:

Ah, never mind. stupid mis-merge, managed to drop one little but 
important hunk on the "ospfd: Don't wait for state change to 
Exchange to start LSReq" patch.


Passes CI. Fingers crossed we really are done on this now. :)


I assume this is now ft-2016100401 (git sha 743dd42) ?

Queuing for the full run next… (Will know in 1..2 days)

- Martin Winter


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev




___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16179] Re: Proposed 8 testing Update

[Martin Winter]

On 4 Oct 2016, at 6:42, Paul Jakma wrote:


On Tue, 4 Oct 2016, Paul Jakma wrote:

Ah, never mind. stupid mis-merge, managed to drop one little but 
important hunk on the "ospfd: Don't wait for state change to Exchange 
to start LSReq" patch.


Passes CI. Fingers crossed we really are done on this now. :)


I assume this is now ft-2016100401 (git sha 743dd42) ?

Queuing for the full run next… (Will know in 1..2 days)

- Martin Winter


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16166] Re: Proposed 8 testing Update

[Martin Winter]

On 3 Oct 2016, at 6:08, Paul Jakma wrote:


Hi Martin,

On Sun, 2 Oct 2016, Martin Winter wrote:


I did a full test run of our RFC compliance testbed against
volatile/patch-tracking/8/proposed/ff-2016093002 (Commit e4adc26)

Results are at
https://drive.google.com/drive/folders/0B8W_T0dxQfwxZFdJd1lPOXo3bHM?usp=sharing

The biggest issues seem to be several new failures on OSPFv2


Thanks for this.

My inclination is to release as is. Document regressions. Try fix them 
later.


Ouch. OSPFv2 seems to be seriously broken.
If you mean release as “an official release”, then I would vote 
against.
If you think just merge to master, then maybe. Still don’t like it (at 
least without

some attempt to fix it)

- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16159] Re: CI Testresult: FAILED (Re: [quagga-dev, 16135] Extend BGP_SEND_ASPATH_CHECK to cover confederations)

[Martin Winter]

On 1 Oct 2016, at 12:28, Thorvald Natvig wrote:


Hi,

This is my first patch to Quagga, so I'm not quite familiar with the
process. What's the next action to help this get reviewed? Should I
resubmit the patch so it gets tested again?


If you are able to find the issue, then yes please just create a v2 
version

and submit it again.

If you can’t find the problem (i.e. in this case: You tried to bring 
up a
RIPng with another Quagga instance or another router and it worked for 
you),

then let me know and I’ll look into more details.

If you want to verify the code as tested by the CI system,
then look at the URL for your test run and click on the artifact link.
There you can download the source (Base source with your patch applied)
and packages for various OS’es).

Let me know if you need any more help.


On Thu, Sep 29, 2016 at 4:31 PM, Martin Winter <
mwin...@opensourcerouting.org> wrote:

Hmm… my updated CI tests with a setup verification seems to fail 
including

any errors of it.

The issue here is that RIPng failed to bring up any neighbors (may 
have

crashed
at startup), so no RIPng test were executed.

- Martin


On 29 Sep 2016, at 12:00, cisys...@netdef.org wrote:

Continous Integration Result: FAILED


See below for issues.
This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter <mwin...@opensourcerouting.org>.

Patches applied :
  Patchwork 2074: http://patchwork.quagga.net/patch/2074
   [quagga-dev,16135] Extend BGP_SEND_ASPATH_CHECK to cover
confederations
Tested on top of Git : 5f67888 (as of 20160429.234845 UTC)
CI System Testrun URL: 
https://ci1.netdef.org/browse/QUAGGA-QPWORK-357/


Get source and apply patch from patchwork: Successful


Building Stage: Successful


Basic Tests: Failed

Static analyzer (clang): Successful
Ipv4 protocols on ubuntu 14.04: Successful

Regards,
  NetDEF/OpenSourceRouting Continous Integration (CI) System

---
OpenSourceRouting.org is a project of the Network Device Education
Foundation,
For more information, see www.netdef.org and 
www.opensourcerouting.org

For questions in regards to this CI System, contact Martin Winter,
mwin...@netdef.org







___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16156] Proposed 8 testing Update

[Martin Winter]

I did a full test run of our RFC compliance testbed against
volatile/patch-tracking/8/proposed/ff-2016093002 (Commit e4adc26)

Results are at
https://drive.google.com/drive/folders/0B8W_T0dxQfwxZFdJd1lPOXo3bHM?usp=sharing

The biggest issues seem to be several new failures on OSPFv2

I’ll look into more details later, but at Netdevconf next week - so 
limited

availability.

Regards,
   Martin Winter

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16157] Anyone at netdev conference in Tokyo?

[Martin Winter]

Any Quagga folks at the netdevconf (http://www.netdevconf.org/1.2/) in Tokyo?

If yes, ping me - would be good to get together for a beer.

- Martin Winter
  mwin...@opensourcerouting.org

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16138] Re: CI Testresult: FAILED (Re: [quagga-dev, 16135] Extend BGP_SEND_ASPATH_CHECK to cover confederations)

[Martin Winter]

Hmm… my updated CI tests with a setup verification seems to fail 
including

any errors of it.

The issue here is that RIPng failed to bring up any neighbors (may have 
crashed

at startup), so no RIPng test were executed.

- Martin

On 29 Sep 2016, at 12:00, cisys...@netdef.org wrote:


Continous Integration Result: FAILED

See below for issues.
This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter <mwin...@opensourcerouting.org>.

Patches applied :
  Patchwork 2074: http://patchwork.quagga.net/patch/2074
   [quagga-dev,16135] Extend BGP_SEND_ASPATH_CHECK to cover 
confederations

Tested on top of Git : 5f67888 (as of 20160429.234845 UTC)
CI System Testrun URL: 
https://ci1.netdef.org/browse/QUAGGA-QPWORK-357/


Get source and apply patch from patchwork: Successful


Building Stage: Successful


Basic Tests: Failed

Static analyzer (clang): Successful
Ipv4 protocols on ubuntu 14.04: Successful

Regards,
  NetDEF/OpenSourceRouting Continous Integration (CI) System

---
OpenSourceRouting.org is a project of the Network Device Education 
Foundation,

For more information, see www.netdef.org and www.opensourcerouting.org
For questions in regards to this CI System, contact Martin Winter, 
mwin...@netdef.org


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16102] Re: round-8: tentative proposed head for master

[Martin Winter]

On 15 Sep 2016, at 8:48, Paul Jakma wrote:

> On Thu, 15 Sep 2016, Paul Jakma wrote:
>
>> So how was it not in the OPEN?
>
> Sigh. It's cause the af config is not transferred to accept peer.

So I assume you found this issue?
Or do you still need help reproducing the problem?

- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16098] Re: round-8: tentative proposed head for master

[Martin Winter]

On 14 Sep 2016, at 0:44, Paul Jakma wrote:


On Tue, 13 Sep 2016, Martin Winter wrote:


Paul,

I’ve started it, but already found some BGP issues…

So somehow my CI testbed had a bug and when the basic setup of the 
BGP IPv6 tests failed (and caused all tests to skip),

then this was ignored (skipped instead of failed tests). Sorry :-(

This broke with the CI Pull Request #38 (and was fine up to and 
including #37)

https://github.com/opensourcerouting/quagga/pull/38

Should have been flagged as failed and not as good…



The issue (on IPv6 BGP):
“No supported <AFI, SAFI> combination found in the received BGP4 
Open Message”



This works for plain IPv4 BGP, but fails for IPv6 sessions.


Weird. I don't see what in the 2 leak fixes of #38 could cause a 
problem. I doubt your test even hits the paths either one change (you 
don't go in and delete the peer in bgpd via the CLI interface do you? 
and you're not testing AFI_ETHER either and anyway that path only is 
hit when shutting down bgpd)?


Can you get the tcpdump?


Sure :-) PCAP is attached.

You’ll see my tester opening the BGP session first
and giving in the capabilities IPv6 Unicast. The OPEN in response from
Quagga is missing the IPv6/Unicast AFI/SAFI

Here is the relevant config from the Quagga Side:

Current configuration:
!
![...]
!
interface eth2
 ip address 192.168.1.101/24
 ipv6 address fc00:192:168:1::101/64
!
![...]
!
router bgp 500
 bgp router-id 192.168.1.101
 network 192.168.1.0/24
 neighbor fc00:192:168:1::1 remote-as 501
 neighbor fc00:192:168:1::1 ebgp-multihop 255
 neighbor fc00:192:168:1::1 timers 60 180
!
 address-family ipv6
 network fc00:192:168:1::/64
 neighbor fc00:192:168:1::1 activate
 exit-address-family
 exit
!
ip forwarding
ipv6 forwarding
!
line vty
!
end

Let me know if you need anything else. I’m working to fix my CI to 
correctly detect issues like these.


- Martin

BGP_Session.pcap
Description: Binary data
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16096] Re: round-8: tentative proposed head for master

[Martin Winter]

Paul,

I’ve started it, but already found some BGP issues…

So somehow my CI testbed had a bug and when the basic setup of the BGP 
IPv6 tests failed (and caused all tests to skip),

then this was ignored (skipped instead of failed tests). Sorry :-(

This broke with the CI Pull Request #38 (and was fine up to and 
including #37)

https://github.com/opensourcerouting/quagga/pull/38

Should have been flagged as failed and not as good…

The issue (on IPv6 BGP):
“No supported  combination found in the received BGP4 Open 
Message”


This works for plain IPv4 BGP, but fails for IPv6 sessions.

Additionally, for AS4 BGP sessions (IPv4 or IPv6), there is a collision 
issue which then closes the session:

(I thought you fixed this - did the fix only apply to 2-byte AS?)

From the bgpd log for the collision:
2016/09/13 18:41:04 BGP: [Event] Make dummy peer structure until read 
Open packet
2016/09/13 18:41:04 BGP: 192.168.1.1 [FSM] TCP_connection_open 
(Active->OpenSent)

2016/09/13 18:41:04 BGP: 192.168.1.1 passive open
2016/09/13 18:41:04 BGP: 192.168.1.1 sending OPEN, version 4, my as 500, 
holdtime 180, id 192.168.1.101
2016/09/13 18:41:04 BGP: 192.168.1.1 send message type 1, length (incl. 
header) 51

2016/09/13 18:41:04 BGP: 192.168.1.1 went from Active to OpenSent
2016/09/13 18:41:04 BGP: 192.168.1.1 rcv message type 1, length (excl. 
header) 18
2016/09/13 18:41:04 BGP: 192.168.1.1 rcv OPEN, version 4, remote-as (in 
open) 23456, holdtime 90, id 192.168.1.1, inbound connection
2016/09/13 18:41:04 BGP: 192.168.1.1 [AS4] rcv OPEN w/ OPTION parameter 
len: 8, peeking for as4

2016/09/13 18:41:04 BGP: [AS4] found AS4 capability, about to parse
2016/09/13 18:41:04 BGP: 192.168.1.1 [AS4] about to set cap 
PEER_CAP_AS4_RCV, got as4 65538
2016/09/13 18:41:04 BGP: %NOTIFICATION: sent to neighbor 192.168.1.1 6/7 
(Cease/Connection collision resolution) 0 bytes
2016/09/13 18:41:04 BGP: 192.168.1.1 send message type 3, length (incl. 
header) 21
2016/09/13 18:41:04 BGP: Notification sent to neighbor 192.168.1.1: type 
6/7



Let me know if you need help to reproduce the issues

- Martin


On 13 Sep 2016, at 2:54, p...@jakma.org wrote:


Hi Martin,

I've got a head of commits that pass your CI (tested via the 
auto-merge feature) at:


 
http://git.savannah.gnu.org/cgit/quagga.git/log/?h=volatile/patch-tracking/8/proposed/ff-2016091301


It's 173 commits odd. Including a CVE fix for an issue with MRT 
dumping that can lead to an ABRT.


I believe you wanted to do a final full compliance run, before 
integration to master. After which we can do a release, and attack the 
next set of patches (which may also be a larger set than ideal, cause 
of the length of r8, but still more manageable - so we should converge 
on a more sane, faster turn-around on these soon).


regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Make sure every module hides something.
- The Elements of Programming Style (Kernighan & Plaugher)


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16038] Re: [PATCH 1/2] configure: fix static linking with readline

[Martin Winter]

On 31 Aug 2016, at 21:22, Baruch Siach wrote:


Hi Martin,

On Wed, Aug 31, 2016 at 12:02:42PM -0700, Martin Winter wrote:
I see this patch labeled as 1 of 2, but can't see the 2nd part (and 
my CI

system is ignoring it while waiting for the
2nd part.


The list archive got it:
https://lists.quagga.net/pipermail/quagga-dev/2016-August/016109.html.


Not sure what went wrong, but Patchwork only got the 1st part.
See https://patchwork.quagga.net/project/quagga/list/


Can you resend (both parts, preferrably labeled as v2) ?


I can do that if it helps. Let me know if you need it.


I would appreciate it. Or at least have the 2nd part sent again.
If the patch isn’t in Patchwork, then it won’t be tested by my CI 
system

and most likely the community will forget it (as it’s not tracked)

I’m not a patchwork expert, so sorry, don’t know what went wrong 
there.
If it still won’t make it after resending it, then let me know and 
I’ll

ping David to look into it (who maintains the patchwork)

- Martin

 http://baruch.siach.name/blog/  ~. .~   Tk Open 
Systems

=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16034] Re: Proposed-8 Testing Update & Github Pull Requests

[Martin Winter]

Paul,

On 25 Aug 2016, at 4:00, Paul Jakma wrote:


On Tue, 23 Aug 2016, Martin Winter wrote:

How about changing the build system (configure.ac I assume) to just 
use always C99 mode?


It does. It sets that when it can.

The thing is, if you supply a CFLAGS then that always overrides what 
was set - and I think that's automake, so nothing we can do in 
configure.ac. And it seems some of the CI system runs stuff that does 
that. Mostly in building packages. So it'll do the build, that works, 
then build packages - which starts a build from scratch in the ones I 
looked at - and some of those set CFLAGS but don't set -std=c99.


I thought the general idea is NOT to use CFLAGS for this and fix 
configure.ac.


See 
http://stackoverflow.com/questions/11647208/where-to-add-a-cflag-such-as-std-gnu99-into-an-autotools-project


They suggest to put
AC_PROG_CC_STDC
after
AC_PROG_CC

Did my way to build packages break this?

- Martin

Suggestion: Just do make dist and build the package from that. The 
package build tests the build, so a build before that isn't necessary 
- just adds further RTT to getting the patches through the CI.


As for CFLAGS in some of the package systems, not sure. Debian seems 
one as do some of the BSDs. Probably GCC version related too? (Maybe 
newer gccs don't error on C99 'for (..) by default?).


regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Never volunteer for anything.
-- Lackland

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16032] Re: Proposed-8 Testing Update & Github Pull Requests

[Martin Winter]

How about changing the build system (configure.ac I assume) to just use 
always C99 mode?


- Martin

On 23 Aug 2016, at 4:57, Paul Jakma wrote:


On Mon, 22 Aug 2016, Martin Winter wrote:

Yes, CFLAGS are overridden for some platforms (to find the needed 
libraries).


Hmm, so maybe we should just unconditionally add the required C99-mode 
flag to CFLAGS then? That seems kind of bad though.


I thought a later commit fixed the c99 issue (Or you changed the 
loop?). Not sure which commit this would be. Potentially adding this 
commit to the set of pull req 17 should fix it.


Yes, there's a later one that does.

Just, in general, I bet this won't be the last of having the CI fail 
cause someone used a C99 construct (and we require some C99 
constructs, but GCC accepts some in C89 and errors on others).


regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Enjoy your life; be pleasant and gay, like the birds in May.

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16030] Re: Proposed-8 Testing Update & Github Pull Requests

[Martin Winter]

Paul,

On 22 Aug 2016, at 9:27, Paul Jakma wrote:


On Tue, 9 Aug 2016, Martin Winter wrote:


I started at the beginning and cherry-picked commits from proposed 8
into a pull requests and so far got 46 commits of the 159 commits 
integrated.
See 
https://docs.google.com/spreadsheets/d/16UtC3epcRv6hx5dkRwPOtG3_wRVj5L5guB63g_hmw-s/edit#gid=1711194199
(The green highlighted commits are merged to the dev/automerge 
branch)


So, this got stuck at 'for (int ...)'? Cause the compiler is in 
less-than-C99 mode?


Which seems to be due to:

# Build the Debian Source and Binary Package
06-Aug-2016 15:45:33	cd quagga-test; /usr/bin/debuild 
--preserve-envvar WANT_LDP -us -uc

06-Aug-2016 15:45:34 dpkg-buildpackage -rfakeroot -D -us -uc
06-Aug-2016 15:45:34	dpkg-buildpackage: export CFLAGS from 
dpkg-buildflags (origin: vendor): -g -O2 -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Wformat-security
06-Aug-2016 15:45:34	dpkg-buildpackage: export CPPFLAGS from 
dpkg-buildflags (origin: vendor): -D_FORTIFY_SOURCE=2
06-Aug-2016 15:45:34	dpkg-buildpackage: export CXXFLAGS from 
dpkg-buildflags (origin: vendor): -g -O2 -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Wformat-security
06-Aug-2016 15:45:34	dpkg-buildpackage: export FFLAGS from 
dpkg-buildflags (origin: vendor): -g -O2
06-Aug-2016 15:45:34	dpkg-buildpackage: export LDFLAGS from 
dpkg-buildflags (origin: vendor): -Wl,-Bsymbolic-functions 
-Wl,-z,relro


in 
https://ci1.netdef.org/browse/QUAGGA-GITHUBOSRQUAGGA-CI002BUILD-81/log


Seems to be same issue for a few of them?

E.g., the OBSD fail, it's built fine the first time, but then tries to 
build it again to build packages but overrides the CFLAGS?


Yes, CFLAGS are overridden for some platforms (to find the needed 
libraries).



build   06-Aug-2016 15:44:04# Build package
build	06-Aug-2016 15:44:04	cd myport/net/quagga-test; export 
PORTSDIR=/home/ci/cibuild.81/myport; make package
build	06-Aug-2016 15:44:05	===>  Checking files for 
quagga-test-20160806.223947p0-git.1f408a5
build	06-Aug-2016 15:44:05 
`/home/ci/cibuild.81/myport/distfiles/quagga-source.tar.gz' is up to 
date.

build   06-Aug-2016 15:44:05>> (SHA256) quagga-source.tar.gz: OK
build	06-Aug-2016 15:44:05	===> 
quagga-test-20160806.223947p0-git.1f408a5 depends on: gawk-* -> 
gawk-4.1.3
build	06-Aug-2016 15:44:05	===> 
quagga-test-20160806.223947p0-git.1f408a5 depends on: gmake-* -> 
gmake-4.1p0
build	06-Aug-2016 15:44:05	===> 
quagga-test-20160806.223947p0-git.1f408a5 depends on: libexecinfo-* -> 
libexecinfo-0.2p5v0
build	06-Aug-2016 15:44:05	===>  Verifying specs:  c curses execinfo m 
readline termcap
build	06-Aug-2016 15:44:05	===>  found c.80.1 curses.14.0 execinfo.2.0 
m.9.0 readline.4.0 termcap.14.0
build	06-Aug-2016 15:44:05	===>  Extracting for 
quagga-test-20160806.223947p0-git.1f408a5
build	06-Aug-2016 15:44:06	===>  Patching for 
quagga-test-20160806.223947p0-git.1f408a5
build	06-Aug-2016 15:44:06	===>  Configuring for 
quagga-test-20160806.223947p0-git.1f408a5
build	06-Aug-2016 15:44:06	Using 
/home/ci/cibuild.81/myport/pobj/quagga-test-20160806.223947-git.1f408a5/config.site 
(generated)
build	06-Aug-2016 15:44:06	cd 
/home/ci/cibuild.81/myport/pobj/quagga-test-20160806.223947-git.1f408a5/quagga-source 
&& env  AUTOMAKE_VERSION=1.15  AUTOCONF_VERSION=2.69  autoreconf -fi 
<cut, but presumably also settting CFLAGS here?>

...
build	06-Aug-2016 15:44:26	checking whether to set a default CFLAGS... 
CFLAGS supplied by user


I'll try fix those, but can the testing stuff also be fixed to either 
not override CFLAGS, or else try remember to set std=c99?


I thought a later commit fixed the c99 issue (Or you changed the loop?). 
Not sure which commit this would be.

Potentially adding this commit to the set of pull req 17 should fix it.

Just couldn’t find the correct one.

- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16020] Proposed-8 Testing Update & Github Pull Requests

[Martin Winter]

All,

Trying to solve the issues of the Proposed-8 branch.

Where we stand:
- The current version of the branch compiles, but fails many protocol 
tests
- Git Bisect is currently not possible for the branch as the branch 
doesn’t

  compile up to the last commits (which fix previous bad commits)

I’ve started testing from the beginning of the branch and the first 
approx

25 commits are all fine before the problem starts.
Completely retesting and getting every commit working would be nice, but
is probably unfeasible.

I’ve setup a test for some automated testing and merging on our 
(OpenSourceRouting)
Github (github.com/opensourcerouting/quagga) to experiment with some 
ideas on
how we could do some automated testing/merging of new patches in the 
future.

(Using Github pull requests)

I’ve started by creating a dev/automerge branch based on master. If a 
pull
request is created against this branch (only this branch), then the CI 
system
will test the pull request. If it’s successful, the req will be merged 
by the

CI system. (and the next pull request can be opened).
If it fails, then I’ve tried to find the later commit which has the 
fixes,

updated the pull request and wait for the next test result.

I started at the beginning and cherry-picked commits from proposed 8
into a pull requests and so far got 46 commits of the 159 commits 
integrated.
See 
https://docs.google.com/spreadsheets/d/16UtC3epcRv6hx5dkRwPOtG3_wRVj5L5guB63g_hmw-s/edit#gid=1711194199

(The green highlighted commits are merged to the dev/automerge branch)

I think the system works, but it takes time to reorder the commits.
If someone wants to give it a try to continue finding working commits
from the remaining commits, then just fork the repo and make pull
requests against the dev/automerge branch.

If there are any issues, then just email me.

If you have better ideas then let me know. Feedback is always welcome.

- Martin Winter

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16014] Re: bgpd regression of 8/ff results (was Re: Someone rebased volatile/patch-tracking/8/proposed/ff branch)

[Martin Winter]

It does NOT work for me as this makes it impossible to test any further 
patch submission.


I would rather break proposed 8 into smaller pieces and submit them 
(i.e. the first approx 25 commits
are all fine as they are and I’m sure most of the later ones are fine 
too).


- Martin

On 5 Aug 2016, at 4:49, Nick Hilliard wrote:


On 5 Aug 2016, at 12:18, Paul Jakma  wrote:
If there are no conceptual objections to what's queued in ff, then we 
continue with merging and fix the bugs later. No?


Wfm. There's too much queued up in the commit queues to block on these 
problems. Pressing on will not impede fixes.


Nick


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16009] Messages "Multiple command installs to node 4 of command" when running vtysh

[Martin Winter]

This is with the latest proposed 8 (ft-2016080301 - commit 76dd32350)

When I start vtysh I get the following messages:

dut:~# vtysh
Multiple command installs to node 4 of command:
list
Multiple command installs to node 4 of command:
exit
Multiple command installs to node 4 of command:
quit
Multiple command installs to node 4 of command:
terminal length <0-512>
Multiple command installs to node 4 of command:
terminal no length
Multiple command installs to node 4 of command:
show daemons
Multiple command installs to node 4 of command:
ping WORD
Multiple command installs to node 4 of command:
ping ip WORD
Multiple command installs to node 4 of command:
traceroute WORD
Multiple command installs to node 4 of command:
traceroute ip WORD
Multiple command installs to node 4 of command:
ping ipv6 WORD
Multiple command installs to node 4 of command:
traceroute ipv6 WORD
Multiple command installs to node 4 of command:
telnet WORD
Multiple command installs to node 4 of command:
telnet WORD PORT
Multiple command installs to node 4 of command:
ssh WORD
Multiple command installs to node 4 of command:
show memory
Multiple command installs to node 4 of command:
show work-queues
Multiple command installs to node 4 of command:
show work-queues (zebra|ripd|ripngd|ospfd|ospf6d|bgpd|isisd)
Multiple command installs to node 4 of command:
show thread cpu [FILTER]
Multiple command installs to node 4 of command:
show logging
Multiple command installs to node 4 of command:
show ipv6 mroute vrf all

Hello, this is Quagga (version 1.0.20160315).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

dut#


I haven’t seen this before and it happens with all config disabled 
(just running zebra

and bgpd).

Any thoughts where this is coming from?
(These messages are not the breakage of the routing protocol, but at 
least annoying)


- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16008] Re: bgpd regression of 8/ff results (was Re: Someone rebased volatile/patch-tracking/8/proposed/ff branch)

[Martin Winter]

On 3 Aug 2016, at 7:25, Paul Jakma wrote:

> On Wed, 3 Aug 2016, Martin Winter wrote:
>
>> I think I found the issue for this one.
>>
>> My CentOS packages are built from the “make dist” tar file output.
>> And Makefile.am in doc/ is missing the isis file
>
> Ah, gah. :)
>
>> Can you confirm (and fix) ?
>
> $ tar -tzf quagga-1.0.20160315.tar.gz |grep isisd.texi
> quagga-1.0.20160315/doc/isisd.texi
>
> See ff-2016080301

Great.. so building the code now works on all the OS’es tested by our
CI system.

Now we need the routing protocols to work :-(

See https://ci1.netdef.org/browse/QUAGGA-QMASTER23-1

In my few basic checks, one of the ISIS tests, 2 of the IPv4 BGP tests
and one of the IPv6 BGP tests fail. :-(

I need a few hours for an initial investigation. (Read: Look at logs etc
to see if I can pinpoint something)

- Martin

>
> regards,
> -- 
> Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
> Fortune:
> Andrea's Admonition:
>   Never bestow profanity upon a driver who has wronged you.
>   If you think his window is closed and he can't hear you,
>   it isn't and he can.

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16005] Re: bgpd regression of 8/ff results (was Re: Someone rebased volatile/patch-tracking/8/proposed/ff branch)

[Martin Winter]

On 2 Aug 2016, at 5:51, Paul Jakma wrote:


On Mon, 1 Aug 2016, Martin Winter wrote:


Thanks.

It fixes some of the issues.

See https://ci1.netdef.org/browse/QUAGGA-QMASTER21-2 for test run

Next issues:

FreeBSD 8/9/10 / OmniOS / OpenBSD 5.8 / NetBSD 6/7:
   CC   stream.lo
 stream.c:26:10: fatal error: 'features.h' file not found
 #include 
  ^
 1 error generated.


Oh, bah :)

See small patch about to hit list on this.


CentOS 6:
 quagga.texi:113: @include: could not find isisd.texi
	 ./main.texi:104: @ref reference to nonexistent node `ISIS Traffic 
Engineering'

 quagga.texi:88: @menu reference to nonexistent node `ISIS'

CentOS 7:
 quagga.texi:113: @include `isisd.texi': No such file or directory.


Hmm, isisd.texi should be there in doc/? What happened there?


I think I found the issue for this one.

My CentOS packages are built from the “make dist” tar file output.
And Makefile.am in doc/ is missing the isis file

Can you confirm (and fix) ?

- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15990] Re: CI Testresult: FAILED (Re: [quagga-dev, 15986] bgp_route.c fix memory leak Introduced by: Author: Pradosh Mohapatra <pmoha...@cumulusnetworks.com> Date: Mon Nov 9 20:21:41 2015

[Martin Winter]

Resubmitted to be tested on top of commit 27185a96 (latest in 
proposed/8/ff branch)


Testrun is at https://ci1.netdef.org/browse/QUAGGA-QPWORK-344

But still failed:
Git Patch: Using "git apply" for patch 2030
error: patch failed: bgpd/bgp_route.c:3778
error: bgpd/bgp_route.c: patch does not apply

- Martin

On 1 Aug 2016, at 14:23, Lou Berger wrote:


no surprise here -- this patch applies to 8/proposed/ff

Lou

On 8/1/2016 5:20 PM, cisys...@netdef.org wrote:

Continous Integration Result: FAILED

See below for issues.
This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter <mwin...@opensourcerouting.org>.

Patches applied :
  Patchwork 2030: http://patchwork.quagga.net/patch/2030
   [quagga-dev,15986] bgp_route.c fix memory leak Introduced by: 
Author: Pradosh Mohapatra <pmoha...@cumulusnetworks.com> Date: Mon 
Nov 9 20:21:41 2015 -0500

Tested on top of Git : 5f67888 (as of 20160429.234845 UTC)
CI System Testrun URL: 
https://ci1.netdef.org/browse/QUAGGA-QPWORK-343/



Get source and apply patch from patchwork: Failed


Applying Patchwork patch 2030

Git Patch: Using "git apply" for patch 2030
error: patch failed: bgpd/bgp_route.c:3778
error: bgpd/bgp_route.c: patch does not apply

Regards,
  NetDEF/OpenSourceRouting Continous Integration (CI) System

---
OpenSourceRouting.org is a project of the Network Device Education 
Foundation,
For more information, see www.netdef.org and 
www.opensourcerouting.org
For questions in regards to this CI System, contact Martin Winter, 
mwin...@netdef.org




___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15985] Re: bgpd regression of 8/ff results (was Re: Someone rebased volatile/patch-tracking/8/proposed/ff branch)

[Martin Winter]

On 1 Aug 2016, at 9:57, Paul Jakma wrote:


Hi,

As per IRC other day, I pushed those little fixes. See

  volatile/patch-tracking/8/proposed/ff-2016080101

- lib: IEC559 tests are fragile, reduce to warning rather than error.

  This should fix the compile issues

- tests: Fix testbgpmpattr and make check, broken by BGP NHT.

- *: Remove some for statement declarations

- bgpd: Remove unused and leaking code

  (Lou's fix, left the other leak alone for now (?))



Thanks.

It fixes some of the issues.

See https://ci1.netdef.org/browse/QUAGGA-QMASTER21-2 for test run

Next issues:

FreeBSD 8/9/10 / OmniOS / OpenBSD 5.8 / NetBSD 6/7:
  CC   stream.lo
stream.c:26:10: fatal error: 'features.h' file not found
#include 
 ^
1 error generated.

CentOS 6:
quagga.texi:113: @include: could not find isisd.texi
	./main.texi:104: @ref reference to nonexistent node `ISIS Traffic 
Engineering'

quagga.texi:88: @menu reference to nonexistent node `ISIS'

CentOS 7:
quagga.texi:113: @include `isisd.texi': No such file or directory.


- Martin




regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
You have an ability to sense and know higher truth.


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15975] Re: CI Testresult: FAILED (Re: [quagga-dev, 15972] config: Give the option of disabling run as user/group)

[Martin Winter]

Ignore… the failure here was not because of the patch, but the build 
system itself.


Real report will follow yup in approx 1hr. (Rerunning now)

- Martin

On 28 Jul 2016, at 14:55, cisys...@netdef.org wrote:


Continous Integration Result: FAILED

See below for issues.
This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter <mwin...@opensourcerouting.org>.

Patches applied :
  Patchwork 2027: http://patchwork.quagga.net/patch/2027
   [quagga-dev,15972] config: Give the option of disabling run as 
user/group

Tested on top of Git : 5f67888 (as of 20160429.234845 UTC)
CI System Testrun URL: 
https://ci1.netdef.org/browse/QUAGGA-QPWORK-340/



Get source and apply patch from patchwork: Successful


Building Stage: Failed

OmniOS amd64 build: Successful
Openbsd58 amd64 build: Successful
Debian8 amd64 build: Successful
Ubuntu1404 amd64 build: Successful
Ubuntu1204 amd64 build: Successful
NetBSD7 amd64 build: Successful
FreeBSD10 amd64 build: Successful
FreeBSD9 amd64 build: Successful
CentOS7 amd64 build: Successful
NetBSD6 amd64 build: Successful
FreeBSD8 amd64 build: Successful

CentOS6 amd64 build: No useful log found

Regards,
  NetDEF/OpenSourceRouting Continous Integration (CI) System

---
OpenSourceRouting.org is a project of the Network Device Education 
Foundation,

For more information, see www.netdef.org and www.opensourcerouting.org
For questions in regards to this CI System, contact Martin Winter, 
mwin...@netdef.org


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15970] Re: [PATCH] config: Give the option of disabling run as user/group

[Martin Winter]

NAK

This fails my package builds.

Here is how I configure the packages for my testing:
	--build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include 
--mandir=${prefix}/share/man --infodir=${prefix}/share/info 
--sysconfdir=/etc --localstatedir=/var 
--libexecdir=${prefix}/lib/quagga-test --disable-maintainer-mode 
--disable-dependency-tracking 
--enable-exampledir=/usr/share/doc/quagga/examples/ 
--localstatedir=/var/run/quagga --sbindir=/usr/lib/quagga 
--sysconfdir=/etc/quagga --enable-vtysh --enable-isisd --enable-pimd 
--enable-watchquagga --enable-ospf-te --enable-opaque-lsa --enable-ipv6 
--enable-ospfclient=yes --enable-ospfapi=yes --enable-multipath=64 
--enable-user=quagga --enable-group=quagga --enable-vty-group=quaggavty 
--enable-configfile-mask=0640 --enable-logfile-mask=0640 --enable-rtadv 
--enable-gcc-rdynamic --enable-tcp-zebra --enable-fpm 
--enable-isis-topology --with-libpam 
--with-pkg-extra-version=-ci.NetDEF.org-20160727.222003-git.5f67888


When I install the package and try to run rip afterwards, then I get:

root@ci-comp8-dut:~# ripd -d
privs_init: user((null)) is not part of vty group specified(quaggavty)

We (at OpenSourceRouting) had a similar issue, but the main use when 
Quagga was already started under the correct user,

then we just skip the user (and group) changes.
Just an alternative thought. Happy to send the change to the list (or 
you) if the community prefers this choice.


- Martin


On 27 Jul 2016, at 15:02, Jafar Al-Gharaibeh wrote:


Leave "user/group" unset when explicitly configuring with
"--disable-user" and "--disable-group". This allows quagga
to skip unsupported system calls such as setuid() on certain
platfroms.

Signed-off-by: Jafar Al-Gharaibeh 
---
 configure.ac | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 6206510..b349131 100755
--- a/configure.ac
+++ b/configure.ac
@@ -351,14 +351,16 @@ AC_SUBST(ISIS_TOPOLOGY_LIB)

 if test "${enable_user}" = "yes" || test x"${enable_user}" = x""; 
then

   enable_user="quagga"
+  AC_DEFINE_UNQUOTED(QUAGGA_USER, "${enable_user}", Quagga User)
 elif test "${enable_user}" = "no"; then
-  enable_user="root"
+  enable_user=""
 fi

 if test "${enable_group}" = "yes" || test x"${enable_group}" = x""; 
then

   enable_group="quagga"
+  AC_DEFINE_UNQUOTED(QUAGGA_GROUP, "${enable_group}", Quagga Group)
 elif test "${enable_group}" = "no"; then
-  enable_group="root"
+  enable_group=""
 fi

 if test x"${enable_vty_group}" = x"yes" ; then
@@ -371,8 +373,6 @@ fi
 AC_SUBST([enable_user])
 AC_SUBST([enable_group])
 AC_SUBST([enable_vty_group])
-AC_DEFINE_UNQUOTED(QUAGGA_USER, "${enable_user}", Quagga User)
-AC_DEFINE_UNQUOTED(QUAGGA_GROUP, "${enable_group}", Quagga Group)

 enable_configfile_mask=${enable_configfile_mask:-0600}
 AC_DEFINE_UNQUOTED(CONFIGFILE_MASK, ${enable_configfile_mask}, Mask 
for config files)

--
2.7.4


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15967] Re: bgpd regression of 8/ff results (was Re: Someone rebased volatile/patch-tracking/8/proposed/ff branch)

[Martin Winter]

On 27 Jul 2016, at 9:10, Paul Jakma wrote:


On Wed, 27 Jul 2016, Paul Jakma wrote:


 The final commit in the proposed branch fails various BGP dejagnu
 tests, but has the above



Don't know what that's about..


Ok, that's a one-liner. See other patch that should hit list about 
same time as tis email.


I’ve tried to apply this on top of proposed-8 (on top of Git d944f2e).
This fixes Ubuntu 14.04
See https://ci1.netdef.org/browse/QUAGGA-QPWORK-339

On all the other OS’es it fixes the dejagnu, but just failed at the 
next step again:


1) Ubuntu 12.04 / Debian 8 / CentOS 6 / CentOS 7 : - Passes the normal 
compile, but fails recompiling when

recompiling as a package

  CC thread.lo
  CC if.lo
if.c: In function 'if_link_params_get':
if.c:1151:3: error: 'for' loop initial declarations are only allowed in 
C99 mode
if.c:1151:3: note: use option -std=c99 or -std=gnu99 to compile your 
code

make[5]: *** [if.lo] Error 1

(Somehow the “-std=gnu99” option does not get configured when 
building packages. I need

to investigate this further)

2) FreeBSD 8/9/10, NetBSD 6/7, OpenBSD, OmniOS: - fails compiling:

make  all-am
  CC   network.lo
network.c:109:2: error: "Please supply htonf implementation for this 
platform"

#error "Please supply htonf implementation for this platform"
 ^

Didn’t we fix this?

- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15966] Re: bgpd regression of 8/ff results (was Re: Someone rebased volatile/patch-tracking/8/proposed/ff branch)

[Martin Winter]

On 27 Jul 2016, at 8:24, Paul Jakma wrote:


On Tue, 26 Jul 2016, Martin Winter wrote:

Up to commit 4ab273b (“lib: Replace lists with arrays to store read 
and write threads”) all is fine for my basic tests.


Commit b9ac2f3 (“lib: Consolidate VIEW_NODE to be ENABLE_NODE as 
well”) breaks “make check”

(Dejagnu libzebra test “testcli”)
See https://ci1.netdef.org/browse/QUAGGA-QMASTER20-30/test
or for the full “make test” output here:
https://ci1.netdef.org/browse/QUAGGA-QMASTER20-30/artifact/CI001BUILD/ErrorLog/log_dejagnu.txt

Somehow a later commit fixes this again, but I have not yet 
identified the fixing commit.

(Tested up to Git 4933f23, approx 8 commits later)


I think the fix must be in dc36f29a86 / 'lib: keep hash of node's 
commands to detect duplicate installs', which removes the duplicate 
installs.


If so, how would you like to proceed?


I’ve tried to apply this as a patch earlier, but there seem to be more 
issues (which then get fixed later again).


So not sure if we should abandon the attempt to have the branch passing 
any basic checks or even just compiling

at each commit.
In general, I would prefer if each commit passes at least compiling and 
potentially some basic checks, but that would

potentially require to rebuild all the branch again after 4ab273b.

The final commit in the proposed branch fails various BGP dejagnu 
tests, but has the above


Don't know what that's about..

regards
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
DEC diagnostics would run on a dead whale.
-- Mel Ferentz


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15942] Re: bgpd regression of 8/ff results (was Re: Someone rebased volatile/patch-tracking/8/proposed/ff branch)

[Martin Winter]

On 21 Jul 2016, at 6:54, Paul Jakma wrote:


On Wed, 20 Jul 2016, Lou Berger wrote:


Id say give them / someone a chance to  provide a fix...


Well, if Martin wants to run that through his torture testing, we can 
advance master if there's no bad breakage.


There is at least one issue left - the final commit fails on the DejaGNU 
unit tests


(see here: https://ci1.netdef.org/browse/QUAGGA-QMASTER20-CI001BUILD-1 )

I’ve started (yet again), going through all the commits one by one…
It will take some time. (Expect approx 1 commit per 15 min in best case)

Once the basic checks pass, then I can try to run a full test suite…

- Martin



regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Your aim is high and to the right.


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15922] Re: Patchwork updated

[Martin Winter]

On 19 Jul 2016, at 9:01, David Lamparter wrote:

> DNS changed (Thanks Paul!), Certificate rolled out, TLS now available:
> https://patchwork.quagga.net/
>
> I'll add a redirect from HTTP to HTTPS after checking if that breaks
> Martin's CI scripts again ;)

Done on my side.

And I’ve pushed all the test results (back to patchwork 1400) to patchwork.
It should be now visible if the CI ran for the patch and the status for
it (and it includes the link to the results as well)

Thanks to David to add the fancy colors on the test results.

- Martin


> On Tue, Jul 19, 2016 at 02:34:46PM +0200, David Lamparter wrote:
>> On Tue, Jul 19, 2016 at 11:49:06AM +0100, Paul Jakma wrote:
>>> On Tue, 19 Jul 2016, David Lamparter wrote:
 Thanks; the problem there is a different one though - my hosting setup
 has a separate reverse proxy doing all TLS handling; i.e. the
 patchwork setup can't access its own certificates.  I'm using the ACME
 DNS method to get my LetsEncrypt certificates for my own domains
 (which the TLS box handles perfectly on its own, and I like the clear
 security zoning with that);  on the other hand the HTTP method becomes
 very cumbersome to use since I'd need to push either the auth-tokens
 or certificates around between zones.
>>>
>>> Ah, ok.
>>>
 For now I'm very tempted to not sink additional time into it and leave
 it as https://patchwork.diac24.net -- is there a real demand/need to
 have https://patchwork.quagga.net too?
>>>
>>> I don't know! I guess HTTPS-by-default is better, if easy to do, but
>>> probably not important enough for this.
>>>
>>> There apparently is a way to do the LetsEncrypt validation via DNS
>>> records, but I don't know if ACME clients support that (the ACME client
>>> I use does not). If that was a fairly static key to setup and your
>>> client worked with that, could try that.
>>
>> That's what my setup uses for everything else; my ACME client writes to
>> my zonefiles through a small script.
>>
>> The solution with minimal total sum of work for both of us is probably
>> if you change the dns record for patchwork.quagga.net to:
>>   patchwork.quagga.net. IN NS ns.diac24.net.
>> so I can put the acme challenge there and get the certificate.
>>
>> (My DNS server already serves the zone, set that up in the past 5 min)
>>
>>
>> -David
>>
>> ___
>> Quagga-dev mailing list
>> Quagga-dev@lists.quagga.net
>> https://lists.quagga.net/mailman/listinfo/quagga-dev
>
> ___
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-dev

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15905] Re: Patchwork updated

[Martin Winter]

Automated testing of submitted patches is back on.
Updated for new patchwork (now using RPC XML interface instead
of scraping the HTML pages)

I’ve tested the parsing of the last 250 patchwork submission
and all seem to be fine
(with the exception of a single series of patches not detected as it
wasn’t sent by git-send-mail)

- Martin

On 13 Jul 2016, at 16:41, Martin Winter wrote:

> On 13 Jul 2016, at 14:25, David Lamparter wrote:
>> Hi all,
>>
>> I've just installed the most recent version of patchwork; the upgrade
>> was a bit bumpy - please report any malfunctions.  It looks quite a bit
>> different since upstream moved to bootstrap for styling, but
>> functionally there isn't much different.
>>
>> There is now also a https URL available at:
>> https://patchwork.diac24.net
>> in addition to the usual:
>> http://patchwork.quagga.net
>
> Nice new interface… but change will break (temporarily) the CI
> integration.
> I have the automatic CI currently disabled until this I have it updated
> (which will happen in the next 24hrs).
>
> If anyone submits a patch, then the CI results will be delayed until
> I have the update done.
>
> - Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15902] Re: Patchwork updated

[Martin Winter]

On 13 Jul 2016, at 14:25, David Lamparter wrote:
> Hi all,
>
> I've just installed the most recent version of patchwork; the upgrade
> was a bit bumpy - please report any malfunctions.  It looks quite a bit
> different since upstream moved to bootstrap for styling, but
> functionally there isn't much different.
>
> There is now also a https URL available at:
> https://patchwork.diac24.net
> in addition to the usual:
> http://patchwork.quagga.net

Nice new interface… but change will break (temporarily) the CI
integration.
I have the automatic CI currently disabled until this I have it updated
(which will happen in the next 24hrs).

If anyone submits a patch, then the CI results will be delayed until
I have the update done.

- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15893] Patch breaking "make check"

[Martin Winter]

I’ve started the testing at the bottom of the proposed/8/ff branch, 
running each version

through my build and basic protocol tests.

The first commit which breaks my tests (“make check” fails on all 
platforms) is
“lib: Consolidate VIEW_NODE to be ENABLE_NODE as well” by Donald 
Sharp

(currently commit 0dbe0d2 unless somebody rebases again)

make check
[…]
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file 
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for 
target.

Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./libzebra.tests/tabletest.exp ...
Running ./libzebra.tests/test-timer-correctness.exp ...
Running ./libzebra.tests/testcli.exp ...
FAIL: testcli

Everything before this commit seems to be fine going through my basic 
tests.


- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15872] Re: Someone rebased volatile/patch-tracking/8/proposed/ff branch

[Martin Winter]

On 7 Jul 2016, at 1:24, Paul Jakma wrote:


On Wed, 6 Jul 2016, Martin Winter wrote:

This time you managed to break the Github mirror. My update scripts 
correctly detect the savannah as the newer and try to push to github, 
but the github git doesn’t accept it.


The volatile/... ref updates are not fast-forwards and I guess Github 
disallows non-ff merges/updates (Savannah does too). On Savannah, you 
have to explicitly delete the ref first and push it again. You do that 
by specifying an empty ref as the source in the :dst> ref specifier.


Already fixed.

the issue wasn’t the fast-forwards or non-ft merges/updates.
The issue was that volatile/patch-tracking/8/nits was pushed first, but 
then in the update
this turned into part of the path on volatile/patch-tracking/8/nits/a 
and volatile/patch-tracking/8/nits/b


I fixed it by deleting the old nits branch before the push

- Martin



I.e. to delete:

git push  :refs/heads/volatile/etc/etc/rebased_ref

E.g., if I want to update a volatile staging ref on Savannah, and I've 
rebased it I have to do:


REF=blah

git push  
:refs/heads/refs/heads/volatile/patch-tracking/8/$REF
git push  
$REF:refs/heads/refs/heads/volatile/patch-tracking/8/$REF


regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Conceit causes more conversation than wit.
-- LaRouchefoucauld


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15870] Re: Someone rebased volatile/patch-tracking/8/proposed/ff branch

[Martin Winter]

Ok, fixed.

the issue was that you created a proposed/nits, then deleted it again 
and created a proposed/nits/a and proposed/nits/b

So it failed to push the nits/a because nits existed.

- Martin

On 6 Jul 2016, at 15:31, Martin Winter wrote:

This time you managed to break the Github mirror. My update scripts 
correctly
detect the savannah as the newer and try to push to github, but the 
github git

doesn’t accept it.

Not sure yet what went wrong, but the mirroring between the git’s is 
now

turned off until I can figure out a way to fix this.
(which is preferably not a delete and fresh mirror on github)

- Martin

quaggamirror@git-us:~/mirrors/q-savannah.git$ git push --mirror
Counting objects: 1029, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (282/282), done.
Writing objects: 100% (1029/1029), 344.32 KiB | 0 bytes/s, done.
Total 1029 (delta 860), reused 897 (delta 747)
To g...@github.com:Quagga/quagga.git
 ! [remote rejected] volatile/patch-tracking/8/proposed/ff -> 
volatile/patch-tracking/8/proposed/ff (failed)
 ! [remote rejected] volatile/patch-tracking/8/proposed/pushback 
(failed)
 ! [remote rejected] volatile/patch-tracking/8/proposed/nits/a -> 
volatile/patch-tracking/8/proposed/nits/a (failed)
 ! [remote rejected] volatile/patch-tracking/8/proposed/nits/b -> 
volatile/patch-tracking/8/proposed/nits/b (failed)
 ! [remote rejected] volatile/patch-tracking/8/proposed/pushback/a -> 
volatile/patch-tracking/8/proposed/pushback/a (cannot lock ref 
'refs/heads/volatile/patch-tracking/8/proposed/pushback/a': 
'refs/heads/volatile/patch-tracking/8/proposed/pushback' exists; 
cannot create 
'refs/heads/volatile/patch-tracking/8/proposed/pushback/a')
 ! [remote rejected] volatile/patch-tracking/8/proposed/pushback/b -> 
volatile/patch-tracking/8/proposed/pushback/b (failed)

error: failed to push some refs to 'g...@github.com:Quagga/quagga.git'



On 6 Jul 2016, at 7:27, Paul Jakma wrote:


On Wed, 6 Jul 2016, Paul Jakma wrote:

Sigh, I screwed something up. I'll have to reset those heads again, 
sorry.


Ah, 'ff' did stay stable. {nits,pushback}/b updated.

Thanks to Jim Carlson for catching my dumb mistake in replacing 
"(A.B.C.D|X:X::X:X)" with a define.


regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
In the future, you're going to get computers as prizes in breakfast 
cereals.

You'll throw them out because your house will be littered with them.


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15868] Re: Someone rebased volatile/patch-tracking/8/proposed/ff branch

[Martin Winter]

This time you managed to break the Github mirror. My update scripts 
correctly
detect the savannah as the newer and try to push to github, but the 
github git

doesn’t accept it.

Not sure yet what went wrong, but the mirroring between the git’s is 
now

turned off until I can figure out a way to fix this.
(which is preferably not a delete and fresh mirror on github)

- Martin

quaggamirror@git-us:~/mirrors/q-savannah.git$ git push --mirror
Counting objects: 1029, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (282/282), done.
Writing objects: 100% (1029/1029), 344.32 KiB | 0 bytes/s, done.
Total 1029 (delta 860), reused 897 (delta 747)
To g...@github.com:Quagga/quagga.git
 ! [remote rejected] volatile/patch-tracking/8/proposed/ff -> 
volatile/patch-tracking/8/proposed/ff (failed)
 ! [remote rejected] volatile/patch-tracking/8/proposed/pushback 
(failed)
 ! [remote rejected] volatile/patch-tracking/8/proposed/nits/a -> 
volatile/patch-tracking/8/proposed/nits/a (failed)
 ! [remote rejected] volatile/patch-tracking/8/proposed/nits/b -> 
volatile/patch-tracking/8/proposed/nits/b (failed)
 ! [remote rejected] volatile/patch-tracking/8/proposed/pushback/a -> 
volatile/patch-tracking/8/proposed/pushback/a (cannot lock ref 
'refs/heads/volatile/patch-tracking/8/proposed/pushback/a': 
'refs/heads/volatile/patch-tracking/8/proposed/pushback' exists; cannot 
create 'refs/heads/volatile/patch-tracking/8/proposed/pushback/a')
 ! [remote rejected] volatile/patch-tracking/8/proposed/pushback/b -> 
volatile/patch-tracking/8/proposed/pushback/b (failed)

error: failed to push some refs to 'g...@github.com:Quagga/quagga.git'



On 6 Jul 2016, at 7:27, Paul Jakma wrote:


On Wed, 6 Jul 2016, Paul Jakma wrote:

Sigh, I screwed something up. I'll have to reset those heads again, 
sorry.


Ah, 'ff' did stay stable. {nits,pushback}/b updated.

Thanks to Jim Carlson for catching my dumb mistake in replacing 
"(A.B.C.D|X:X::X:X)" with a define.


regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
In the future, you're going to get computers as prizes in breakfast 
cereals.

You'll throw them out because your house will be littered with them.


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15842] Re: Someone rebased volatile/patch-tracking/8/proposed/ff branch

[Martin Winter]

On 1 Jul 2016, at 8:03, Paul Jakma wrote:


On Thu, 30 Jun 2016, Martin Winter wrote:

Didn’t we had this discussion back in february and agreed not to do 
rebasing?


Where?


http://ipv6.gossamer-threads.com/lists/quagga/dev/30142?search_string=FreeBSD%20Testing%20Update;#30142

Unless you claim that this only applied to the proposed/6 branch. I took 
this as an agreement for

general work on proposed branches.


It really makes testing painful.


If there are serious reason for a rebase, then I would rather see a 
8a branch (and the old 8 branch abandoned) I would prefer to just 
have fixes/reverse commits added on top of it.


Well, that's why it has 'volatile' in the namespace. Rather than 
create a myriad of string refs, instead it'd be easier to just do 
something like:


If $REF contains "volatile"
set REF to the commit ID instead.

The commit ID will be stable.


But this doesn’t solve the issue on tracking where things broke. I 
would need to tag the test runs with

every commit ID included in the code. Not really a solution…

- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15831] Someone rebased volatile/patch-tracking/8/proposed/ff branch

[Martin Winter]

Didn’t we had this discussion back in february and agreed not to do 
rebasing?

It really makes testing painful.

If there are serious reason for a rebase, then I would rather see a 8a 
branch

(and the old 8 branch abandoned)
I would prefer to just have fixes/reverse commits added on top of it.

So, please, please - no more rebasing.

- Martin Winter


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15830] Re: [PATCH 21/89] bgpd: Improve peer scaling

[Martin Winter]

Paul,

I think Donald is out for a week vacation…

On 30 Jun 2016, at 7:36, Paul Jakma wrote:


Hi,

Was it this patch that Martin said caused issues for his CI/testing? 
(There's a few revisions/resends).


I think so, but would need to go back to my old emails (but I don’t 
think it’s relevant for

the question below)

If so, should we keep the jitter? (It'll just go between 1 and 0 then 
I think).


I would vote for no. I think that was sensible in the past, but today it 
gets into the way of
everyone wanting fast convergence. And yes, it makes my testing more 
painful (but that shouldn’t

count if there is a real use case/need for it).

Curious what everyone else thinks.

- Martin



regards,

Paul

On Fri, 11 Dec 2015, Donald Sharp wrote:


From: Daniel Walton 

Reduce the amount of time it takes to bring up a large number of 
peers


Signed-off-by: Daniel Walton 
---
bgpd/bgp_fsm.c | 14 ++
bgpd/bgpd.h|  2 +-
2 files changed, 3 insertions(+), 13 deletions(-)

diff --git a/bgpd/bgp_fsm.c b/bgpd/bgp_fsm.c
index 0d38bfc..4fbd639 100644
--- a/bgpd/bgp_fsm.c
+++ b/bgpd/bgp_fsm.c
@@ -63,13 +63,6 @@ static int bgp_keepalive_timer (struct thread *);
/* BGP FSM functions. */
static int bgp_start (struct peer *);

-/* BGP start timer jitter. */
-static int
-bgp_start_jitter (int time)
-{
-  return ((random () % (time + 1)) - (time / 2));
-}
-
static void
peer_xfer_stats (struct peer *peer_dst, struct peer *peer_src)
{
@@ -178,8 +171,6 @@ peer_xfer_conn(struct peer *from_peer)
void
bgp_timer_set (struct peer *peer)
{
-  int jitter = 0;
-
  switch (peer->status)
{
case Idle:
@@ -192,9 +183,8 @@ bgp_timer_set (struct peer *peer)
}
  else
{
- jitter = bgp_start_jitter (peer->v_start);
  BGP_TIMER_ON (peer->t_start, bgp_start_timer,
-   peer->v_start + jitter);
+   peer->v_start);
}
  BGP_TIMER_OFF (peer->t_connect);
  BGP_TIMER_OFF (peer->t_holdtime);
@@ -203,7 +193,7 @@ bgp_timer_set (struct peer *peer)
  break;

case Connect:
-  /* After start timer is expired, the peer moves to Connnect
+  /* After start timer is expired, the peer moves to Connect
 status.  Make sure start timer is off and connect timer is
 on. */
  BGP_TIMER_OFF (peer->t_start);
diff --git a/bgpd/bgpd.h b/bgpd/bgpd.h
index 82b4efc..d58c7bf 100644
--- a/bgpd/bgpd.h
+++ b/bgpd/bgpd.h
@@ -786,7 +786,7 @@ struct bgp_nlri
#define BGP_EVENTS_MAX  15

/* BGP timers default value.  */
-#define BGP_INIT_START_TIMER 5
+#define BGP_INIT_START_TIMER 1
#define BGP_DEFAULT_HOLDTIME 9
#define BGP_DEFAULT_KEEPALIVE3
#define BGP_DEFAULT_EBGP_ROUTEADV   30



--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Eloquence is logic on fire.


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15821] Tools Document Review - Summary of call

[Martin Winter]

ans some maintainers have to enforce and teach manually good 
emails’ policy. For instance: http://dpdk.org/dev#send . But after using other 
automatic tools, I could notice that even web tools require some manual policy 
and teaching.
   * No inline code review nor possibility to amend a patch
   * Cons: Not supporting work in multiple branches as it is not clear to which 
base commit the patches should apply to
   * Cons: Difficult to correlate multi-part patches and potential partial 
updates of some patches in a serie
   * 



1. (Temp) Voting Sheet
We’ll remove this chapter later, but to speed up the discussion, I would prefer 
everyone reading this to highlight their preference in the table below. Feel 
free to vote for “none” or anything else not listed above if this is your 
preference.




Name
Issue Tracking choice
Code Review choice
    Code Submission
Martin Winter
GitHub Issue Tracking
(no strong preference, but like it because of API)
Or bugzilla if API is useable
Gerrit on top of Github (gerrithub.io)
Github (as I don’t see the +1/+2 etc voting as part of Quagga process)
Mailing list + Github Pull Requests. Support both, but push for large 
sets (1 of XX to Github)
Vincent JARDIN
bugzilla
emails
Upstream first (email patch) from the day 1, iterate. Do not send 50 
patches of a feature, but iterate.
Stop using branches, it creates fragmentation.
Olivier Dugeon
GitHub or Savannah
Gerrit alone or on top of GitHub


Lou
No strong preference
No strong preference
Email patch + github pull requests
David Bond
GitHub or Jira (no strong preference)
Gerrit alone or on top of GitHub (I believe you can still use the 
command line git review tool?)


Donald Sharp
Bugzilla especially if email is hooked up
No Strong Preference
Email( Make it easy for people to DO IT)
David Lamparter
No strong preference
Any, but must be possible to send E-Mail as input.
E-Mail + pull requests (not necessarily GitHub)
Jafar Al-Gharaibeh
Bugzilla
Email (+GitHub)
Email + GitHub Pull Requests
















[a]I strongly suggest to stay on patchwork but it shall be better explained and 
emails must be policed. For instance, ack't, v2 of a patch must be sent using 
the thread id of the email. I do suggest this tool that has been developped by 
6WIND: https://github.com/Qeole/PatchCmd - 
https://addons.mozilla.org/fr/thunderbird/addon/generate-patch-command/


Why patchwork? it is basic, but other tools break the email dynamics, they are 
not proven to systain history after 10y+ Thanks to emails archives, we can 
still track old threads which are 10y olds.___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15743] Re: Quagga project governance

[Martin Winter]

On 27 Jun 2016, at 5:22, Paul Jakma wrote:


[any 'you' in the below may be general case than you specifically]

On Mon, 27 Jun 2016, Lou Berger wrote:


 In terms of specific development processes, things have evolved and
 should continue to evolve.


Why is this recent discussion anything than an evolution of the 
process?


If it's meant to be evolution, show me the evolutionary path? Give me 
a "diff" from the current processes to what is being proposed?


I assume you mean a diff to the current process:

I think the attempt here started with some suggestion with a disregard 
of existing process and
then over multiple stages of discussion go and adapt it to current 
process. Just a different
process, but still the end product (or better: the current suggestion) 
is not completely different.
It’s actually only different on a few sections. (i.e. the maintainer 
doc on adding rules of

removing maintainers based on inactivity among a few other things)

Just the fact one must have a Google account to participate in this 
suggests this is far from an evolution.


You don’t need a google account. The documents are shared on Google, 
but anyone can access them

without logging into Google and edit/comment on them.

For the phone calls: You don’t need a google account either. Anyone 
can join the calls with whatever
email they get the invite on or just by getting the link forwarded to 
them. (Unless Donald didn’t

by accident allow this)

But yes, you need access to google.
But again, unless there is someone having an actual issue, then there is 
no need to move. (Other tools
have other limitations). We could move the docs to a Wiki if needed, 
calls to any other service.

Nobody insisted to this on Google.

I accept that there may not be as much understand and context of 
quagga's history as think there should be. But if those that have the 
history or are not participating in the discussion , that history 
will be missed. While this isn't preferred, we can't compel people to 
participate.


That's a 2-way street.

And it has seemed to have left you somewhat abandoned by the other 
"maintainers".


Look, it really gives me _no_ joy to make other people unhappy. 
Honestly. I _want_ you to be happy, and if you want a project where:


- Decisions are made by Google Hangouts at a time that suits US TZ


I think it suits europe better at the usual monthly 13:00 GMT time.
(and that’s fair as I have the feeling that most participants are
in europe)
But there are no final decisions. They are discussions.


- Contributors can game (consciously or not) things by simply ignoring
  comments for nearly 2 years, then rally others to vote in their
  changes en bloc with talk about how the development process is 
broken,

  _failing to mention_ how they helped break it.


And maintainers can veto things just because they don’t like it (i.e. 
I can
do it better, but I don’t have the time for it, so VETO) or force 
lengthy

discussions over ideas on improving the RFCs and breaking compatibility.
This does not encourage any participation…


- Any old crap goes into master, just if whatever random 'Acks'
  (completely immune to gaming is that!), and anyone who might have
  views just happens to have taken even a brief holiday (cause,
  holidays, who needs those).

  [the goal of reducing rebases is a good one, and fast cycles and
   auto-collated proposed trees would help with that, but some of what
   I've read so far is just "I want magic ponies!" in that regard]


If you prefer things to go in if there is NO voice (no ACK, no NACK)
like it should be now, then please explain how this is better.

I think a random ACK is still better.
And it seems to work for some other communities.

Then _please_ go set up that project. I'm _*begging*_ you. _How clear 
do I have to be?_


Really, we'll _all_ be happier.


You really seem to be unwilling to move from your positions and rather
break the community in 2 (or more parts).

Sad.

- Martin Winter



Me, I'm going to:

- Keep going through the last of the backlog, and sort it out.

- Get the obvious stuff in ASAP, get nits pushed back ASAP to the
  contributors so they can fix them, and derail stuff that needs wider
  discussion (and sorry that just happens in distributed, 
decentralised

  development sometimes - people just /happen/ to pull in different
  directions, and it needs resolving; and the outcome can mean
  significant reworking or even lost work; it happens, it happens to
  me].

- Listen to people's comments on patches, including my own. I manage 
to
  listen to other people's opinions on my patches - I might not like 
the

  comments or agree with them. I don't see why this is a problem in a
  well functioning community.

- Find people willing to help constructively, who are willing to work 
to

  consensus

  [that can mean going with majority opinion usually, but still
  respecting people when there's something they really don't get

[quagga-dev 15742] Tools Document Discussion

[Martin Winter]

We haven’t discussed the tools document so far and I would like to 
have a
Google Hangout call to discuss and try to clean it up as much as 
possible.


This is the document up for discussion:
https://docs.google.com/document/d/1s_EbbXwqWPmfOg6ArgKmEMm_iv0vwGvJs-7ZG4yFKb4/edit?usp=sharing

To make it clear (for the ones thinking that this is a definitive 
decision):
Only discussing it, resolving some (as much as we can) of the 
differences.

We can continue to have the discussion on the list afterwards.
I would still prefer if as many as possible can attend the call.

For this, I suggest a Google Hangout this Thursday
at 13:00 GMT:
06:00 US Pacific
09:00 US East Coast
15:00 Central Europe
21:00 China (Bejing)

I’ve sent a Hangout invite to the same people who are on the monthly 
list.

If you want to be added, then let me know.

If you can’t/don’t want to use Google Hangout, then feel free to 
email me
your phone number privately and I’ll add you by phone (phone call). 
Please

let me know if possible 1hr prior to the meeting.

Regards,
  Martin Winter

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15741] Re: Multiple Test failures in Round 8 - Anyone working on fixes?

[Martin Winter]

On 27 Jun 2016, at 7:52, Paul Jakma wrote:


On Sat, 25 Jun 2016, Martin Winter wrote:

My bad. I thought that only patches which are in a working stage 
should be selected for proposed branch (the “proposed” would be 
for code review, functionality etc).


Maybe my bad for not pre-sorting those onto some 'pushback' branch 
then.


I’m partially a bit frustrated on the guesswork on automatically 
testing series of patches - which is the reason why I’m pushing to 
try the github pull request model for this. Patchwork has no concept 
of series of the patches.


I thought it did? It seems to get the '[Patch X/Y]' in the right order 
in the web-UI at least, even when they go through the list in another 
order and get non-consecutive PW IDs. Though, the non-consec IDs will 
make scripting annoying.


It does partially. But the series have no common subject or reference to 
match the series. I can only guess that there aren’t

2 overlapping series from the same contributor.
At the time of updates (when people only send a v2 for a specific patch) 
it gets even worse as I have a hard time to
go back to find the original series and to guess if I should rerun 
immediately or wait for another v2 part from the same

series.

At this time, I look at subject, msg-id and sender and try to 
re-assemble the series. But this fails whenever someone resubmits 
just a single replacement v2 patch or doesn’t use “git 
send-email”. So the larger the patch, the more likely my automated 
system fails to detect them.


Ouch. We need another way.

I'm really leaning towards Bugzilla now. There are at least two 
different sets of git tools. The one I've tried is good enough. It 
would give one ID for patch-trains, with the ability for a contributor 
to manage and update revisions of the attached patches. Etc. It 
doesn't try take over.


The instance we have needs upgrading though. The other downside is 
that, iirc, git bz doesn't quite work with HTTP proxies - though that 
seems to be some issue with the underlying library somehow. However, 
there's a lot of projects using it to some degree AFAICT - fate 
sharing is nice.




My hope is still Pull Requests on Github. I can’t say how well it 
works, but I’m eager to give it some tries.
Personally I prefer someway a 2-path version: the current version (works 
fine for one-off patches and for contributors

which are not regulars) and a some pull-requests for more complex ones.

Maybe your proposed branch could be a pull request as well?
(Discussion could be still linked back to list, potentially with some 
proxy to forward it. There is no requirement

for discussion to be on Github)
Would allow to redo the pull request multiple times without cluttering 
the official git history.


Doesn’t matter if it’s part of a series or not - it should get 
you directly to the test run(s) for

that specific patch.


Cool


Would love to mark pass/fail on patchwork each pass automatically, but 
not sure if/how this could be done.


- Martin Winter



 Aha, will look.


Would be good to remind everyone that it IS (or should be) a 
requirement for
acceptance that it passes “make check” at the time of a patch 
submission.


Ah, yes. +1

regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Pure drivel tends to drive ordinary drivel off the TV screen.


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15727] Re: Quagga project governance

[Martin Winter]

Adding to this…


On 24 Jun 2016, at 9:16, Lou Berger wrote:

> Paul,
>
>
> On 6/24/2016 11:33 AM, Paul Jakma wrote:
>> On Fri, 24 Jun 2016, Lou Berger wrote:
>>
>>> I can only speak to what's motivated my participation in this
>>> discussion. I think the root issues I'd like to see addressed are:
>>> 1.  no ability to predict when the next release with *any* fixes will be
>>> available
>>> 2.  lack of an active (rolling) development/integration master branch
>>> 3.  lack of visibility and transparency in the integration and release
>>> process
>> The process developed late last year, initiated by Vincent and developed
>> into roughly month-based rounds of queueing patches objectively (i.e.
>> hoovering up everything possible from patchwork that came in since last
>> round); posting summary mails of said 'proposed' queue to the list;
>> having a bounded review period; and then sorting patches into:
>>
>> - deferred
>> - rejected
>> - accepted
>>
>> based on the feedback, then testing 'accepted' and merging into master,
>> was supposed to have answered 2 and 3. Though 'deferred' probably not a
>> good idea, and 'rejected' probably should be 'pushedback' or somesuch.
>>
>> Particularly on 3, the idea being that between the summary mail at the
>> start of the review period and 'gitk --all' at the end, it'd be very
>> clear what went where.
>>
>> To what extent did that fail to be transparent.
> so this is respect to 3.
>
> I personally don't recall a discussion on this on list, but perhaps
> missed it.  I also don't see the process documented anywhere.  Also,
> it's unclear how patches Ack'ed on list would end up anywhere but
> accepted.  -- Keep in mind, my perspective is as user and contributor,
> not maintainer.

Yes, a lot of confusion. Even for patches which got ack’ed, it is completely
unknown if and when they go into the active development branch.
(They could sit on patchwork for a long time).
Things going in on more FREQUENT interval (and in smaller batches) would
make things so much easier.

>> On 2, it seemed to be going well. We had (almost) month based
>> integration rounds, and had (from whatever arbitrary starting point in
>> patchwork) clear everything in patchwork from at least that point
>> forward.
>>
>> Why was that not meeting the 'active integration head' objective?
> It comes down to where I should do my development, test and
> submissions.  Right now there is no changes between releases except at
> the last minute (or couple of weeks).  This means:
> - no testing on ack'ed patches
> - no easy way for a user to see if an issue is addressed by the dev branch
> - submitted patches are often out of date (and need rebasing) and
> occasionally are duplicative

Strongly support this.
I really think that things need to move from ACK into the master
(or whatever the development branch is) in matter of days. This would
make integration (and testing) much simpler: Further contribution would
be tested on top of the development branch and it would be much more
clear when/what broke - and give more people time to test against the
growing development tree.

The current model of “proposed trees” just doesn’t work. It was a fair
try, but I think we now have enough evidence to improve the process.

>> Further, why did that break down earlier this year? (I know what it
>> looks like to me, and I have asked this question several times now on
>> list, and no one answers).
>
> I have no idea.  I only got involved beyond the contributor level once
> things broke down.

I think most of this is based (at least) on confusion.
Most people think that you only look at yourself, Vincent and Greg as
actual maintainers and the rest (i.e. Donald) as sub-maintainers or
“round keepers” without the right on merging into master without your
ok. This is not encouraging their work.

>>> I probably wouldn't have cared enough to speak up on 3 if 1 and 2
>>> weren't issues.
>> Great, so why not propose fixes that make reference to the current
>> practices?
> This is where I started, but couldn't find it documented anywhere. And
> it seemed that others had their own ideas.

Yes, I think that’s exactly what these 3 documents are trying to do.
I think this is a great start on consolidating everyones thoughts and
experience and trying to come up with a new way.
It might not be perfect on the first try, but at least a group
of active contributors would like to give it a new try.

>>  Rather than just go with a clean-sheet document that (at
>> best) ignores prior experience and lessons and the realities of
>> integration.
> What about any of the 3 discussed documents leads you to conclude they
> are clean-sheet documents?  I see folks that have been active for a
> while contributing to each?

Some here. I see a lot of them just documenting the existing way
(at least as I think it is right now). Only a few changes to actual
work.

>> Indeed, it's primary feature (in the early draft I read) seemed to be
>> "Let's have one branch for 

[quagga-dev 15726] CC defines on various (supported) OS for Quagga

[Martin Winter]

Attached are a few CC defines for reference.
I assume most of the people on this list don’t have all the OS’es 
available to check

for supported defines.

(This is based on the recent breakage on *BSD for __STDC_IEC_559__ )

Enjoy,
   Martin Winter

CentOS 7 Linux 3.10.0-327.13.1.el7.x86_64 #1 SMP Thu Mar 31 16:04:38 UTC 2016

[root@ci005 ~]# gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[root@ci005 ~]# gcc -dM -E - < /dev/null | sort
#define __amd64 1
#define __amd64__ 1
#define __ATOMIC_ACQ_REL 4
#define __ATOMIC_ACQUIRE 2
#define __ATOMIC_CONSUME 1
#define __ATOMIC_HLE_ACQUIRE 65536
#define __ATOMIC_HLE_RELEASE 131072
#define __ATOMIC_RELAXED 0
#define __ATOMIC_RELEASE 3
#define __ATOMIC_SEQ_CST 5
#define __BIGGEST_ALIGNMENT__ 16
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __CHAR16_TYPE__ short unsigned int
#define __CHAR32_TYPE__ unsigned int
#define __CHAR_BIT__ 8
#define __code_model_small__ 1
#define __DBL_DECIMAL_DIG__ 17
#define __DBL_DENORM_MIN__ ((double)4.94065645841246544177e-324L)
#define __DBL_DIG__ 15
#define __DBL_EPSILON__ ((double)2.22044604925031308085e-16L)
#define __DBL_HAS_DENORM__ 1
#define __DBL_HAS_INFINITY__ 1
#define __DBL_HAS_QUIET_NAN__ 1
#define __DBL_MANT_DIG__ 53
#define __DBL_MAX_10_EXP__ 308
#define __DBL_MAX__ ((double)1.79769313486231570815e+308L)
#define __DBL_MAX_EXP__ 1024
#define __DBL_MIN_10_EXP__ (-307)
#define __DBL_MIN__ ((double)2.22507385850720138309e-308L)
#define __DBL_MIN_EXP__ (-1021)
#define __DEC128_EPSILON__ 1E-33DL
#define __DEC128_MANT_DIG__ 34
#define __DEC128_MAX__ 9.9E6144DL
#define __DEC128_MAX_EXP__ 6145
#define __DEC128_MIN__ 1E-6143DL
#define __DEC128_MIN_EXP__ (-6142)
#define __DEC128_SUBNORMAL_MIN__ 0.1E-6143DL
#define __DEC32_EPSILON__ 1E-6DF
#define __DEC32_MANT_DIG__ 7
#define __DEC32_MAX__ 9.99E96DF
#define __DEC32_MAX_EXP__ 97
#define __DEC32_MIN__ 1E-95DF
#define __DEC32_MIN_EXP__ (-94)
#define __DEC32_SUBNORMAL_MIN__ 0.01E-95DF
#define __DEC64_EPSILON__ 1E-15DD
#define __DEC64_MANT_DIG__ 16
#define __DEC64_MAX__ 9.999E384DD
#define __DEC64_MAX_EXP__ 385
#define __DEC64_MIN__ 1E-383DD
#define __DEC64_MIN_EXP__ (-382)
#define __DEC64_SUBNORMAL_MIN__ 0.001E-383DD
#define __DEC_EVAL_METHOD__ 2
#define __DECIMAL_BID_FORMAT__ 1
#define __DECIMAL_DIG__ 21
#define __ELF__ 1
#define __FINITE_MATH_ONLY__ 0
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __FLT_DECIMAL_DIG__ 9
#define __FLT_DENORM_MIN__ 1.40129846432481707092e-45F
#define __FLT_DIG__ 6
#define __FLT_EPSILON__ 1.1920928955078125e-7F
#define __FLT_EVAL_METHOD__ 0
#define __FLT_HAS_DENORM__ 1
#define __FLT_HAS_INFINITY__ 1
#define __FLT_HAS_QUIET_NAN__ 1
#define __FLT_MANT_DIG__ 24
#define __FLT_MAX_10_EXP__ 38
#define __FLT_MAX__ 3.40282346638528859812e+38F
#define __FLT_MAX_EXP__ 128
#define __FLT_MIN_10_EXP__ (-37)
#define __FLT_MIN__ 1.17549435082228750797e-38F
#define __FLT_MIN_EXP__ (-125)
#define __FLT_RADIX__ 2
#define __FXSR__ 1
#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
#define __GCC_ATOMIC_INT_LOCK_FREE 2
#define __GCC_ATOMIC_LLONG_LOCK_FREE 2
#define __GCC_ATOMIC_LONG_LOCK_FREE 2
#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
#define __GCC_ATOMIC_SHORT_LOCK_FREE 2
#define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
#define __GCC_HAVE_DWARF2_CFI_ASM 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
#define __GNUC__ 4
#define __GNUC_GNU_INLINE__ 1
#define __GNUC_MINOR__ 8
#define __GNUC_PATCHLEVEL__ 5
#define __GNUC_RH_RELEASE__ 4
#define __gnu_linux__ 1
#define __GXX_ABI_VERSION 1002
#define __INT16_C(c) c
#define __INT16_MAX__ 32767
#define __INT16_TYPE__ short int
#define __INT32_C(c) c
#define __INT32_MAX__ 2147483647
#define __INT32_TYPE__ int
#define __INT64_C(c) c ## L
#define __INT64_MAX__ 9223372036854775807L
#define __INT64_TYPE__ long int
#define __INT8_C(c) c
#define __INT8_MAX__ 127
#define __INT8_TYPE__ signed char
#define __INT_FAST16_MAX__ 9223372036854775807L
#define __INT_FAST16_TYPE__ long int
#define __INT_FAST32_MAX__ 9223372036854775807L
#define __INT_FAST32_TYPE__ long int
#define __INT_FAST64_MAX__ 9223372036854775807L
#define __INT_FAST64_TYPE__ long int
#define __INT_FAST8_MAX__ 127
#define __INT_FAST8_TYPE__ signed char
#define __INT_LEAST16_MAX__ 32767
#define __INT_LEAST16_TYPE__ short int
#define __INT_LEAST32_MAX__ 2147483647
#define __INT_LEAST32_TYPE__ int
#define __INT_LEAST64_MAX__ 9223372036854775807L
#define __INT_LEAST64_TYPE__ l

[quagga-dev 15725] Re: Multiple Test failures in Round 8 - Anyone working on fixes?

[Martin Winter]

On 24 Jun 2016, at 2:44, Paul Jakma wrote:


Hi Martin,

Cheers.

On Fri, 24 Jun 2016, Martin Winter wrote:

I haven’t seen any fixes yet, but the Round 8 breaks on several 
points on my CI system:


As a side note, I’m a little bit disappointed that all were all 
marked as failed by my CI system, not tested (series of patches are 
sometimes missed as finding complete series isn’t perfect) or never 
submitted to patchwork or the list


so, this is still a WIP. I'm in the final stages of getting as many 
outstnading patches lined up as possible. Also, this is the 
'proposed/ff' head - not a tentative 'accepted' head.


I was aware from patchwork some of those patches have CI fails, also 
some have comments on issues. This pass is just to get them queued in 
some way. After which, I was intending to re-scan the comments as part 
of building a summary mail.


Though, still _v useful_ to have them re-checked. Thanks. :)


My bad. I thought that only patches which are in a working stage should 
be selected for proposed branch

(the “proposed” would be for code review, functionality etc).

I’m partially a bit frustrated on the guesswork on automatically 
testing series of patches - which is the

reason why I’m pushing to try the github pull request model for this.
Patchwork has no concept of series of the patches. At this time, I look 
at subject, msg-id and sender
and try to re-assemble the series. But this fails whenever someone 
resubmits just a single replacement v2
patch or doesn’t use “git send-email”. So the larger the patch, 
the more likely my automated system

fails to detect them.

(and if anyone here notices that their series is missing and got no 
automated test report, then feel free

to email me and I’ll manually fix and trigger the series)

Also, if you ever want to find the CI result for a specific Patchwork, 
then just go to

https://ci1.netdef.org/browse/label/patchwork_id={patchID}

Ie https://ci1.netdef.org/browse/label/patchwork_id=2006
for patchwork 2006

Doesn’t matter if it’s part of a series or not - it should get you 
directly to the test run(s) for

that specific patch.


1) DejaGNU testcli:


 […]
 Running ./libzebra.tests/testcli.exp ...
 FAIL: testcli
 […]


—>  —> The offending commit for this is 0dbe0d2 (“lib: 
Consolidate VIEW_NODE to be ENABLE_NODE as well”)

This is Patchwork #1856
Originally failed CI test: 
https://ci1.netdef.org/browse/QUAGGA-QPWORK-251


2) DejaGNU testbgpmpattr IPv6-default: IPV6 MP Reach, global nexthop, 
2 NLRIs + default -- testbgpmpattr  aborted!


Aha, will look.


Would be good to remind everyone that it IS (or should be) a requirement 
for
acceptance that it passes “make check” at the time of a patch 
submission.



 […]
 Running ./bgpd.tests/testbgpmpath.exp ...
 Running ./bgpd.tests/testbgpmpattr.exp ...
 failed: testbgpmpattr IPv6-default: IPV6 MP Reach, global nexthop, 
2 NLRIs

 + default -- testbgpmpattr  aborted!
 […]


—>  —> The offending commit for this is 82655af (“bgpd, zebra: 
Use next hop tracking for connected routes too”)

This is Patchwork #1640
Was never tested by my CI system (it is part of a series of 89 
patches which is a challenge for the automated

patchwork testing setup on my CI system)

3) missing htonf on OpenBSD / NetBSD 6/7 / FreeBSD 8/9/10 / OmniOS:


 […]
 make  all-am
   CC   network.lo
 network.c: In function 'htonf':
 network.c:109:2: error: #error "Please supply htonf implementation 
for

 this platform"
  #error "Please supply htonf implementation for this platform"
   ^
 network.c:111:1: warning: control reaches end of non-void function
 [-Wreturn-type]
  }
  ^
 *** Error code 1
 […]


Now that's interesting.

The offending commit for this is f8e536e (“lib: consolidate 
ntohf/htonf from ospfd/isisd TE to lib/network”)


This is was never seen in Patchwork. No idea where this patch came 
from…


That's basically a previous version of something that Olivier then 
incorporated into his LLS train. I went back to the other version, so 
that the attribution to OSR is visible in the commit logs, as well as 
the other credit to Aidan Delaney.


Olivier's recent version in patchwork is:

  http://patchwork.quagga.net/patch/1906/

Not sure where the other version is. I don't see a CI error for the 
BSDs or Solaris. Do they not have __STDC_IEC_559__ ?


Would appreciate if someone can spend a few cycles on fixing this 
BEFORE pushing more commits into this branch as these are multiple 
teststoppers.


Will have a look.

Can you do a grep for STDC_IEC_559 on those test hosts?


Doesn’t exist. I send the complete defines in a separate email to the 
list (for future reference)

These are based on the default C compilers.

Regards,

- Martin Winter

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15708] Multiple Test failures in Round 8 - Anyone working on fixes?

[Martin Winter]

I haven’t seen any fixes yet, but the Round 8 breaks on several points 
on my CI system:


As a side note, I’m a little bit disappointed that all were all marked 
as failed by my CI
system, not tested (series of patches are sometimes missed as finding 
complete series isn’t perfect)

or never submitted to patchwork or the list

We could have all avoided this…



1) DejaGNU testcli:


[…]
Running ./libzebra.tests/testcli.exp ...
FAIL: testcli
[…]


—> The offending commit for this is 0dbe0d2 (“lib: Consolidate 
VIEW_NODE to be ENABLE_NODE as well”)

This is Patchwork #1856
Originally failed CI test: 
https://ci1.netdef.org/browse/QUAGGA-QPWORK-251


2) DejaGNU testbgpmpattr IPv6-default: IPV6 MP Reach, global nexthop, 2 
NLRIs + default -- testbgpmpattr  aborted!



[…]
Running ./bgpd.tests/testbgpmpath.exp ...
Running ./bgpd.tests/testbgpmpattr.exp ...
failed: testbgpmpattr IPv6-default: IPV6 MP Reach, global nexthop, 2 
NLRIs + default -- testbgpmpattr  aborted!

[…]


—> The offending commit for this is 82655af (“bgpd, zebra: Use next 
hop tracking for connected routes too”)

This is Patchwork #1640
Was never tested by my CI system (it is part of a series of 89 patches 
which is a challenge for the automated

patchwork testing setup on my CI system)

3) missing htonf on OpenBSD / NetBSD 6/7 / FreeBSD 8/9/10 / OmniOS:


[…]
make  all-am
  CC   network.lo
network.c: In function 'htonf':
network.c:109:2: error: #error "Please supply htonf implementation for 
this platform"

 #error "Please supply htonf implementation for this platform"
  ^
network.c:111:1: warning: control reaches end of non-void function 
[-Wreturn-type]

 }
 ^
*** Error code 1
[…]


The offending commit for this is f8e536e (“lib: consolidate 
ntohf/htonf from ospfd/isisd TE to lib/network”)
This is was never seen in Patchwork. No idea where this patch came 
from…



4) bootstrap.sh fails on Ubuntu 16.04


./bootstrap.sh
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: 'AC_PROG_RANLIB' is rendered obsolete by 'LT_INIT'
configure.ac:97: error: possibly undefined macro: AC_MSG_RESULT
  If this token and others are legitimate, please use 
m4_pattern_allow.

  See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1


—> The offending commit for this is 09d4631 (“qpb: Add support for 
protobuf”)

(Small note: Running “bootstrap.sh” a 2nd time will work.)
This is Patchwork 1884 which somehow was missed in my CI system as well. 
(My CI
system never detected this as a complete series of patches, so no run 
was triggered)




Would appreciate if someone can spend a few cycles on fixing this BEFORE 
pushing more

commits into this branch as these are multiple teststoppers.

The list is potentially not complete - as the tests fail at various 
stages on all platforms

based on these problems. There could be more issues later on…

- Martin Winter

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15667] Re: Call for Agenda

[Martin Winter]

A little bit late, but I had a long call with Vincent today (his late
monday evening).

He has some different suggestion which I wrote down in a new document as
an alternative choice. (Unfortunately, he can’t attend the call)

Description is here:
https://docs.google.com/document/d/1A0kr7PrlsXs7Xe4btAgVWolvXYF5-JjtSWTOQypGRSs/edit?usp=sharing

Key changes:
- Maintainers are reduced to git committers and can’t make the 
ACK/NACK

  decision.
- Anyone in community can ACK/NACK a patch.
- No ACK: does not go in at all
- Can’t agree: will get pushed to Steering committee for decision
- Dispute resolution is done by a Steering committee which is elected

I hope I got all the details correctly written down in the spirit of how
Vincent explained it to me.

- Martin

Disclaimer: I’m only the person who wrote it down. This does not mean 
that
I agree or disagree on it. But I want this choice to be discussed as 
well.



On 18 Jun 2016, at 14:23, Lou Berger wrote:


On 6/14/2016 12:55 PM, Donald Sharp wrote:
Next Tuesday we have the normal monthly meeting.  If you have 
anything

that you would like to discuss please let me know so I can add it to
the agenda.

I'd like to discuss and vote on the 3 documents:

Maintainer:

https://docs.google.com/document/d/19DZcT0cJUSYxVIFenHvGFhLLUmLTRFHuMNZcI7aUNGA/edit?usp=sharing


I made a few minor changes and comments. The most substantive change I
made was to clarify that missing e-mail votes are the ones that count,
and that it's 3 out of 6 votes is needed to be inactive (3 in a row, 3
out of 4, 3 out of 5, and 3 out of 6 all = inactive).

  It looks good to me (either with or without the changes). I vote yes
(as contributor).


Tools:

https://docs.google.com/document/d/1s_EbbXwqWPmfOg6ArgKmEMm_iv0vwGvJs-7ZG4yFKb4/edit?usp=sharing


I think the document combines a few things together in a few places,
e.g., submission within the code review section.  I suggested some
changes to address this.  I think the topic of submissions via pull
requests is also missing.  From my contributor perspective, I prefer
pull requests makes the most sense, but given where the project is
"vote" for both email patches and pull requests.  Having pull requests
only be mandatory for patch sets seems like a reasonable transition
approach...

This too looks good to me (either with or without the changes). I vote
yes (as contributor).


Quagga Process:

https://docs.google.com/document/d/1xYrpTKYDvK23BCxXP-dbE6nOuvBxbGIilNLfVkI3j-I/edit?usp=sharing


I support this new process.  I tweaked the language related to
confirming meeting decisions on the e-mail list. The main point of the
change is that split decisions (those that are not unanimous across 
all
maintainers)  need to be confirmed on the list and and all decisions 
are

announced on the list.

I'm particularity interested in (and see this as the most important 
part

of the overall discussion):
(a) having an active master branch that reflects the current/living
state of ACK'ed patches
(b) having a predictable release cycle

Lou

PS I'm unlikely to be on the whole call on Tuesday due to an 
unavoidable

conflict -- but I hope the above unambiguously provides my position.


Please take the time to read/discuss.

thanks!

donald


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev




___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15575] Comments on Tools and Maintainer Doc please! (Was Re: Call for Agenda)

[Martin Winter]

I would appreciate if everyone takes some time to read through the 
documents

and adds their comment.

I’ve added a table at the bottom of the tools document for everyone to 
list their
preferences. There are many choices and I think it would be great for 
everyone to

list what they prefer so we can speed up the discussion and voting.

I’ve also fixed the permission on the Maintainer doc. I’ve noticed 
that it was
accidentally set to view only. This is now changed to allow everyone to 
comment

and edit it.

- Martin

On 14 Jun 2016, at 9:55, Donald Sharp wrote:

Next Tuesday we have the normal monthly meeting.  If you have anything 
that
you would like to discuss please let me know so I can add it to the 
agenda.


I'd like to discuss and vote on the 3 documents:

Maintainer:

https://docs.google.com/document/d/19DZcT0cJUSYxVIFenHvGFhLLUmLTRFHuMNZcI7aUNGA/edit?usp=sharing

Tools:

https://docs.google.com/document/d/1s_EbbXwqWPmfOg6ArgKmEMm_iv0vwGvJs-7ZG4yFKb4/edit?usp=sharing

Quagga Process:

https://docs.google.com/document/d/1xYrpTKYDvK23BCxXP-dbE6nOuvBxbGIilNLfVkI3j-I/edit?usp=sharing

Please take the time to read/discuss.

thanks!

donald
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15513] Re: round 7, can you test?

[Martin Winter]

Round-7 is fine on my compliance tests. Only change are a few ISIS tests 
which are now passing,

no new failures visible.

All good from my side to merge this into Master.

- Martin


On 6 Jun 2016, at 12:14, Martin Winter wrote:


It’s already tested. At least the basic run.

https://ci1.netdef.org/chain/viewChain.action?planKey=QUAGGA-QMASTER9

(Part of the “Master” Plan - just select the branch on top to see 
different branches. My CI system should automatically pick up any 
proposed/* branches)


I’ll start a full pass of the compliance tests (takes 2 days max)

- Martin

On 6 Jun 2016, at 8:29, Paul Jakma wrote:


Hi,

Not sure why it's been sitting there untouched for so long, but could 
you do some of your smoke-tests on r7? So we can get it into master?


As it was apparently a limited bugfix-only round, it perhaps needs 
only a basic run.


regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
The world is coming to an end.  Please log off.


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15498] Re: Quagga Release Process Meeting Notes

[Martin Winter]

The Tools doc is set to “View” only. Please someone change to allow 
access for

(at least) comments.

- Martin

On 8 Jun 2016, at 6:02, Donald Sharp wrote:


All -

I'd like to close up feedback on the documents by Monday June 13.  
Please

take a few minutes to read the documents and provide some feedback.

thanks!

donald

On Mon, Jun 6, 2016 at 3:09 PM, Donald Sharp 


wrote:


Tools Document:


https://docs.google.com/document/d/1s_EbbXwqWPmfOg6ArgKmEMm_iv0vwGvJs-7ZG4yFKb4/edit?usp=sharing

Maintainer Document:


https://docs.google.com/document/d/19DZcT0cJUSYxVIFenHvGFhLLUmLTRFHuMNZcI7aUNGA/edit?usp=sharing

If you have feedback, please take the time to edit the documents.

thanks!

donald

On Thu, Jun 2, 2016 at 12:43 PM, Donald Sharp 


wrote:


Document is here:


https://docs.google.com/document/d/1xYrpTKYDvK23BCxXP-dbE6nOuvBxbGIilNLfVkI3j-I/edit

Meeting Notes:

Section 2:
  n == 6 months, let's start w/ 6 and adjust later

Discussion around YE and what it should be named.

Are YE and CE released at the same time?  The are released at 
separate

times.

Can we make the first release sooner than 6 months from now?  TBD, 
but

interest from multiple parties in doing so.

Section 3:

Martin - Pull requests for github should be handled this week.

How do the releases relate to each other?  Not sure if it is a 
problem.

Keep numbering disconnected since we don't currently have CE and YE
connected?

Section 4 and 9 - To be made into it's own document.  Olivier to 
head up

writing this document.

Section 5:

CE and YE maintainers separate?  No!

Need a set of Maintainers more than 3 that is 'reasonable'.  
Maintainer
Document under separate process, Martin taking lead on this 
document.


Maintainers have the vote, simple majority.  They have a week after
meeting to voice their opinion.  Meeting notes or recording must be 
made

available.

Section 6:

May need to be refined in the future.

Donald, Jafar, Martin, Olivier and Balaji recommend to move forward 
with

this document.

Lou can you express your opinion about moving forward since you had 
to

drop off a bit early?

Would anyone else like to express their opinion about moving 
forward?

I'd like to finish up this discussion by next Thursday the 9th.

thanks!

donald






___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15496] Re: Round 8

[Martin Winter]

On 8 Jun 2016, at 7:13, Paul Jakma wrote:


On Wed, 8 Jun 2016, Martin Winter wrote:

So even in a set of 4 patches, I would test patch 1, patch 1+2, patch 
1+2+3 and finally patch 1+2+3+4 ?



Or test each on it’s own?


The former would be enough I think. The latter would discourage 
breaking up patches into easier to review 'stories'.


If you want me to try this, then suggest something (i.e. name of 
accumulating branch?) and I can give it a try.


'proposed'?


Do you suggest the current proposed or a special proposed branch for the 
CI system?


If we decide with the “proposed” tree workflow, then I’m not sure 
if this should be a different branch

and let some maintainer cherry-pick commits into the current proposed.

Having a dedicated branch for this would also be preferred for me as 
less risky in case my

scripts screw up :-)  (at least for a trial phase)

- Martin



regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
It's amazing how much better you feel once you've given up hope.


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15495] Re: Round 8

[Martin Winter]

On 8 Jun 2016, at 8:10, Jafar Al-Gharaibeh wrote:

On 6/8/2016 9:13 AM, Paul Jakma wrote:

On Wed, 8 Jun 2016, Martin Winter wrote:

So even in a set of 4 patches, I would test patch 1, patch 1+2, 
patch 1+2+3 and finally patch 1+2+3+4 ?



Or test each on it’s own?


The former would be enough I think. The latter would discourage 
breaking up patches into easier to review 'stories'.


I agree. In most cases there will be dependency between a series of 
patches where each one may depend on previous patches in the series. 
This would leave the developer no choice but to lump the whole thing 
together as Paul pointed out.


Ok, if everyone agrees, I can just modify my CI system to automatically 
break the a series in these steps
and run them this way (and have an email reply sent for each of these 
combination, so a reply to 1/4 with
result of just patch 1, a reply to 2/4 with result of 1+2, reply to 3/4 
with 1+2+3 and reply to 4/4 with

result of the whole series.

Or is this borderline to spamming? (i.e. if someone sends a series of 
40, then there will be 40 replies)


Agreements? Or better suggestions?

Also, if we decide for me to automatically commit it to some 
“proposed” (or whatever the name is)

branch, then I would only commit it there if every test is successful?

- Martin

If you want me to try this, then suggest something (i.e. name of 
accumulating branch?) and I can give it a try.


'proposed'?

regards,


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15485] Re: Round 8

[Martin Winter]

On 7 Jun 2016, at 3:24, Paul Jakma wrote:


Hi,

On Mon, 6 Jun 2016, Martin Winter wrote:


Paul,

from the testing side, I would appreciate if you could submit them in 
multiple patches into the next proposed branch. I worry a long git 
bisect nightmare to find the bad commits. (also, not sure if you 
checked if each patch was successful on it’s own on my CI system).


I did look at the CI results, where they were attached to the 
patchwork issue. I also did my own 'git rebase -i --exec make' test.


Some series of patches contain commits that need later commits to 
compile. When the series are marked as such in the emails (as git 
send-email tries to), i.e. "[patch X/Y]", the CI system seems to test 
them as a unit.


However, that gets lost once applied to git.

So, as things stand, you're going to end up with a linearised 
'proposed for merging to master' tree (need to find quick terms to 
distinguish between the 'proposed contribution' stage and the later 
'linearised, reviewed and now proposed for merging' stage ;) ) that 
will contain commits that don't compile.


If it's easy I try fix such commits. E.g., MTYPEs that are added in a 
later commit I might manually move to the first one that uses it. But 
that's not always possible.


In the future, we could get super-strict about each commit compiling - 
you should change your CI to enforce that in that case!


So even in a set of 4 patches, I would test patch 1, patch 1+2, patch 
1+2+3 and finally patch 1+2+3+4 ?


Or test each on it’s own?

My preferred way to work through this would be to submit one set 
(from one committer) into a proposed branch, then wait until the CI 
system gives the OK (or if not then get them fixed), then push the 
next set etc.. (I assume that most/all of these patches are not 
disputed from the functionality and the further review is based 
mostly on the implementation)


What would be cool would to have a system that auto-applied 
contributions to a git branch based off the last master, and made that 
available to others. And then maybe replied to the email so it'd show 
up in patchwork.


I can think of two things that'd be useful:

- a branch of just the contribution on master

- an accumulating branch, so that the latest submission to the list is
  applied to the previous submission on the list

That might help automate a lot of what at present is tedious manual 
work. And... it seems you already have a lot of the scripts to do it? 
:)


Both should be easy. I don’t see much use for the first one in case of 
patches which are just a single commit (and if there are multiple parts, 
then I would argue that we should rather commit the series independent 
of some proposed branch on approval directly to master (or whatever the 
working branch is).
For the 2nd choice, this would only be added to the accumulating branch 
on successful pass of the tests.


If you want me to try this, then suggest something (i.e. name of 
accumulating branch?) and I can give it a try.


- Martin Winter


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15465] Re: CI Testresult: FAILED (Re: [quagga-dev, 15452, 3/3] pimd: Remove igmp_add_group_by_addr unneeded parameter)

[Martin Winter]

On 6 Jun 2016, at 18:45, Donald Sharp wrote:


Martin -

Looks like something went wrong with your test system?


Yes. Added some patches and it seems it didn’t come back up all 
correct.


Ignore it - I’ll rerun in a few minutes and will trigger a new email 
at the end.


- Martin



donald

On Mon, Jun 6, 2016 at 9:40 PM, <cisys...@netdef.org> wrote:


Continous Integration Result: FAILED

See below for issues.
This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter <mwin...@opensourcerouting.org>.

Patches applied :
  Patchwork 1961: http://patchwork.quagga.net/patch/1961
   [quagga-dev,15450,1/3] pimd: Remove dead code.
  Patchwork 1962: http://patchwork.quagga.net/patch/1962
   [quagga-dev,15451,2/3] pimd: Remove source_new unneeded 
parameter

  Patchwork 1963: http://patchwork.quagga.net/patch/1963
   [quagga-dev,15452,3/3] pimd: Remove igmp_add_group_by_addr 
unneeded

parameter
Tested on top of Git : 86c5d2e (as of 20160315.231717 UTC)
CI System Testrun URL: 
https://ci1.netdef.org/browse/QUAGGA-QPWORK-302/



Get source and apply patch from patchwork: Successful


Building Stage: Successful


Basic Tests: Failed

Static analyzer (clang): Successful


Regards,
  NetDEF/OpenSourceRouting Continous Integration (CI) System

---
OpenSourceRouting.org is a project of the Network Device Education
Foundation,
For more information, see www.netdef.org and 
www.opensourcerouting.org

For questions in regards to this CI System, contact Martin Winter,
mwin...@netdef.org



___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15438] Re: round 7, can you test?

[Martin Winter]

It’s already tested. At least the basic run.

https://ci1.netdef.org/chain/viewChain.action?planKey=QUAGGA-QMASTER9

(Part of the “Master” Plan - just select the branch on top to see 
different branches. My CI system should automatically pick up any 
proposed/* branches)


I’ll start a full pass of the compliance tests (takes 2 days max)

- Martin

On 6 Jun 2016, at 8:29, Paul Jakma wrote:


Hi,

Not sure why it's been sitting there untouched for so long, but could 
you do some of your smoke-tests on r7? So we can get it into master?


As it was apparently a limited bugfix-only round, it perhaps needs 
only a basic run.


regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
The world is coming to an end.  Please log off.


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15378] Re: quagga-1.0.20160315 bgp crash bgp_packet.c

[Martin Winter]

Richard,

I don’t think this is anything known.
Unless someone else here knows something obvious, I would appreciate if 
you could
send me a pcap of the bgp traffic. This should allow me to reproduce and 
narrow down

the problem.

Feel free to email it to me directly.

Regards,
   Martin Winter


On 24 May 2016, at 16:14, Richard Savage wrote:


Hi

Using FreeBSD 10.3 and quagga version 1.0.20160315

There seems to be a bug on loading prefixes from other neighbors and  
bgp will crash at the same point everytime:


BGP: Received signal 10 at 1464125380 (si_addr 0x80143aa62); 
aborting...

Backtrace for 5 stack frames:
0x80091465d <zlog_backtrace_sigsafe+0x3d> at 
/usr/local/lib/libzebra.so.0

0x800913dc5 <zlog_signal+0x515> at /usr/local/lib/libzebra.so.0
0x80091f7a8 <signal_init+0x308> at /usr/local/lib/libzebra.so.0
0x801b71b37 <pthread_sigmask+0x507> at /lib/libthr.so.3
0x801b7122c <pthread_getspecific+0xe1c> at /lib/libthr.so.3
in thread bgp_read scheduled from bgp_packet.c:2472

There are also a lot of messages in the logs regarding the following:

2016/05/24 22:29:40 BGP: unknown afi/safi (0/0)
2016/05/24 22:29:40 BGP: xxx.xxx.xxx.xxx[Info] UPDATE with unsupported 
AFI/SAFI 0/0


Has the above crash been looked at as a bug and is there a new release 
due soon that might fix this?


Many thanks

Richard
This e-mail is sent on behalf of Timico Partner Services Limited, a 
company registered in England and Wales, registered number 03128506, 
registered office Beacon Hill Park, Newark, Nottinghamshire, NG24 2TN 
and regulated by Ofcom. The information in this e-mail is confidential 
and is intended solely for the use of that individual or entity to 
which it is addressed. Unauthorised use, dissemination, distribution, 
publication or copying of this communication is strictly prohibited. 
If you receive this in error, please notify us by email to 
priv...@timico.co.uk<mailto:priv...@timico.co.uk> and delete any 
copies. For information about how we process data and monitor 
communications please see our privacy 
statement<http://www.timico.co.uk/downloads/terms/Privacy_Statement.pdf>.

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15348] Re: Patch Submittal Process Going Forward Discussion.

[Martin Winter]

On 20 May 2016, at 2:38, Paul Jakma wrote:
[…]

- "resolve issues at a faster rate", by which you really mean "Ignore
  having to address the former".

On unanimity, I disagree with you. If we regularly have patches being 
pushed through by the vote of the 51+% of contributors over objections 
of others, we're going to run into really deep problems working 
togehter.


We'd be much better working hard at engaging and trying to keep each 
other happy, than trying to come up with simple majority voting 
structures.


Also, there can be some issues I simply am not prepared to devolve to 
simple majority votes. There are some things that are red-lines for 
me. I can well accept that others have red-lines too, and in general 
try to respect that (do you know how many patches I never got in? :) 
). Unanimous agreement on inclusion (or rollback to a last 'good' 
state in some edge cases) is the only way to accommodate that.


Can you clarify?
Is the “simple majority” the issue for these “some issues” and 
it could be solved for these issues with a super majority (i.e. 67%)

or do you need/want unanimous agreement on these?
If you think it needs a “unanimous agreement”, then could you come 
up with an example of an issue where you see the need for?


- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15335] Re: Patch Submittal Process Going Forward Discussion.

[Martin Winter]

On 19 May 2016, at 8:51, Olivier Dugeon wrote:


Hello Donald, all

I globally agree on the proposal, but have some questions. See Below.

BTW, I will attend next quagga meeting

Regards,

Olivier

Le 19/05/2016 13:47, Donald Sharp a écrit :


Adjusted proposal based upon feedback.

-

Golden Rule applies to everything we do.

A person who Submit’s code cannot be the person who commits it into 
quagga.  Assume that this can be worked out amongst the maintainers.


Anyone can ACK/NACK code by sending mail to the submitter and the 
quagga-dev alias substantiating the basis for dissent.


Proposal for going forward:

 1. Patch Submitted
 1. Automatic testing is being applied to incoming patches on 
quagga-dev.  If testing indicates a failure then the patch must be 
fixed and resubmitted.


Does this automatic testing include protocol conformity or just 
applying patch and try to compile ? In case it includes  conformity, 
what's happen with future / innovative .. features ? I means 
implementing extensions that are not yet RFC e.g. Segment Routing. How 
to be sure that the testing will not report false failures just 
because the code is freshen regarding the testing tool.


In my earlier response (which I believe was the base for this), I’ve 
added an exception rule for cases when it’s believed that the test 
itself is broken/bad or something changes on purpose. But it would have 
to be a clearly stated intent. I think for the case of simplicity, 
Donald left this out and just assumed a common sense by maintainer to 
overrule this rule if needed.


However, specially for new features which may not even be covered by 
existing tests, I would expect submitter to give some description on
his own testing - or find someone else who is able to test it before it 
goes in. But again, I think common sense and doesn’t need to be

spelled out.

 1. If Acked goes in immediately to a development branch, by current 
maintainer.


Is the submitter got write access on this development branch to rebase 
/ update /modify / ... its code easily before it will be merge into 
the master ?


Can you explain a bit more?
My understanding is that it should be done/ready reviewed and agreed 
when it gets accepted into the development branch. Update/Modify later 
would be a new patch started at step 1.


 1. If no-one says anything after 2 weeks, code get’s put into a 
development branch by one of the current maintainers.
 2. If Nacked, dissenter and submitter must publicly work the issue 
out on the quagga-dev alias, and going back to step 1 after working 
issue out.
 3. If after 2 weeks, from Submittal, dissenter and submitter cannot 
figure the problem out either Dissenter or Submitter can ask for 
agenda item to be added to next monthly meeting.  If disagreement is 
large enough a special meeting can be asked for as well.


Same question as Lou. When, who and how we decide that the development 
branch is merge into the master ?


I’ve asked for this as well. Donald decided to leave this open to give 
maintainers a flexible way.
Personally, I don’t see a clear timeline required in the rules, but a 
quick rule if a single maintainer
(the one working on this branch) can make this decision on it’s own or 
if it would require more

maintainer/community involvement to make this decision.


When code review take place ?


On the list before it get’s ACKed. An ACK means that you think it’s 
ready to go in.



Format for Resolution during Meeting:

 1. Simple Majority of those attending meeting is required for 
decision.  Decision results can be: Inclusion of the Nak’ed patch, 
further discussion( step #4 above ), or exclusion of the patch.



No alternative ? Reworking on the patch for example ?


I would expect this is done with a NACK and explaining what needs to be 
done/changed. Submitter would then resubmit a updated version
(until no more NACKs). The issue is here for NACK’s when there are 
fundamental issues, i.e. should this feature go into Quagga,
should we change the functionality or the Submitter disagrees in some 
other way with the NACK reason and won’t or can’t change it,

but wants the code in anyway.

 1. Scheduling of a special meeting details must be worked out 
publicly on quagga-dev alias.
 2. A Patch cannot be a meeting topic more than 2 times in a 12 month 
period.


Yes and No. Yes as normally the decision solved the problem. And no if 
the decision was to work on the patch before re-submitting it which 
generate more than 2 "Submit/Nack/Discussion/Correction/ReSubmit" 
cycles are needed to achieve an Ack'ed patch ?


I think you misunderstood the process. Normal NACK is just someone 
finding a issue with code and the submitter will just update
and resubmit - and all the ACK/NACK cycle starts again. At least thats 
the way I understand it. No need for a Meeting in this case.


- Martin

On Tue, May 17, 2016 at 11:45 AM, Donald Sharp 

[quagga-dev 15317] Re: Patch Submittal Process Going Forward Discussion.

[Martin Winter]

On 17 May 2016, at 8:45, Donald Sharp wrote:


Golden Rule applies to everything we do.

A person who Submit’s code cannot be the person who commits it into
quagga.  Assume that this can be worked out amongst the maintainers.

A maintainer can Ack or Nack code he plans to commit.


Can only maintainers ACK or NACK in your proposal? Can you clarify the
influence a “normal” community member (i.e. anyone on quagga-dev) 
should

have?


Proposal for going forward:

   1. Patch Submitted


 1b.	Patch needs to be tested. If tests fail, then it’s back to 
submitter

 to update. Basically test fails -> reject
 (Excluding case where it’s assume the test itself is believed to be
 broken or there is a good reason why the patch should break the 
tests)



   2. If Acked goes in immediately to a development branch, by current
   maintainer.
   3. If no-one says anything after 2 weeks, immediately get’s put 
into a

   development branch by current maintainer.
   4. If Nacked, dissenter and submitter must publicly work the issue 
out,

   and going back to step 1 after working issue out.
   5. If after 2 weeks, from Submittal, dissenter and submitter cannot
   figure the problem out either Dissenter or Submitter can ask for 
agenda
   item to be added to next monthly meeting.  If disagreement is large 
enough

   a special meeting can be asked for as well.


Would appreciate some thoughts/discussion on when the “development 
branch”

from a maintainer goes into the shared (master?) branch. Should this be
up to the individual maintainer to decide?

- Martin



Format for Resolution during Meeting:



   1. Discussion on alias( See #4 ) must be sufficient for Meeting to
   resolve the issue.  Meeting attendees are within their rights to 
say we

   can’t make a decision from fact’s presented at the meeting.
   2. Simple Majority of those attending meeting is required for 
decision.
   If you can’t be bothered to attend then the decision wasn’t 
important to

   you.
   3. Scheduling of a special meeting details must be worked out 
publicly

   on quagga-dev alias.


Please discuss this on alias, and we'll finalize in a meeting for 11 
am EDT
next tuesday.  If you are interested in attending please let me know.  
I'm

auto inviting everyone currently on the quagga-dev monthly meeting.

donald
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15276] Re: Unable to clone quagga repo

[Martin Winter]

I’ve added another pull request to show an example of a failed run 
first

with another commit added which fixes it.

https://github.com/opensourcerouting/quagga/pull/6

This pull request is against proposed/7 and not master.
In general it doesn’t matter against which branch the request is. 
Should work

for all of them

- Martin

On 16 May 2016, at 20:53, Martin Winter wrote:


On 16 May 2016, at 15:16, Lou Berger wrote:


very cool!  I just tried it for a patch I'm about to submit (probably
tomorrow AM, as have to get something else out now.)

https://github.com/opensourcerouting/quagga/pull/5

Thanks!
Lou

PS How do I see/check CI progress?


The CI system tags the code with pass/fail and posts a response with
a more detailed information and a link to the webpage of the run on 
the CI system.

This is after it’s done.

While it’s running, you should see a “Not all checks finished” 
message

on the pull request with a small link to CI system.

- Martin



On 5/16/2016 5:20 PM, Martin Winter wrote:

On 16 May 2016, at 8:41, Jafar Al-Gharaibeh wrote:


On 5/15/2016 7:40 AM, Lou Berger wrote:
That would work for me. Should be pretty simple to regularly 
mirror.

We could even go crazy and make it a bidirectional mirror to
start

  Why not bring this up in the meeting tomorrow :) ... I like the 
idea

of a github repo as well.

As a side note: Just got our CI Integration with Github done.

If you do a pull request against opensourcerouting/quagga (any 
branch -

master and all the proposed are synced),
then this will trigger a CI run with status update and test report
attached back to PR as comment.

Should give you an easy way to test a branch (and update the pull
request as needed)

Obviously, no merge possible as this is a one-way mirror. So can’t
accept the pull request at the end.

- Martin Winter

PS: Bug reports & Improvement requests are welcome



On May 15, 2016 8:34:28 AM Balaji Gurudoss <balaji...@gmail.com>
wrote:


Yes that would be very handy. I feel we could have the repo in
github itself and probably have Savannah as backup

Thanks
Balaji

On May 15, 2016 18:01, "Lou Berger" <lber...@labn.net
<mailto:lber...@labn.net>> wrote:

Having this on github would facilitate certain tasks, e.g. 
forks

and pull requests - said by someone in the process of putting
together a rather large patch...

Ps still think there needs to be a non-gitub based backup in
case
someone decides to start charging for opensource repos...

On May 15, 2016 7:45:45 AM Balaji Gurudoss 
<balaji...@gmail.com

<mailto:balaji...@gmail.com>> wrote:


Thanks Martin for the information and the links.

 - Balaji

On Sun, May 15, 2016 at 5:03 PM, Martin Winter
<mwin...@opensourcerouting.org
<mailto:mwin...@opensourcerouting.org>> wrote:

On 15 May 2016, at 1:49, Balaji Gurudoss wrote:

Hi

I get the following error when i do a git clone. Any
one
else facing this
issue ?

git clone git://git.savannah.nongnu.org/quagga.git
<http://git.savannah.nongnu.org/quagga.git>
Cloning into 'quagga'...
fatal: read error: Connection reset by peer


Yes, seems to be some issue with Savannah for the past
approx 2 days where access is spotty.

If you can’t wait, then use our mirrors.
We run a public mirror for Quagga (exact mirrors - 
update

hourly if Savannah is up)

Web Access at
US:

https://git-us.netdef.org/projects/QUAGGA/repos/quagga-savannah-official/browse
Germany:

https://git-de.netdef.org/projects/QUAGGA/repos/quagga-savannah-official/browse

Git clone URLs:
US:

https://git-us.netdef.org/scm/quagga/quagga-savannah-official.git
Germany:

https://git-us.netdef.org/scm/quagga/quagga-savannah-official.git

- Martin Winter
  OpenSourceRouting / NetDEF


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
<mailto:Quagga-dev%40lists.quagga.net>
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15275] Re: Unable to clone quagga repo

[Martin Winter]

On 16 May 2016, at 15:16, Lou Berger wrote:


very cool!  I just tried it for a patch I'm about to submit (probably
tomorrow AM, as have to get something else out now.)

https://github.com/opensourcerouting/quagga/pull/5

Thanks!
Lou

PS How do I see/check CI progress?


The CI system tags the code with pass/fail and posts a response with
a more detailed information and a link to the webpage of the run on the 
CI system.

This is after it’s done.

While it’s running, you should see a “Not all checks finished” 
message

on the pull request with a small link to CI system.

- Martin



On 5/16/2016 5:20 PM, Martin Winter wrote:

On 16 May 2016, at 8:41, Jafar Al-Gharaibeh wrote:


On 5/15/2016 7:40 AM, Lou Berger wrote:
That would work for me. Should be pretty simple to regularly 
mirror.

We could even go crazy and make it a bidirectional mirror to
start

  Why not bring this up in the meeting tomorrow :) ... I like the 
idea

of a github repo as well.

As a side note: Just got our CI Integration with Github done.

If you do a pull request against opensourcerouting/quagga (any branch 
-

master and all the proposed are synced),
then this will trigger a CI run with status update and test report
attached back to PR as comment.

Should give you an easy way to test a branch (and update the pull
request as needed)

Obviously, no merge possible as this is a one-way mirror. So can’t
accept the pull request at the end.

- Martin Winter

PS: Bug reports & Improvement requests are welcome



On May 15, 2016 8:34:28 AM Balaji Gurudoss <balaji...@gmail.com>
wrote:


Yes that would be very handy. I feel we could have the repo in
github itself and probably have Savannah as backup

Thanks
Balaji

On May 15, 2016 18:01, "Lou Berger" <lber...@labn.net
<mailto:lber...@labn.net>> wrote:

Having this on github would facilitate certain tasks, e.g. 
forks

and pull requests - said by someone in the process of putting
together a rather large patch...

Ps still think there needs to be a non-gitub based backup in
case
someone decides to start charging for opensource repos...

On May 15, 2016 7:45:45 AM Balaji Gurudoss 
<balaji...@gmail.com

<mailto:balaji...@gmail.com>> wrote:


Thanks Martin for the information and the links.

 - Balaji

On Sun, May 15, 2016 at 5:03 PM, Martin Winter
<mwin...@opensourcerouting.org
<mailto:mwin...@opensourcerouting.org>> wrote:

On 15 May 2016, at 1:49, Balaji Gurudoss wrote:

Hi

I get the following error when i do a git clone. Any
one
else facing this
issue ?

git clone git://git.savannah.nongnu.org/quagga.git
<http://git.savannah.nongnu.org/quagga.git>
Cloning into 'quagga'...
fatal: read error: Connection reset by peer


Yes, seems to be some issue with Savannah for the past
approx 2 days where access is spotty.

If you can’t wait, then use our mirrors.
We run a public mirror for Quagga (exact mirrors - update
hourly if Savannah is up)

Web Access at
US:

https://git-us.netdef.org/projects/QUAGGA/repos/quagga-savannah-official/browse
Germany:

https://git-de.netdef.org/projects/QUAGGA/repos/quagga-savannah-official/browse

Git clone URLs:
US:

https://git-us.netdef.org/scm/quagga/quagga-savannah-official.git
Germany:

https://git-us.netdef.org/scm/quagga/quagga-savannah-official.git

- Martin Winter
  OpenSourceRouting / NetDEF


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
<mailto:Quagga-dev%40lists.quagga.net>
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15273] Re: Unable to clone quagga repo

[Martin Winter]

On 16 May 2016, at 8:41, Jafar Al-Gharaibeh wrote:


On 5/15/2016 7:40 AM, Lou Berger wrote:


That would work for me. Should be pretty simple to regularly mirror. 
We could even go crazy and make it a bidirectional mirror to 
start




  Why not bring this up in the meeting tomorrow :) ... I like the idea 
of a github repo as well.


As a side note: Just got our CI Integration with Github done.

If you do a pull request against opensourcerouting/quagga (any branch - 
master and all the proposed are synced),
then this will trigger a CI run with status update and test report 
attached back to PR as comment.


Should give you an easy way to test a branch (and update the pull 
request as needed)


Obviously, no merge possible as this is a one-way mirror. So can’t 
accept the pull request at the end.


- Martin Winter

PS: Bug reports & Improvement requests are welcome


On May 15, 2016 8:34:28 AM Balaji Gurudoss <balaji...@gmail.com> 
wrote:


Yes that would be very handy. I feel we could have the repo in 
github itself and probably have Savannah as backup


Thanks
Balaji

On May 15, 2016 18:01, "Lou Berger" <lber...@labn.net 
<mailto:lber...@labn.net>> wrote:


Having this on github would facilitate certain tasks, e.g. forks
and pull requests - said by someone in the process of putting
together a rather large patch...

Ps still think there needs to be a non-gitub based backup in 
case

someone decides to start charging for opensource repos...

On May 15, 2016 7:45:45 AM Balaji Gurudoss <balaji...@gmail.com
<mailto:balaji...@gmail.com>> wrote:


Thanks Martin for the information and the links.

 - Balaji

On Sun, May 15, 2016 at 5:03 PM, Martin Winter
<mwin...@opensourcerouting.org
<mailto:mwin...@opensourcerouting.org>> wrote:

On 15 May 2016, at 1:49, Balaji Gurudoss wrote:

Hi

I get the following error when i do a git clone. Any 
one

else facing this
issue ?

git clone git://git.savannah.nongnu.org/quagga.git
<http://git.savannah.nongnu.org/quagga.git>
Cloning into 'quagga'...
fatal: read error: Connection reset by peer


Yes, seems to be some issue with Savannah for the past
approx 2 days where access is spotty.

If you can’t wait, then use our mirrors.
We run a public mirror for Quagga (exact mirrors - update
hourly if Savannah is up)

Web Access at
US:
   
https://git-us.netdef.org/projects/QUAGGA/repos/quagga-savannah-official/browse

Germany:
   
https://git-de.netdef.org/projects/QUAGGA/repos/quagga-savannah-official/browse


Git clone URLs:
US:
   
https://git-us.netdef.org/scm/quagga/quagga-savannah-official.git

Germany:
   
https://git-us.netdef.org/scm/quagga/quagga-savannah-official.git


- Martin Winter
  OpenSourceRouting / NetDEF


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net 
<mailto:Quagga-dev%40lists.quagga.net>

https://lists.quagga.net/mailman/listinfo/quagga-dev





___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15268] Re: Unable to clone quagga repo

[Martin Winter]

On 15 May 2016, at 5:34, Balaji Gurudoss wrote:


Yes that would be very handy. I feel we could have the repo in github
itself and probably have Savannah as backup


Feel free to use our mirrors as well. I’ve started them after some 
other projects

started to disappear or become unreliable.

Most of them (the ones in mirror section) are exact read-only mirrors on 
purpose.


We do two-way mirroring on some git’s (i.e. our own) between the 2 
mirrors

and I do a selective mirror between the main quagga and our quagga on
github [opensourcerouting/quagga] (Selective as exact read-only mirrors
of master and proposed branches, but allowing additional github only
branches which are not mirrored)

- Martin



On May 15, 2016 18:01, "Lou Berger" <lber...@labn.net> wrote:

Having this on github would facilitate certain tasks, e.g. forks and 
pull
requests - said by someone in the process of putting together a 
rather

large patch...

Ps still think there needs to be a non-gitub based backup in case 
someone

decides to start charging for opensource repos...

On May 15, 2016 7:45:45 AM Balaji Gurudoss <balaji...@gmail.com> 
wrote:



Thanks Martin for the information and the links.

 - Balaji

On Sun, May 15, 2016 at 5:03 PM, Martin Winter <
mwin...@opensourcerouting.org> wrote:


On 15 May 2016, at 1:49, Balaji Gurudoss wrote:

Hi


I get the following error when i do a git clone. Any one else 
facing

this
issue ?

git clone git://git.savannah.nongnu.org/quagga.git
Cloning into 'quagga'...
fatal: read error: Connection reset by peer



Yes, seems to be some issue with Savannah for the past approx 2 
days

where access is spotty.

If you can’t wait, then use our mirrors.
We run a public mirror for Quagga (exact mirrors - update hourly if
Savannah is up)

Web Access at
US:
https://git-us.netdef.org/projects/QUAGGA/repos/quagga-savannah-official/browse
Germany:
https://git-de.netdef.org/projects/QUAGGA/repos/quagga-savannah-official/browse

Git clone URLs:
US: 
https://git-us.netdef.org/scm/quagga/quagga-savannah-official.git

Germany:
https://git-us.netdef.org/scm/quagga/quagga-savannah-official.git

- Martin Winter
  OpenSourceRouting / NetDEF



___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev





___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15261] Re: Unable to clone quagga repo

[Martin Winter]

On 15 May 2016, at 1:49, Balaji Gurudoss wrote:


Hi

I get the following error when i do a git clone. Any one else facing 
this

issue ?

git clone git://git.savannah.nongnu.org/quagga.git
Cloning into 'quagga'...
fatal: read error: Connection reset by peer


Yes, seems to be some issue with Savannah for the past approx 2 days 
where access is spotty.


If you can’t wait, then use our mirrors.
We run a public mirror for Quagga (exact mirrors - update hourly if 
Savannah is up)


Web Access at
US: 
https://git-us.netdef.org/projects/QUAGGA/repos/quagga-savannah-official/browse
Germany:
https://git-de.netdef.org/projects/QUAGGA/repos/quagga-savannah-official/browse

Git clone URLs:
US: https://git-us.netdef.org/scm/quagga/quagga-savannah-official.git
Germany: 
https://git-us.netdef.org/scm/quagga/quagga-savannah-official.git


- Martin Winter
  OpenSourceRouting / NetDEF

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15107] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support

[Martin Winter]

On 20 Apr 2016, at 7:41, Paul Jakma wrote:


On Wed, 20 Apr 2016, Daniel Walton wrote:

If you are not willing to say "ok I disagree with the quagga 
community but I am going to accept this patch anyway" then the 
reality is that it is your word no matter what.


As far as I know, the community also wants significant behaviour 
changes to be handled in a staged way.


The community has a split-brain on that.


I can’t remember this to ever been asked for a bug fix.

It was discussed about changing defaults a few times. And in all cases, 
none of the

choices on defaults violated RFCs.

- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15060] Re: CI Testresult: FAILED (Re: [quagga-dev, 15056] Fix ospfd: use the correct index for pseudo neighbors on p2p/v links)

[Martin Winter]

On 17 Apr 2016, at 13:19, jafar wrote:

I think I'm supposed to resubmit this patch in a new email, right?


Yes, would be preferred.


Is it better to submit patches as attachments, or inline?
BTW. how do we avoid an error like this, that I see often on the list 
but don't know why it happens?


In general it’s your email client screwing with the format of the 
patch.

The suggest rule is to NOT use a traditional email client and use
“git send-email …” instead. This should correctly preserve the 
format.


Regards,

- Martin Winter



On 2016-04-15 18:40, cisys...@netdef.org wrote:

Continous Integration Result: FAILED

See below for issues.
This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter <mwin...@opensourcerouting.org>.

Patches applied :
  Patchwork 1897: http://patchwork.quagga.net/patch/1897
   [quagga-dev,15056] Fix ospfd: use the correct index for pseudo
neighbors on p2p/v links
Tested on top of Git : 86c5d2e (as of 20160315.231717 UTC)
CI System Testrun URL: 
https://ci1.netdef.org/browse/QUAGGA-QPWORK-269/



Get source and apply patch from patchwork: Failed


Applying Patchwork patch 1897

patching file ospfd/ospf_interface.c
patch:  malformed patch at line 57: *ifp, struct prefix *p)


Regards,
  NetDEF/OpenSourceRouting Continous Integration (CI) System

---
OpenSourceRouting.org is a project of the Network Device Education 
Foundation,
For more information, see www.netdef.org and 
www.opensourcerouting.org

For questions in regards to this CI System, contact Martin Winter,
mwin...@netdef.org


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15054] FreeBSD issue: ZEBRA: Kernel: Len: 168 Type: RTM_MISS

[Martin Winter]

Some issue which is a mystery where to even begin troubleshooting:

On FreeBSD 10.2 (Not testing other FreeBSD), I have at least one ISIS 
IPv4 test

sometimes failing by not updating the kernel table.

ISIS log looks fine in all cases.

When I look at Zebra log, I see the following in the failed case:

2016/04/13 01:28:06 ZEBRA: vty[??]@# end
2016/04/13 01:28:06 ZEBRA: vty[??]@# exit
2016/04/13 01:28:06 ZEBRA: vty[??]@> enable
2016/04/13 01:28:06 ZEBRA: vty[??]@# config ter
2016/04/13 01:28:06 ZEBRA: vty[??]@(config)# interface eth2
2016/04/13 01:28:06 ZEBRA: vty[??]@(config-if)# no shutdown
2016/04/13 01:28:06 ZEBRA: vty[??]@(config-if)# end
2016/04/13 01:28:06 ZEBRA: vty[??]@# end
2016/04/13 01:28:06 ZEBRA: vty[??]@# exit
2016/04/13 01:28:06 ZEBRA: vty[??]@> enable
2016/04/13 01:28:06 ZEBRA: vty[??]@# config ter
2016/04/13 01:28:06 ZEBRA: vty[??]@(config)# interface eth3
2016/04/13 01:28:06 ZEBRA: vty[??]@(config-if)# no shutdown
2016/04/13 01:28:06 ZEBRA: vty[??]@(config-if)# end
2016/04/13 01:28:06 ZEBRA: vty[??]@# end
2016/04/13 01:28:06 ZEBRA: vty[??]@# exit
2016/04/13 01:28:23 ZEBRA: Kernel: Len: 168 Type: RTM_MISS
2016/04/13 01:28:23 ZEBRA: Kernel: DONE
2016/04/13 01:28:23 ZEBRA: Kernel: message seq 0
2016/04/13 01:28:23 ZEBRA: Kernel: pid 0, rtm_addrs 0x1
2016/04/13 01:28:23 ZEBRA: Unprocessed RTM_type: 7
2016/04/13 01:28:26 ZEBRA: vty[??]@> enable
2016/04/13 01:28:26 ZEBRA: vty[??]@# end
2016/04/13 01:28:26 ZEBRA: vty[??]@# exit
2016/04/13 01:29:02 ZEBRA: vty[??]@> enable

While a good case looks like this:

2016/04/13 01:28:03 ZEBRA: vty[??]@# end
2016/04/13 01:28:03 ZEBRA: vty[??]@# exit
2016/04/13 01:28:03 ZEBRA: vty[??]@> enable
2016/04/13 01:28:03 ZEBRA: vty[??]@# config ter
2016/04/13 01:28:03 ZEBRA: vty[??]@(config)# interface eth2
2016/04/13 01:28:03 ZEBRA: vty[??]@(config-if)# no shutdown
2016/04/13 01:28:03 ZEBRA: vty[??]@(config-if)# end
2016/04/13 01:28:03 ZEBRA: vty[??]@# end
2016/04/13 01:28:03 ZEBRA: vty[??]@# exit
2016/04/13 01:28:03 ZEBRA: vty[??]@> enable
2016/04/13 01:28:03 ZEBRA: vty[??]@# config ter
2016/04/13 01:28:03 ZEBRA: vty[??]@(config)# interface eth3
2016/04/13 01:28:03 ZEBRA: vty[??]@(config-if)# no shutdown
2016/04/13 01:28:03 ZEBRA: vty[??]@(config-if)# end
2016/04/13 01:28:03 ZEBRA: vty[??]@# end
2016/04/13 01:28:03 ZEBRA: vty[??]@# exit
2016/04/13 01:28:08 ZEBRA: zebra message comes from socket [13]
2016/04/13 01:28:08 ZEBRA: zebra message received [ZEBRA_IPV4_ROUTE_ADD] 
20 in VRF 0
2016/04/13 01:28:08 ZEBRA: rib_link: 172.16.0.0/28 vrf 0: rn 
0x8020ffbf0, rib 0x8020ffb00
2016/04/13 01:28:08 ZEBRA: rib_link: 172.16.0.0/28 vrf 0: adding dest to 
table
2016/04/13 01:28:08 ZEBRA: rib_add_ipv4_multipath: called rib_addnode 
(0x8020ffbf0, 0x8020ffb00) on new RIB entry
2016/04/13 01:28:08 ZEBRA: rib_add_ipv4_multipath: dumping RIB entry 
0x8020ffb00 for 172.16.0.0/28 vrf 0
2016/04/13 01:28:08 ZEBRA: rib_add_ipv4_multipath: refcnt == 0, uptime 
== 1460536088, type == 8, table == 0
2016/04/13 01:28:08 ZEBRA: rib_add_ipv4_multipath: metric == 11, 
distance == 115, flags == 0, status == 0
2016/04/13 01:28:08 ZEBRA: rib_add_ipv4_multipath: nexthop_num == 1, 
nexthop_active_num == 0, nexthop_fib_num == 0
2016/04/13 01:28:08 ZEBRA: rib_add_ipv4_multipath: NH 192.168.1.1 with 
flags

2016/04/13 01:28:08 ZEBRA: rib_add_ipv4_multipath: dump complete
2016/04/13 01:28:08 ZEBRA: kernel_rtm_ipv4: 172.16.0.0/28: successfully 
did NH 192.168.1.1

2016/04/13 01:28:08 ZEBRA: Kernel: Len: 200 Type: RTM_ADD
2016/04/13 01:28:08 ZEBRA: Kernel: UP GATEWAY DONE PROTO1
2016/04/13 01:28:08 ZEBRA: Kernel: message seq 0
2016/04/13 01:28:08 ZEBRA: Kernel: pid 75135, rtm_addrs 0x7
2016/04/13 01:28:08 ZEBRA: rtm_read: got rtm of type 1 (RTM_ADD)
2016/04/13 01:28:08 ZEBRA: rtm_read: RTM_ADD 172.16.0.0/28: done Ok
2016/04/13 01:28:08 ZEBRA: rib_lookup_and_dump: rn 0x8020ffbf0, rib 
0x8020ffb00: NOT removed, selected
2016/04/13 01:28:08 ZEBRA: rib_lookup_and_dump: dumping RIB entry 
0x8020ffb00 for 172.16.0.0/28 vrf 0
2016/04/13 01:28:08 ZEBRA: rib_lookup_and_dump: refcnt == 0, uptime == 
1460536088, type == 8, table == 0
2016/04/13 01:28:08 ZEBRA: rib_lookup_and_dump: metric == 11, distance 
== 115, flags == 16, status == 4
2016/04/13 01:28:08 ZEBRA: rib_lookup_and_dump: nexthop_num == 1, 
nexthop_active_num == 1, nexthop_fib_num == 0
2016/04/13 01:28:08 ZEBRA: rib_lookup_and_dump: NH 192.168.1.1 with 
flags ACTIVE FIB

2016/04/13 01:28:08 ZEBRA: rib_lookup_and_dump: dump complete
[…]

Notice the following lines:

2016/04/13 01:28:06 ZEBRA: vty[??]@# exit
[17 sec of no messages here…]
2016/04/13 01:28:23 ZEBRA: Kernel: Len: 168 Type: RTM_MISS
2016/04/13 01:28:23 ZEBRA: Kernel: DONE
2016/04/13 01:28:23 ZEBRA: Kernel: message seq 0
2016/04/13 01:28:23 ZEBRA: Kernel: pid 0, rtm_addrs 0x1
2016/04/13 01:28:23 ZEBRA: Unprocessed RTM_type: 7

It seems somehow zebra drops or misses several messages from isis 
(including the route which it supposed to install)


Outcome is random. I can run it 

[quagga-dev 14906] Re: [PATCH 1/6] Add support for protobuf.

[Martin Winter]

Avneesh,

You missed to update the Makefile infrastructure for the new directory
“make dist” does not add the new qpb directory to the tar it
creates.

(This causes theCentOS package fail to build on my CI system)

- Martin


On 11 Mar 2016, at 12:21, Avneesh Sachdev wrote:


Infrastructure that allows protocol buffers to be used in Quagga. The
changes below comprise of:

- Build hooks

- Protobuf definitions for common types.

- Library routines for working with protobuf, including functions
 that help translate between common quagga types and their protobuf
 equivalents.

Changes:

* qpb/{Makefile.am,README.txt,qpb.h,.gitignore}

 Add the qpb library, which provides shared code and definitions
 for using protocol buffers in quagga code.

* qpb/qpb.proto

 Protobuf definitions that can be shared by all of quagga.

* qpb/linear_allocator.h

 An allocator that allocates memory by walking down towards the end
 of a buffer. This is used to cheaply allocate/deallocate memory on
 the stack for protobuf operations.

* qpb/qpb_allocator.[ch]

 Thin layer that allows a linear allocator to be used with the
 protobuf-c library.

* common.am

 This is an automake fragment that is intended to be shared by
 Makefile.am files in the tree. It currently includes definitions
 related to protobuf.

* configure.ac

 - Add logic to optionally build protobuf code.

   By default, protobuf support is enabled if the protobuf C
   compiler (protoc-c) is available, and the associated header
   files/library can be found.

   The user can choose to override this behavior via the new
   --disable-protobuf/--enable-protobuf flags.

 - Include the quagga protobuf library (qpb) in the build.

* .gitignore

 Ignore source code generated by protobuf compiler.

* Makefile.am

 Add 'qpb' to the list of subdirectories.

Signed-off-by: Avneesh Sachdev 
---
.gitignore |   3 +
Makefile.am|   2 +-
common.am  |  39 ++
configure.ac   |  52 ++-
qpb/.gitignore |  15 ++
qpb/Makefile.am|  20 +++
qpb/README.txt |   1 +
qpb/linear_allocator.h | 207 +++
qpb/qpb.h  | 372 
+

qpb/qpb.proto  | 121 
qpb/qpb_allocator.c|  67 +
qpb/qpb_allocator.h| 113 +++
12 files changed, 1009 insertions(+), 3 deletions(-)
create mode 100644 common.am
create mode 100644 qpb/.gitignore
create mode 100644 qpb/Makefile.am
create mode 100644 qpb/README.txt
create mode 100644 qpb/linear_allocator.h
create mode 100644 qpb/qpb.h
create mode 100644 qpb/qpb.proto
create mode 100644 qpb/qpb_allocator.c
create mode 100644 qpb/qpb_allocator.h

diff --git a/.gitignore b/.gitignore
index e8de252..a281555 100644
--- a/.gitignore
+++ b/.gitignore
@@ -38,3 +38,6 @@ build
m4/*.m4
!m4/ax_sys_weak_alias.m4
cscope.*
+*.pb.h
+*.pb-c.h
+*.pb-c.c
diff --git a/Makefile.am b/Makefile.am
index d2efb20..ece8a59 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with automake to produce Makefile.in.

-SUBDIRS = lib @ZEBRA@ @BGPD@ @RIPD@ @RIPNGD@ @OSPFD@ @OSPF6D@ \
+SUBDIRS = lib qpb @ZEBRA@ @BGPD@ @RIPD@ @RIPNGD@ @OSPFD@ @OSPF6D@ \
   @ISISD@ @PIMD@ @WATCHQUAGGA@ @VTYSH@ @OSPFCLIENT@ @DOC@ m4 
@pkgsrcdir@ \

   redhat @SOLARIS@ tests

diff --git a/common.am b/common.am
new file mode 100644
index 000..dc79479
--- /dev/null
+++ b/common.am
@@ -0,0 +1,39 @@
+#
+# Automake fragment intended to be shared by Makefile.am files in the
+# tree.
+#
+
+if HAVE_PROTOBUF
+
+# Uncomment to use an non-system version of libprotobuf-c.
+#
+# Q_PROTOBUF_C_CLIENT_INCLUDES = 
-I$(top_srcdir)/third-party/protobuf-c/src
+# Q_PROTOBUF_C_CLIENT_LDOPTS = 
$(top_builddir)/third-party/protobuf-c/src/libprotobuf-c.la

+
+Q_PROTOBUF_C_CLIENT_INCLUDES=
+Q_PROTOBUF_C_CLIENT_LDOPTS=-lprotobuf-c
+
+Q_PROTOC=protoc
+Q_PROTOC_C=protoc-c
+
+Q_PROTOBUF_CFILES = $(filter %.pb-c.c,$(SOURCES))
+
+Q_PROTOBUF_SRCS = $(Q_PROTOBUF_CFILES) $(Q_PROTOBUF_HFILES)
+
+# Rules
+%.pb.h: %.proto
+	$(Q_PROTOC) $(PROTOBUF_INCLUDES) --cpp_out=$(top_srcdir) 
$(top_srcdir)/$(PROTOBUF_PACKAGE)/$^

+
+%.pb-c.c %.pb-c.h: %.proto
+	$(Q_PROTOC_C) $(PROTOBUF_INCLUDES) --c_out=$(top_srcdir) 
$(top_srcdir)/$(PROTOBUF_PACKAGE)/$^

+
+#
+# Information about how to link to various libraries.
+#
+Q_QUAGGA_PB_CLIENT_LDOPTS = $(top_srcdir)/qpb/libquagga_pb.la 
$(Q_PROTOBUF_C_CLIENT_LDOPTS)

+
+endif  # HAVE_PROTOBUF
+
+Q_CLEANFILES = $(Q_PROTOBUF_SRCS)
+
+Q_BUILT_SRCS = $(Q_PROTOBUF_SRCS)
diff --git a/configure.ac b/configure.ac
index 3003e62..51be70a 100755
--- a/configure.ac
+++ b/configure.ac
@@ -20,7 +20,10 @@ AC_CANONICAL_BUILD()
AC_CANONICAL_HOST()
AC_CANONICAL_TARGET()

-AM_INIT_AUTOMAKE(1.6)
+# Disable portability warnings -- our automake code (in particular
+# common.am) uses some constructs specific to gmake.
+AM_INIT_AUTOMAKE([1.6 -Wno-portability])
+
AM_SILENT_RULES([yes])

[quagga-dev 14904] Re: CI Testresult: FAILED (Re: [quagga-dev,14881,3/3] *: Consolidate all double VIEW_NODE and ENABLE_NODE s)

[Martin Winter]

There is actually a bug in “make check”

failing the “testcli” does not return an error exist status.
So my CI system didn’t detect the error initially, but then noticed
during the dejagnu log parsing the failure…

(It does for [most] other failures).

I’m going to add a hack to check for “FAIL:” in dejagnu console 
log…


- Martin

On 11 Mar 2016, at 14:10, Martin Winter wrote:

Need to fix my log parsing for this case on the CI system, but 
basically

the “make check” for libzebra fails on all these systems:

11-Mar-2016 12:45:40=== libzebra tests ===
11-Mar-2016 12:45:40
11-Mar-2016 12:45:40Schedule of variations:
11-Mar-2016 12:45:40unix
11-Mar-2016 12:45:40
11-Mar-2016 12:45:40Running target unix
11-Mar-2016 12:45:40	Using /usr/share/dejagnu/baseboards/unix.exp as 
board description file for target.
11-Mar-2016 12:45:40	Using /usr/share/dejagnu/config/unix.exp as 
generic interface file for target.
11-Mar-2016 12:45:40	Using ./config/unix.exp as 
tool-and-target-specific interface file.

11-Mar-2016 12:45:40Running ./libzebra.tests/tabletest.exp ...
11-Mar-2016 12:45:40	Running 
./libzebra.tests/test-timer-correctness.exp ...

11-Mar-2016 12:45:45Running ./libzebra.tests/testcli.exp ...
11-Mar-2016 12:45:46FAIL: testcli
11-Mar-2016 12:45:46Running ./libzebra.tests/testcommands.exp ...
11-Mar-2016 12:45:46Test Run By ci on Fri Mar 11 12:45:46 2016
11-Mar-2016 12:45:46Native configuration is x86_64-unknown-linux-gnu
11-Mar-2016 12:45:46

- Martin


On 11 Mar 2016, at 13:00, cisys...@netdef.org wrote:


Continous Integration Result: FAILED

See below for issues.
This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter <mwin...@opensourcerouting.org>.

Patches applied :
Patchwork 1857: http://patchwork.quagga.net/patch/1857
[quagga-dev,14880,1/3] bgpd, lib: Remove RESTRICTED_NODE from code 
base

Patchwork 1856: http://patchwork.quagga.net/patch/1856
[quagga-dev,14879,2/3] lib: Consolidate VIEW_NODE to be ENABLE_NODE 
as well

Patchwork 1858: http://patchwork.quagga.net/patch/1858
[quagga-dev,14881,3/3] *: Consolidate all double VIEW_NODE and 
ENABLE_NODEs

Tested on top of Git : e3f623b (as of 20160309.134159 UTC)
CI System Testrun URL: 
https://ci1.netdef.org/browse/QUAGGA-QPWORK-251/



Get source and apply patch from patchwork: Successful


Building Stage: Failed

OmniOS amd64 build: Successful

FreeBSD10 amd64 build: No useful log found
Ubuntu1204 amd64 build: No useful log found
Openbsd58 amd64 build: No useful log found
NetBSD7 amd64 build: No useful log found
NetBSD6 amd64 build: No useful log found
FreeBSD8 amd64 build: No useful log found
FreeBSD9 amd64 build: No useful log found
CentOS7 amd64 build: No useful log found
Ubuntu1404 amd64 build: No useful log found
CentOS6 amd64 build: No useful log found
Debian8 amd64 build: No useful log found

Regards,
NetDEF/OpenSourceRouting Continous Integration (CI) System

---
OpenSourceRouting.org is a project of the Network Device Education 
Foundation,
For more information, see www.netdef.org and 
www.opensourcerouting.org
For questions in regards to this CI System, contact Martin Winter, 
mwin...@netdef.org


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14903] Re: CI Testresult: FAILED (Re: [quagga-dev, 14886, 6/6] zebra: add developer test functions for FPM code)

[Martin Winter]

Ignore this first result from the CI system
Parsing of the result failed.

See the other CI email for real results (which still failed)

- Martin

On 11 Mar 2016, at 14:12, cisys...@netdef.org wrote:


Continous Integration Result: FAILED

See below for issues.
This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter <mwin...@opensourcerouting.org>.

Patches applied :
Patchwork 1861: http://patchwork.quagga.net/patch/1861
[quagga-dev,14885,1/6] Add support for protobuf.
Patchwork 1860: http://patchwork.quagga.net/patch/1860
[quagga-dev,14883,2/6] Add protobuf support for FPM.
Patchwork 1864: http://patchwork.quagga.net/patch/1864
[quagga-dev,14888,3/6] zebra: optionally use protobuf with FPM
Patchwork 1859: http://patchwork.quagga.net/patch/1859
[quagga-dev,14884,4/6] build: support for development 
build

Patchwork 1863: http://patchwork.quagga.net/patch/1863
[quagga-dev,14887,5/6] vtysh: support for invoking functions by 
name

Patchwork 1862: http://patchwork.quagga.net/patch/1862
[quagga-dev,14886,6/6] zebra: add developer test functions for FPM 
code

Tested on top of Git : e3f623b (as of 20160309.134159 UTC)
CI System Testrun URL: 
https://ci1.netdef.org/browse/QUAGGA-QPWORK-252/



Get source and apply patch from patchwork: Successful


Building Stage: Failed

FreeBSD8 amd64 build: Successful
Ubuntu1204 amd64 build: Successful
FreeBSD10 amd64 build: Successful
NetBSD7 amd64 build: Successful
NetBSD6 amd64 build: Successful
FreeBSD9 amd64 build: Successful
Ubuntu1404 amd64 build: Successful
Debian8 amd64 build: Successful

Make failed for Openbsd58 amd64 build
see log in attachment openbsd58_amd64_make.log
Package building failed for CentOS7 amd64 build:(see full log in 
attachment centos7_amd64_pkgbuild.log)
tar: 
quagga-1.0.20160309-ci.NetDEF.org-20160311.215901-git.e3f623b/tests/libzebra.tests/test-timer-correctness.exp: 
file name is too long (max 99); not dumped
tar: 
quagga-1.0.20160309-ci.NetDEF.org-20160311.215901-git.e3f623b/tests/libzebra.tests/testnexthopiter.exp: 
file name is too long (max 99); not dumped

tar: Exiting with failure status due to previous errors
make[1]: Leaving directory `/home/ci/cibuild.252/rpmwork'
if test -d 
"quagga-1.0.20160309-ci.NetDEF.org-20160311.215901-git.e3f623b"; then 
find "quagga-1.0.20160309-ci.NetDEF.org-20160311.215901-git.e3f623b" 
-type d ! -perm -200 -exec chmod u+w {} ';' && rm -rf 
"quagga-1.0.20160309-ci.NetDEF.org-20160311.215901-git.e3f623b" || { 
sleep 5 && rm -rf 
"quagga-1.0.20160309-ci.NetDEF.org-20160311.215901-git.e3f623b"; }; 
else :; fi

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.QHHLLZ
+ umask 022
+ cd /home/ci/cibuild.252/rpmbuild/BUILD
+ cd /home/ci/cibuild.252/rpmbuild/BUILD


OmniOS amd64 build: Unknown Log 
 URL: 
https://ci1.netdef.org/browse/QUAGGA-QPWORK-252/artifact/CI010BUILD/ErrorLog/log_bootstrap.txt

OmniOS amd64 build: No useful log found
Package building failed for CentOS6 amd64 build:(see full log in 
attachment centos6_amd64_pkgbuild.log)
tar: 
quagga-1.0.20160309-ci.NetDEF.org-20160311.215901-git.e3f623b/tests/libzebra.tests/testnexthopiter.exp: 
file name is too long (max 99); not dumped
tar: 
quagga-1.0.20160309-ci.NetDEF.org-20160311.215901-git.e3f623b/tests/libzebra.tests/test-timer-correctness.exp: 
file name is too long (max 99); not dumped

tar: Exiting with failure status due to previous errors
gtar: 
quagga-1.0.20160309-ci.NetDEF.org-20160311.215901-git.e3f623b/tests/libzebra.tests/testnexthopiter.exp: 
file name is too long (max 99); not dumped
gtar: 
quagga-1.0.20160309-ci.NetDEF.org-20160311.215901-git.e3f623b/tests/libzebra.tests/test-timer-correctness.exp: 
file name is too long (max 99); not dumped

gtar: Exiting with failure status due to previous errors
{ test ! -d 
"quagga-1.0.20160309-ci.NetDEF.org-20160311.215901-git.e3f623b" || { 
find "quagga-1.0.20160309-ci.NetDEF.org-20160311.215901-git.e3f623b" 
-type d ! -perm -200 -exec chmod u+w {} ';' && rm -fr 
"quagga-1.0.20160309-ci.NetDEF.org-20160311.215901-git.e3f623b"; }; }

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.41wdfQ
+ umask 022



Regards,
NetDEF/OpenSourceRouting Continous Integration (CI) System

---
OpenSourceRouting.org is a project of the Network Device Education 
Foundation,

For more information, see www.netdef.org and www.opensourcerouting.org
For questions in regards to this CI System, contact Martin Winter, 
mwin...@netdef.org


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14900] Re: CI Testresult: PASSED (Re: [quagga-dev, 14893] quagga: Remove double read of stream)

[Martin Winter]

Basic testing of the patch shows that this fixed the issue.

I can do a run after it is committed to a branch
(I would suggest to commit to master)

Let’s hope that there aren’t more bad issues.

Full compliance run takes approx 1..2 days (Ubuntu 14.04 first), then 
another 1..2 days (FreeBSD 10).


- Martin

On 11 Mar 2016, at 15:00, cisys...@netdef.org wrote:


Continous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF CI System <cisys...@netdef.org>

This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter <mwin...@opensourcerouting.org>.

Patches applied :
Patchwork 1865: http://patchwork.quagga.net/patch/1865
[quagga-dev,14893] quagga: Remove double read of stream
Tested on top of Git : e3f623b (as of 20160309.134159 UTC)
CI System Testrun URL: 
https://ci1.netdef.org/browse/QUAGGA-QPWORK-253/



Regards,
NetDEF/OpenSourceRouting Continous Integration (CI) System

---
OpenSourceRouting.org is a project of the Network Device Education 
Foundation,

For more information, see www.netdef.org and www.opensourcerouting.org
For questions in regards to this CI System, contact Martin Winter, 
mwin...@netdef.org


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14872] Quagga 1.0.20160309 - BGP Crashing

[Martin Winter]

(New thread so people actually see it)

I really wish my suggestion to Donald/Paul would have been followed and 
we would have created a RC version first
or at least updated Master first with giving me a few days for some 
checks…  :-(


Anyway, the brand new version 1.0.20160309 crashes in my BGP Tests:

2016/03/09 09:42:20 BGP: vty[??]@# exit
2016/03/09 09:42:20 BGP: stream_getl: Attempt to get long out of bounds
2016/03/09 09:42:20 BGP: &(struct stream): 0x7f495d91f6b0, size: 4096, 
getp: 23, endp: 25


2016/03/09 09:42:20 BGP: Assertion `0' failed in file stream.c, line 
413, function stream_getl

2016/03/09 09:42:20 BGP: Backtrace for 9 stack frames:
2016/03/09 09:42:20 BGP: [bt 0] 
/usr/lib/libzebra.so.0(zlog_backtrace+0x2b) [0x7f495c661c10]
2016/03/09 09:42:20 BGP: [bt 1] 
/usr/lib/libzebra.so.0(_zlog_assert_failed+0xa1) [0x7f495c66234c]
2016/03/09 09:42:20 BGP: [bt 2] /usr/lib/libzebra.so.0(stream_getl+0x7f) 
[0x7f495c65ef69]

2016/03/09 09:42:20 BGP: [bt 3] bgpd(+0x5c2f0) [0x7f495cb132f0]
2016/03/09 09:42:20 BGP: [bt 4] /usr/lib/libzebra.so.0(+0x34141) 
[0x7f495c666141]
2016/03/09 09:42:20 BGP: [bt 5] /usr/lib/libzebra.so.0(thread_call+0x7e) 
[0x7f495c656728]

2016/03/09 09:42:20 BGP: [bt 6] bgpd(main+0x417) [0x7f495caec22a]
2016/03/09 09:42:20 BGP: [bt 7] 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f495bf88ec5]

2016/03/09 09:42:20 BGP: [bt 8] bgpd(+0x35267) [0x7f495caec267]
2016/03/09 09:42:20 BGP: Current thread function zclient_read, scheduled 
from file zclient.c, line 1131


This is on Ubuntu 14.04

I’ll start digging into the details, just wanted to give a heads up.

Any hints on differences to the Proposed/6 branch?

- Martin
(Would like to be excited on 1.0…)

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14854] Re: BGP Keepalive/Holdtime changes in master

[Martin Winter]

On 10 Mar 2016, at 0:56, Oleg A. Arkhangelsky wrote:

> 10.03.2016, 11:47, "Martin Winter" <mwin...@opensourcerouting.org>:
>
>>
>> The change came from Cumulus and it makes a lot of sense in some
>> environments
>> (i.e. specially data centers).
>
> Datacenters is mostly iBGP with relative small number of routes.
> Do you have cases when multiple eBGP full view (~550K routes for
> each) neighbors established (or maybe actively flapping)?

I only have my test cases and I know about concerns from ISPs
for changes.
Anyway - I was the person who argued for keeping the old values
of 60/180sec. And that’s the current decision to go forward.
(At least for next release)

- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14852] Re: Quagga key rotation

[Martin Winter]

Paul,

Thanks for the heads-up.

can you give a list on who is included in these lists AND able to 
decrypt the messages?

(I always thought that security is going to maintainers anyway?)

- Martin

On 9 Mar 2016, at 6:54, Paul Jakma wrote:


Hi,

I have hopefully rolled over the Quagga PGP key. Note there should now 
be 3 keys:


C1A4AEA6: A signing only key, no email address, to sign releases.

8D0599B7: secur...@quagga.net

0E20C9BB: maintain...@quagga.net

These keys should all be self-signed, and signed by the old (6BB68C9C) 
and new maintain...@quagga.net keys, as well my personal key.


I have also updated http://www.nongnu.org/quagga/contacts.html to 
reflect current practices/status - please see the note about the 
distribution of secur...@quagga.net.


I have updated a major keyserver and 
http://www.nongnu.org/quagga/quagga.net.pgp.asc with the public keys.


Please let me know if I've screwed anything up. :)

regards,
- -- Paul Jakma p...@jakma.org  @pjakma Key ID: 64A2FF6A
Fortune:
This life is yours.  Some of it was given to you; the rest, you made 
yourself.



___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14851] Re: BGP Keepalive/Holdtime changes in master

[Martin Winter]

On 8 Mar 2016, at 11:30, John Kemp wrote:


You can't just update to 60 and 180 and commit that?


That’s what it used to be and what it reverts to again for the next 
release.



The 3s and 9s is just going to mess up anyone who pulls that version.


The change came from Cumulus and it makes a lot of sense in some 
environments

(i.e. specially data centers).
The main issue is that the default isn’t visible in the config and by 
changing
it everyone who didn’t set anything else would have changed their 
timers the

the new lower value.

I think the current consensus is that the shorter timers might be good, 
but

the missing defaults in the config make it difficult to change.
So we may need to fix the issue with the invisible defaults first 
(somehow)


- Martin Winter



On 3/8/2016 4:52 AM, Martin Winter wrote:

On 8 Mar 2016, at 2:59, Paul Jakma wrote:


On Tue, 15 Dec 2015, Martin Winter wrote:

Just to want to bring this up to everyones attention - one more 
time.


The commits from proposed 5 branch are now in master and the BGP
keepalive/holdtimer is now changed to 3s keepalive and 9s holdtime
(from 60s keepalive and 180s holdtime)


Had a chat with Donald about this yesterday, as you'd also recently
raised this again.

The underlying problem here is we need a better way to handle
defaults, and perhaps we should tackle that first. E.g., we also 
have

the link-detect default issue.

Donald and I are happy to back this out for now, before a release.

OK?


OK with me, but anyone else having a strong opinion against backing
this out, please speak up!

And yes, fully agree on the default issue. Suggestions welcome…

- Martin Winter


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev



___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14845] Re: BGP Keepalive/Holdtime changes in master

[Martin Winter]

On 8 Mar 2016, at 2:59, Paul Jakma wrote:


On Tue, 15 Dec 2015, Martin Winter wrote:


Just to want to bring this up to everyones attention - one more time.

The commits from proposed 5 branch are now in master and the BGP 
keepalive/holdtimer is now changed to 3s keepalive and 9s holdtime 
(from 60s keepalive and 180s holdtime)


Had a chat with Donald about this yesterday, as you'd also recently 
raised this again.


The underlying problem here is we need a better way to handle 
defaults, and perhaps we should tackle that first. E.g., we also have 
the link-detect default issue.


Donald and I are happy to back this out for now, before a release.

OK?


OK with me, but anyone else having a strong opinion against backing this 
out, please speak up!


And yes, fully agree on the default issue. Suggestions welcome…

- Martin Winter


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14842] Re: FreeBSD Bug: Zebra not deleting routes

[Martin Winter]

If you want a better commit message from me, then I suggest this

— snip —
zebra: Fix route deletion on *BSD

Fix for not handling RTM_CHANGE correctly. This patch change it to
delete/add instead.
Using RTM_CHANGE on kernels where it works is better, but is left
as an  exercise for developer who has access and will to fix it
on *BSD.
— snip —

(However, I see the real author as Timo and credits etc should go to 
him. I’ve just

fixed a few typos in his proposed fix)

- Martin


On 7 Mar 2016, at 1:28, Paul Jakma wrote:


Just a ping on needing a commit message.

Otherwise, I'll note that if a commiter has to write the commit 
message, that that's a creative act and they can more than 
legitimately set the Author == themselves. ;)


regards,

Paul

On Fri, 26 Feb 2016, Paul Jakma wrote:


Can someone propose a better commit message? :)

On Wed, 24 Feb 2016, Martin Winter wrote:


Thanks, I see it applied.

Most of the issues are fixed. I see a few ISIS & OSPF differences.
Could be the different base (the Ubuntu one was done before the last
rebase).
I’m currently re-running Ubuntu against the rebased tree to have
a base for comparison.

Updated test comparison is here:
https://drive.google.com/open?id=0B8W_T0dxQfwxN2ZXSnkweF94anc

- Martin


On 24 Feb 2016, at 4:42, Donald Sharp wrote:


Martin -

Thanks for this work.

I'll be applying the patch here in a few minutes.


regards,



--
Paul Jakma  p...@jakma.org  @pjakma Key ID: 64A2FF6A
Fortune:
When taxes are due, Americans tend to feel quite bled-white and blue.


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14797] Re: CI Testresult: FAILED (Re: [quagga-dev, 14785, 10/10] build: goodbye, gawk)

[Martin Winter]

On 26 Feb 2016, at 2:58, cisys...@netdef.org wrote:

Continous Integration Result: FAILED

See below for issues.
This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter <mwin...@opensourcerouting.org>.

Patches applied :
Patchwork 1839: http://patchwork.quagga.net/patch/1839
[quagga-dev,14778,01/10] *: get rid of MTYPE 0
Patchwork 1843: http://patchwork.quagga.net/patch/1843
[quagga-dev,14786,02/10] lib: move memory.[ch] out of the way
Patchwork 1838: http://patchwork.quagga.net/patch/1838
[quagga-dev,14783,03/10] lib: add new extensible memory-type 
handling

Patchwork 1844: http://patchwork.quagga.net/patch/1844
[quagga-dev,14787,04/10] lib: migrate to new memory-type handling
Patchwork 1845: http://patchwork.quagga.net/patch/1845
[quagga-dev,14788,05/10] *: split  distribute memtypes
Patchwork 1840: http://patchwork.quagga.net/patch/1840
[quagga-dev,14782,06/10] *: stop (re|ab)using lib/ MTYPEs
Patchwork 1842: http://patchwork.quagga.net/patch/1842
[quagga-dev,14784,07/10] lib: distribute mtypes into files
Patchwork 1836: http://patchwork.quagga.net/patch/1836
[quagga-dev,14779,08/10] lib: clean/restore memory debugging 
functions

Patchwork 1837: http://patchwork.quagga.net/patch/1837
[quagga-dev,14781,09/10] build: goodbye, memtypes.c
Patchwork 1841: http://patchwork.quagga.net/patch/1841
[quagga-dev,14785,10/10] build: goodbye, gawk
Tested on top of Git : ca52365 (as of 20160224.131903 UTC)
CI System Testrun URL: 
https://ci1.netdef.org/browse/QUAGGA-QPWORK-247/



Get source and apply patch from patchwork: Successful


Building Stage: Failed

CentOS6 amd64 build: Successful
Ubuntu1204 amd64 build: Successful
NetBSD7 amd64 build: Successful
FreeBSD10 amd64 build: Successful
OmniOS amd64 build: Successful
NetBSD6 amd64 build: Successful
FreeBSD8 amd64 build: Successful
Debian8 amd64 build: Successful
Openbsd58 amd64 build: Successful
FreeBSD9 amd64 build: Successful
CentOS7 amd64 build: Successful

Package building failed for Ubuntu1404 amd64 build:(see full log 
in attachment ubuntu1404_amd64_pkgbuild.log)

debian/rules:10: "DEBIAN: SNMP disabled, see README.Debian"
# Quagga needs /proc to check some BSD vs Linux specific stuff.
# Else it fails with an obscure error message pointing out that
# IPCTL_FORWARDING is an undefined symbol which is not very helpful.
dh_auto_configure -- \
--enable-exampledir=/usr/share/doc/quagga/examples/ \
--localstatedir=/var/run/quagga \
--sbindir=/usr/lib/quagga \
--sysconfdir=/etc/quagga \


That’s actually some bad parsing on the log…  (will fix this 
tomorrow)


(And yes, I’ve intercepted it and made sure it runs on top of correct 
commit on proposed/6)


Error is during package build later:

[…]
  CC   pim_static.o
  AR   libpim.a
  CC   test_igmpv3_join.o
  CCLD test_igmpv3_join
test_igmpv3_join.o:(.data.rel.ro+0x0): undefined reference to `_mt_TMP'
test_igmpv3_join.o:(.data.rel.ro+0x8): undefined reference to `_mt_IF'
test_igmpv3_join.o:(.data.rel.ro+0x10): undefined reference to 
`_mt_CONNECTED_LABEL'

pim_igmp_join.o:(.data.rel.ro+0x0): undefined reference to `_mt_TMP'
pim_igmp_join.o:(.data.rel.ro+0x8): undefined reference to `_mt_IF'
pim_igmp_join.o:(.data.rel.ro+0x10): undefined reference to 
`_mt_CONNECTED_LABEL'

collect2: error: ld returned 1 exit status
make[4]: *** [test_igmpv3_join] Error 1
make[4]: Leaving directory 
`/home/ci/cibuild.247/debpkg/quagga-test/pimd'


(see attached full log for more details)

- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14791] FreeBSD bug: Mac filter issue (ie in ISIS hello)

[Martin Winter]

Next FreeBSD issue.

This is not a new bug - it existed in 0.99.24 (at times when none tested 
compliance).
This bug at least affects ISIS, but I expect it might be in some 
library. This works correctly on Linux.


In ISIS, Only Hello’s sent to MAX ISIS-all-level-2-ISs 
(01:80:c2:00:00:15) (or similar L1 MAC) should be accepted.
(ISIS ISO reference is ISO/IEC 10589:1992(E), s8.4.2, p44, Broadcast 
subnetwork IIH PDUs)


Somehow Quagga on FreeBSD listens and accepts packets sent to any MAC 
address
(My test sends the ISIS Hellos to MAC destination 12:23:34:45:56:67 [an 
unused MAC] and Quagga

incorrectly forms a neighbor)

Looks like there is a check missing for the MAC.

- Martin

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14771] Re: FreeBSD Bug: Zebra not deleting routes

[Martin Winter]

Thanks, I see it applied.

Most of the issues are fixed. I see a few ISIS & OSPF differences.
Could be the different base (the Ubuntu one was done before the last
rebase).
I’m currently re-running Ubuntu against the rebased tree to have
a base for comparison.

Updated test comparison is here:
https://drive.google.com/open?id=0B8W_T0dxQfwxN2ZXSnkweF94anc

- Martin


On 24 Feb 2016, at 4:42, Donald Sharp wrote:


Martin -

Thanks for this work.

I'll be applying the patch here in a few minutes.

donald

On Wed, Feb 24, 2016 at 6:02 AM, Martin Winter <
mwin...@opensourcerouting.org> wrote:


On 22 Feb 2016, at 6:40, Donald Sharp wrote:


Martin -

Any word on this?  I'd like to push this patch if it fixes your 
issues.




Ok, finally more answers.
It seems something went wrong when I retested with Timo’s fix. 
(Might be
related to the way I retested as I was unable to do a clean rebuild 
and
applied patch [probably wrong] on top of the last commit. Rebase made 
it

impossible to pull a new copy as I usually do for each run)

Anyway, re-running the tests and Timo’s patch (same fixed version 
as

mailed earlier) fixes at least all BGP IPv4 bug difference between
Linux and FreeBSD.

So I suggest to go ahead an apply that patch on top of proposed/6 
branch


Full results (including all other protocols) of the rerun will be 
available

in approx another 12..18hrs.

- Martin



On Thu, Feb 18, 2016 at 10:30 PM, Martin Winter <

mwin...@opensourcerouting.org> wrote:

On 18 Feb 2016, at 18:35, Donald Sharp wrote:


Martin -


rt_socket.c is not compiled on linux so no need for verification.  
Once



you


have a run please let me know and I'll push your updated patch.



It’s running now. Will know soon. It definitely fixes some of the 
errors

and I hope it actually fixes all of the FreeBSD errors.

Will know in approx one more day.

(BTW: Testing on a git commit which does no longer exist because of
rebase,
but I needed the same to compare. Lucky that I still had the VMs 
with the

old git checkout running…)

- Martin



donald

On Thu, Feb 18, 2016 at 9:19 PM, Martin Winter <
mwin...@opensourcerouting.org> wrote:

Timo,


On 17 Feb 2016, at 23:01, Timo Teras wrote:

On Wed, 17 Feb 2016 20:11:07 -0800


"Martin Winter" <mwin...@opensourcerouting.org> wrote:

This is based on Quagga proposed 6 branch of Feb 10 (git 
f48d5b9957 -



which does no longer exist, [no] thanks to rebase on a public
git) on FreeBSD 10.2.

Zebra seems to fail delete any routes in FreeBSD RIB. It fails 
with

updates (better routes to different interface) and
it fails to remove them when quagga is killed.


Thanks for the testing. Sounds like this is breakage caused by 
my

atomic FIB patch which was pretty untested on *BSD.

Looks like the code talking to kernel does not handle RTM_CHANGE
correctly. As first test, perhaps just removing RTM_CHANGE usage 
might

fix the issues and revert to how it used to work.

Using RTM_CHANGE on kernels where it works is better, but it's 
left an
exercise for developer who has access and will to fix it on 
*BSD.




Thanks for the patch. Seems like you never tested it (failed to


compile),


but was close enough to guess what you probably meant. See inline 
on



patch





diff --git a/zebra/rt_socket.c b/zebra/rt_socket.c


index 4d0a7db..9012280 100644
--- a/zebra/rt_socket.c
+++ b/zebra/rt_socket.c
@@ -68,7 +68,7 @@ sin_masklen (struct in_addr mask)

/* Interface between zebra message and rtm message. */
static int
-kernel_rtm_ipv4 (int cmd, struct prefix *p, struct rib *rib, 
int



family)



+kernel_rtm_ipv4 (int cmd, struct prefix *p, struct rib *rib)


{
struct sockaddr_in *mask = NULL;
@@ -245,7 +245,7 @@ sin6_masklen (struct in6_addr mask)

/* Interface between zebra message and rtm message. */
static int
-kernel_rtm_ipv6 (int cmd, struct prefix *p, struct rib *rib, 
int



family)



+kernel_rtm_ipv6 (int cmd, struct prefix *p, struct rib *rib)

{
struct sockaddr_in6 *mask;
struct sockaddr_in6 sin_dest, sin_mask, sin_gate;
@@ -363,33 +363,32 @@ kernel_rtm_ipv6 (int cmd, struct prefix 
*p,



struct



rib *rib, int family)


#endif

+static int
+kernel_rtm_ipv6 (int cmd, struct prefix *p, struct rib *rib)



I assume this should be
kernel_rtm - not kernel_rtm_ipv6
(otherwise you have a duplicate for kernel_rtm_ipv6() and a loop
in case of AF_INET6)


+{


+  switch (PREFIX_FAMILY(p))
+{
+case AF_INET:
+  return kernel_rtm_ipv4 (cmd, p, rib);
+case AF_INET6:
+  return kernel_rtm_ipv6 (cmd, p, rib);
+}
+  return 0;
+}
+
int
kernel_route_rib (struct prefix *p, struct rib *old, struct rib 
*new)

{
-  struct rib *rib;
-  int route = 0, cmd;
-
-  if (!old && new)
-cmd = RTM_ADD;
-  else if (old && !new)
-cmd = RTM_DELETE;
-  else
-cmd = RTM_CHANGE;
-
-  rib = new ? new : old;
+  int route = 0;

if (zserv_privs.change(ZPRIVS_RAISE))
zlog (NULL, LOG_ERR, "Can't raise privileges");

-