[quagga-dev 16532] Fork of Quagga

[Donald Sharp]

All -

Since there have been questions on alias about the fork and if you are
interested in checking us out, we are working over here:

https://github.com/freerangerouting/frr

The email alias can be found:

https://lists.nox.tf/listinfo/frr

We have a public slack channel for realtime discussion:

freerangerouting.slack.com

Please unicast me or the frr alias with any questions you may have.

thanks!

donald

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

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

[Donald Sharp]

This should fix the issue.

diff --git a/lib/thread.c b/lib/thread.c
index a26b43a..6fcddd7 100644
--- a/lib/thread.c
+++ b/lib/thread.c
@@ -790,7 +790,7 @@ funcname_thread_add_read_write (int dir, struct
thread_master *m,
   else
 fdset = >writefd;

-  if (FD_ISSET (fd, >readfd))
+  if (FD_ISSET (fd, fdset))
 {
   zlog (NULL, LOG_WARNING, "There is already %s fd [%d]",
(dir = THREAD_READ) ? "read" : "write", fd);

On Wed, Jul 13, 2016 at 6:22 AM, Paul Jakma <p...@jakma.org> wrote:
> Hi Lou,
>
> Thanks. Donald had another patch in that series, 0b697fa9281a62 / "ib: Add
> ability to use poll() instead of select", but had indicated that was kind of
> preliminary still and that he wanted to do further work on it.
>
> If you drop the below, do you find further probs?
>
> regards,
>
> Paul
>
>
> On Wed, 13 Jul 2016, Lou Berger wrote:
>
>> This is patch that's breaking bgpd in 8/proposed/ff
>>
>> Author: Donald Sharp <sha...@cumulusnetworks.com>
>> Date:   Fri Mar 4 15:28:56 2016 -0500
>>
>>lib: Refactor read/write functionality
>>
>>Both the read and write functions used the same code
>>slightly modified for reading and writing.  Combine this
>>code together.
>>
>>Signed-off-by: Donald Sharp <sha...@cumulusnetworks.com>
>>
>>Edited-by: Paul Jakma <paul.ja...@hpe.com> to retain the
>>external library symbols, for ease of merging.
>>
>>
>> On 7/12/2016 7:55 PM, Lou Berger wrote:
>>>
>>> Just an update: we've hooked our regression system into the github
>>> mirror and are now running minimal  regression tests on bgpd.  The tests
>>> start at a commit and move to the head of the branch, commit by commit
>>> -- pretty simple approach.
>>>
>>> Each run does a compile, basic adjacency checks, some unicast and VRF
>>> route distributions and checks the results against a reference (known
>>> good run).  Each run takes about 4 minutes and there are about 160
>>> commits in /8/proposed/ff - currently has about 150 to go.
>>>
>>> I'll provide an update once we have interesting results.
>>>
>>> Lou
>>>
>>> PS I rebased the following commits to be 1st in order to get the
>>> regression environment running:
>>>
>>> Author: Lou Berger <lber...@labn.net>
>>> Date:   Tue May 17 07:10:37 2016 -0400
>>>
>>> bgpd: Add flag to not change e{u,g}id on startup and run as
>>> unprivileged user
>>>
>>> * bgp_main.c: add -S / --skip_runas flag to not change effective
>>> user/group
>>>   on start up.  Enables bgpd to be run by unprivileged user.
>>>
>>> Author: Lou Berger <lber...@labn.net>
>>> Date:   Tue May 17 07:10:36 2016 -0400
>>>
>>> bgp: add "debug bgp allow-martians" next hops and related
>>> code/commands
>>>
>>> Author: Lou Berger <lber...@labn.net>
>>> Date:   Tue May 17 12:19:51 2016 -0400
>>>
>>> lib: change command logging to be off by default
>>>
>>> * lib/vty.c: add 'log_command' to enable logging of vty commands
>>> executed.
>>>   Default command logging to off.
>>>
>>>
>>>
>>> On 7/11/2016 5:44 AM, Lou Berger wrote:
>>>>>>
>>>>>> Any luck pinning down what commits are causing which issues for you?
>>>>>>
>>>> Not yet.  Thinking I'll try to wire into our regression system in some
>>>> way...
>>>>
>>
>>
>>
>> ___
>> 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:
> If dolphins are so smart, why did Flipper work for television?

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

[quagga-dev 15770] Re: Quagga project governance

[Donald Sharp]

I think our recollections of what happened appears to be very
different.  I've stated publicly what my position is and would
appreciate you to stop continuing to misrepresent my position.

donald

On Tue, Jun 28, 2016 at 11:12 AM, Paul Jakma <p...@jakma.org> wrote:
> On Tue, 28 Jun 2016, Donald Sharp wrote:
>
>> I would like to have the ability to have dispute resolution handled in a
>> timely fashion.  It should be measured in weeks not months.
>
>
> They were handled plenty quickly, you just didn't like the answers.
>
> regards,
> --
> Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
> Fortune:
> Modeling paged and segmented memories is tricky business.
> -- P.J. Denning

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

[quagga-dev 15763] Re: Quagga project governance

[Donald Sharp]

I think this is a succinct conveyance of my concerns.  I'd like to add one more:

I would like to have the ability to have dispute resolution handled in
a timely fashion.  It should be measured in weeks not months.

donald

On Fri, Jun 24, 2016 at 11:15 AM, Lou Berger  wrote:
> Paul,
>
> On 6/24/2016 10:51 AM, Paul Jakma wrote:
>> On Fri, 24 Jun 2016, Lou Berger wrote:
>>
>>> I think this goes to the root of the recent discussions:
>> Oh, and while that might go to the root of some discussion, what caused
>> those discussions?
>
> 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
>
> I probably wouldn't have cared enough to speak up on 3 if 1 and 2
> weren't issues.
>
> I think there a slew of other issues that stem from / will be solved by
> addressing the above , e.g., duplicate patches,  painful/repeated
> rebases, and late discovery of issues.
>
> Lou
>
>> regards,
>
>

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

[quagga-dev 15759] Re: Quagga project governance

[Donald Sharp]

Lou -

It works for me.  I believe we've resolved all current comments that
were placed into the document.  I'd like to hear feedback from
everyone on this new version of the document.

https://docs.google.com/document/d/19DZcT0cJUSYxVIFenHvGFhLLUmLTRFHuMNZcI7aUNGA/edit?usp=sharing

In light of the HACKING.md additions, I will take further comments on
these changes and submit a HACKING.md patch on Thursday the 30th.  I
won't be paying full attention to any review comments because I will
be on vacation the 1-10 of July, but hope to resolve all issues upon
getting back in a timely manner.

thanks!

donald



On Tue, Jun 28, 2016 at 8:23 AM, Lou Berger  wrote:
> Paul,
>
> So you'll discuss details once proposed as a patch to HACKING.md?
> Doesn't sound like the right place for some of this, but sure -
> shouldn't be hard to merge as there's not much overlap.  In fact, I just
> did the merge (in
> https://docs.google.com/document/d/19DZcT0cJUSYxVIFenHvGFhLLUmLTRFHuMNZcI7aUNGA/edit#)
> by dropping HACKING.md at the start.
>
> It probably makes sense to ensure the new pieces are largely agreed to
> before submitting as patch (by Donald?) as well as formatted
> consistently with HACKING.md.
>
> Donald,
> Does this work for you?  Where do we stand with resolving comments and
> getting general agreement on the Maintainers doc?
>
> Lou
>
>
> On June 28, 2016 6:54:44 AM Paul Jakma  wrote:
>
>> On Tue, 28 Jun 2016, Lou Berger wrote:
>>
>>> Being unwilling to directly comment on, or contribute to a community
>>> developed document seems a bit unreasonable to me.
>>
>> One existed. Written by a number of people over the years. It's not
>> perfect, but what is?
>>
>> It starts with:
>>
>> "This is a living document. Suggestions for updates, via the
>>[quagga-dev list].., are welcome."
>>
>> Ignoring that and starting from scratch of itself I took to be sending a
>> message, to an extent.
>>
>> If you want evolve, evolve things.
>>
>> regards,
>> --
>> Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
>> Fortune:
>> The brain is a wonderful organ; it starts working the moment you get up
>> in the morning, and does not stop until you get to work.
>>
>
>

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

[quagga-dev 15696] Re: Quagga Monthly Meeting Notes

[Donald Sharp]

Lou -

You are correct, I jumped the gun a little bit.  We need to provide
time for people to vote on the document..  Please take the time to
read the document and let us know how you would like to proceed.

Additionally I'll move the CE part back to the Quagga Release Process docuemnt.

thanks!

donald

On Wed, Jun 22, 2016 at 6:28 AM, Lou Berger <lber...@labn.net> wrote:
> Paul,
>
> While the conclusion to work on ce may (or may not, I wasn't on the call for
> this) be premature, why can't a branch just be added under the existing repo
> if/when that's the consensus among the community?
>
> Lou
>
>
>
> On June 22, 2016 5:53:34 AM Paul Jakma <p...@jakma.org> wrote:
>
>> On Tue, 21 Jun 2016, Donald Sharp wrote:
>>
>>> Discussion on where to do the work next.  quagga-ce on github or on a
>>> branch in Savannah.  Decision was to start immediately working on a CE
>>> branch on github.
>>
>>
>> You need to change the name though.
>>
>> regards,
>> --
>> Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
>> Fortune:
>> Getting the job done is no excuse for not following the rules.
>>
>> Corollary:
>> Following the rules will not get the job done.
>>
>> ___
>> 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 15695] Re: [PATCH 31/89] lib, zebra: Block configuration and installation of martians

[Donald Sharp]

inet_pton in this case is only called once for every interface.  Is
that a problem?

donald

On Tue, Jun 21, 2016 at 8:29 AM, Paul Jakma <p...@jakma.org> wrote:
> On Fri, 11 Dec 2015, Donald Sharp wrote:
>
>> Block martian address configuration on an interface and also block from
>> getting installed into the zebra tables.
>>
>> Idea behind the fix was to not allow martian address configurations in
>> quagga and also block any connected martian address installation coming from
>> kernel
>
>
>> ---
>> lib/prefix.h  | 15 ++-
>> zebra/connected.c |  6 ++
>> zebra/interface.c | 12 
>> 3 files changed, 32 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/prefix.h b/lib/prefix.h
>> index a517d79..779c68e 100644
>> --- a/lib/prefix.h
>> +++ b/lib/prefix.h
>> @@ -234,13 +234,26 @@ extern void masklen2ip6 (const int, struct in6_addr
>> *);
>> extern void str2in6_addr (const char *, struct in6_addr *);
>> extern const char *inet6_ntoa (struct in6_addr);
>>
>> +static inline int ipv6_martian (struct in6_addr *addr)
>> +{
>> +  struct in6_addr localhost_addr;
>> +
>> +  inet_pton (AF_INET6, "::1", _addr);
>
>
> So every invocation has to do inet_pton??
>
>> +
>> +  if (IPV6_ADDR_SAME(_addr, addr))
>> +return 1;
>> +
>> +  return 0;
>> +}
>> +
>> #endif /* HAVE_IPV6 */
>>
>
> (Note, this is re-transmit of this comment).
>
> regards,
> --
> Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
> Fortune:
> Turn right here. No! NO! The OTHER right!

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

[quagga-dev 15693] Re: Quagga Monthly Meeting Notes

[Donald Sharp]

Michael -

It's clearly defined in the Release Process document.  Would a pointer
to that document be sufficient?

donald

On Wed, Jun 22, 2016 at 9:09 AM, Michael H Lambert <lamb...@psc.edu> wrote:
>> On 21 Jun 2016, at 10:59, Donald Sharp <sha...@cumulusnetworks.com> wrote:
>>
>> Discussion of the Quagga Maintainers Document:
>>
>> https://docs.google.com/document/d/19DZcT0cJUSYxVIFenHvGFhLLUmLTRFHuMNZcI7aUNGA/edit?usp=sharing
>>
>> The document is updated to reflect the discussion/decisions in this
>> meeting.  The highlights of the discussion:
>>
>> ...
>>
>> Discussion on where to do the work next.  quagga-ce on github or on a
>> branch in Savannah.  Decision was to start immediately working
>> on a CE branch on github.
>
> Could we please have a definition of CE in the document?  There is no clear 
> meaning from context.
>
> Thanks,
>
> Michael
>
>
>
> ___
> 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 15680] Quagga Monthly Meeting Notes

[Donald Sharp]

Discussion of the Quagga Maintainers Document:

https://docs.google.com/document/d/19DZcT0cJUSYxVIFenHvGFhLLUmLTRFHuMNZcI7aUNGA/edit?usp=sharing

The document is updated to reflect the discussion/decisions in this
meeting.  The highlights of the discussion:

  1) Maintainer per protocol.  This is maintained in a MAINTAINER document
  2) Different branches per protocol.  This was deemed to high cost.
Limit to one development branch
  3) Counter proposal from Vincent to have stricter roles and git only
committers.  Community is not large enough yet to move to this
methodology.
  4) Added a section on Sabbatical/extended leave
  5) 6 months inactivity to remove
  6) Violation of trust/Role - Resolved through current maintainers.

This document was approved for moving forward with

Discussion on where to do the work next.  quagga-ce on github or on a
branch in Savannah.  Decision was to start immediately working
on a CE branch on github.

donald

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

[quagga-dev 15638] Re: quagga ipc

[Donald Sharp]

You should look at lib/zclient.c and zebra/zserv.c.  As that the
answer is 'it depends'.

donald

On Fri, Jun 17, 2016 at 6:10 AM, dexter i  wrote:
> what is the ipc mechanism used in Quagga..?
>
> ___
> 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 15618] Re: [PATCH 16/16] vtysh: fix a memory leak in vtysh_client_execute

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Tue, Jun 14, 2016 at 2:07 PM, Christian Franke
<ch...@opensourcerouting.org> wrote:
> From: Christian Franke <nob...@nowhere.ws>
>
> buf is dynamically allocated and needs to be freed in the error handling
> path too.
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  vtysh/vtysh.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/vtysh/vtysh.c b/vtysh/vtysh.c
> index 625ab1c..2497f70 100644
> --- a/vtysh/vtysh.c
> +++ b/vtysh/vtysh.c
> @@ -124,6 +124,7 @@ vtysh_client_execute (struct vtysh_client *vclient, const 
> char *line, FILE *fp)
> {
>   fprintf (stderr, ERR_WHERE_STRING \
>"warning - pbuf beyond buffer end.\n");
> + XFREE(MTYPE_TMP, buf);
>   return CMD_WARNING;
> }
>
> --
> 2.8.0
>
>
> ___
> 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 15617] Re: [PATCH 15/16] vtysh: handle case if there is no match in "write terminal $daemon"

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Tue, Jun 14, 2016 at 2:07 PM, Christian Franke
<ch...@opensourcerouting.org> wrote:
> From: Christian Franke <nob...@nowhere.ws>
>
> While the DEFUN should match the list of clients registered in
> vtysh, it seems better to handle the case explicitly instead of
> relying on the client list and the DEFUN signature being in sync.
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  vtysh/vtysh.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/vtysh/vtysh.c b/vtysh/vtysh.c
> index 63b596a..625ab1c 100644
> --- a/vtysh/vtysh.c
> +++ b/vtysh/vtysh.c
> @@ -1840,6 +1840,9 @@ DEFUN (vtysh_write_terminal_daemon,
> break;
>  }
>
> +  if (i == array_size(vtysh_client))
> +return CMD_ERR_NO_MATCH;
> +
>ret = vtysh_client_execute(_client[i], "show running-config\n", 
> stdout);
>
>return ret;
> --
> 2.8.0
>
>
> ___
> 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 15616] Re: [PATCH 14/16] ripd: print md5 auth digest correctly

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Tue, Jun 14, 2016 at 2:07 PM, Christian Franke
<ch...@opensourcerouting.org> wrote:
> From: Christian Franke <nob...@nowhere.ws>
>
> The dump of the md5 hash was missing one byte of the hash.
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  ripd/ripd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ripd/ripd.c b/ripd/ripd.c
> index 82b1ada..c4548fe 100644
> --- a/ripd/ripd.c
> +++ b/ripd/ripd.c
> @@ -814,9 +814,9 @@ rip_packet_dump (struct rip_packet *packet, int size, 
> const char *sndrcv)
>   zlog_debug ("  family 0x%X type %d (MD5 data)",
>  ntohs (rte->family), ntohs (rte->tag));
>   zlog_debug ("MD5: %02X%02X%02X%02X%02X%02X%02X%02X"
> -"%02X%02X%02X%02X%02X%02X%02X",
> +"%02X%02X%02X%02X%02X%02X%02X%02X",
>   p[0], p[1], p[2], p[3], p[4], p[5], p[6],
> - p[7], p[9], p[10], p[11], p[12], p[13],
> + p[7], p[8], p[9], p[10], p[11], p[12], p[13],
>   p[14], p[15]);
> }
>   else
> --
> 2.8.0
>
>
> ___
> 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 15615] Re: [PATCH 13/16] pimd: don't leak original_s_route on error

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Tue, Jun 14, 2016 at 2:07 PM, Christian Franke
<ch...@opensourcerouting.org> wrote:
> From: Christian Franke <nob...@nowhere.ws>
>
> original_s_route is allocated on the heap and was not freed during the
> error case.
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  pimd/pim_static.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/pimd/pim_static.c b/pimd/pim_static.c
> index cbbcaaa..4038c68 100644
> --- a/pimd/pim_static.c
> +++ b/pimd/pim_static.c
> @@ -194,6 +194,10 @@ int pim_static_add(struct interface *iif, struct 
> interface *oif, struct in_addr
>   pim_static_route_free(s_route);
>}
>
> +  if (original_s_route) {
> + pim_static_route_free(original_s_route);
> +  }
> +
>return -1;
> }
>
> --
> 2.8.0
>
>
> ___
> 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 15614] Re: RFC: plugin (DSO) + hook support

[Donald Sharp]

I personally don't see allot of value in making snmp support runtime
-vs- compile time, but as a proof of concept I think it's fine for
what it is.

I do see value in shared libraries though.

Should we be thinking a bit bigger?  Could we modify the protocols to
all be shared libraries that could be loaded and then modify
watchquagga( or some other daemon ) and vtysh to be able to auto start
the daemons as shared libraries when the appropriate cli comes in?

donald

On Tue, Jun 14, 2016 at 1:59 PM, David Lamparter
 wrote:
> Hi all,
>
>
> this series contains support for loading dynamic modules (DSOs) that contain
> additional functionality.  bgpd's SNMP support is the test target.
>
> THIS IS AN UNFINISHED VERSION TO INVITE FEEDBACK.
>
> In the "big picture", there are some very broad topics that are non-trivial,
> first and foremost interaction of plugin's DEFUNs with config saving and
> startup.  In the current version, the patchset only supports loading DSOs on
> the command line, i.e. before config load.  That means all config works as
> usual.  However, if you remove a module from startup parameters, leftover
> config statements may result in startup failure.  Not sure if this is a real
> problem...
>
> FWIW, loading modules from the config wouldn't be much of a problem, as long
> as the plugin-loading statements get pushed all the way to the top of the
> config.  That way, they'd be loaded before their respective config blocks are
> reached.
>
> Also, after unloading a module, config writes wouldn't include its config
> anymore.  The on-disk config file either has both the "load plugin" command
> and the plugin's config (i.e. before-removal config), or would have neither
> (as written out by a "write mem" after removing the module).
>
> That said, I haven't implemented unloading (or uninstalling hooks) yet :)
>
>
> Cheers,
>
> -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 15602] Re: [PATCH 12/16] isisd: Fix size of malloc

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Tue, Jun 14, 2016 at 2:07 PM, Christian Franke <
ch...@opensourcerouting.org> wrote:

> From: Christian Franke <nob...@nowhere.ws>
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  isisd/isis_routemap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/isisd/isis_routemap.c b/isisd/isis_routemap.c
> index 3e0ab04..3443a0a 100644
> --- a/isisd/isis_routemap.c
> +++ b/isisd/isis_routemap.c
> @@ -230,7 +230,7 @@ route_set_metric_compile(const char *arg)
>if (arg[0] == '\0' || *endp != '\0' || metric > MAX_WIDE_PATH_METRIC)
>  return NULL;
>
> -  ret = XCALLOC(MTYPE_ROUTE_MAP_COMPILED, sizeof(ret));
> +  ret = XCALLOC(MTYPE_ROUTE_MAP_COMPILED, sizeof(*ret));
>*ret = metric;
>
>return ret;
> --
> 2.8.0
>
>
> ___
> 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 15601] Re: [PATCH 11/16] isisd: fix an error that was probably a result of copypasting

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Tue, Jun 14, 2016 at 2:07 PM, Christian Franke <
ch...@opensourcerouting.org> wrote:

> From: Christian Franke <nob...@nowhere.ws>
>
> The code should check for the existance of the correct list prior to
> accessing it.
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  isisd/isis_circuit.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/isisd/isis_circuit.c b/isisd/isis_circuit.c
> index a48afd2..0b5f5f1 100644
> --- a/isisd/isis_circuit.c
> +++ b/isisd/isis_circuit.c
> @@ -993,7 +993,7 @@ isis_circuit_print_vty (struct isis_circuit *circuit,
> struct vty *vty,
>vty_out(vty, "  %s%s", buf, VTY_NEWLINE);
>  }
>  }
> -  if (circuit->ipv6_link && listcount(circuit->ipv6_non_link) > 0)
> +  if (circuit->ipv6_non_link && listcount(circuit->ipv6_non_link) > 0)
>  {
>vty_out(vty, "IPv6 Prefixes:%s", VTY_NEWLINE);
>for (ALL_LIST_ELEMENTS_RO(circuit->ipv6_non_link, node,
> ip_addr))
> --
> 2.8.0
>
>
> ___
> 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 15600] Re: [PATCH 10/16] ospf6d: fix off-by-one on display of spf reasons

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Tue, Jun 14, 2016 at 2:07 PM, Christian Franke <
ch...@opensourcerouting.org> wrote:

> From: Christian Franke <nob...@nowhere.ws>
>
> The loop should only iterate to array_size - 1.
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  ospf6d/ospf6_spf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ospf6d/ospf6_spf.c b/ospf6d/ospf6_spf.c
> index 6d2e536..c3431c3 100644
> --- a/ospf6d/ospf6_spf.c
> +++ b/ospf6d/ospf6_spf.c
> @@ -402,7 +402,7 @@ void ospf6_spf_reason_string (unsigned int reason,
> char *buf, int size)
>if (!buf)
>  return;
>
> -  for (bit = 0; bit <= (sizeof(ospf6_spf_reason_str) / sizeof(char *));
> bit++)
> +  for (bit = 0; bit < array_size(ospf6_spf_reason_str); bit++)
>  {
>if ((reason & (1 << bit)) && (len < size))
> {
> --
> 2.8.0
>
>
> ___
> 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 15599] Re: [PATCH 09/16] ospf6d: don't access nexthops out of bounds

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Tue, Jun 14, 2016 at 2:07 PM, Christian Franke <
ch...@opensourcerouting.org> wrote:

> From: Christian Franke <nob...@nowhere.ws>
>
> Given that the && is evaluated lazily from left to right,
> i < OSPF6_MULTI_PATH_LIMIT should be checked prior to calling
> ospf6_nexthop_is_set on the array element, not the other way around.
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  ospf6d/ospf6_intra.c |  4 ++--
>  ospf6d/ospf6_route.c |  8 
>  ospf6d/ospf6_spf.c   | 12 ++--
>  3 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/ospf6d/ospf6_intra.c b/ospf6d/ospf6_intra.c
> index 6606c96..f003a80 100644
> --- a/ospf6d/ospf6_intra.c
> +++ b/ospf6d/ospf6_intra.c
> @@ -1314,8 +1314,8 @@ ospf6_intra_prefix_lsa_add (struct ospf6_lsa *lsa)
>  }
>else
>  {
> -  for (i = 0; ospf6_nexthop_is_set (_entry->nexthop[i]) &&
> -   i < OSPF6_MULTI_PATH_LIMIT; i++)
> +  for (i = 0; i < OSPF6_MULTI_PATH_LIMIT &&
> +   ospf6_nexthop_is_set (_entry->nexthop[i]); i++)
>  ospf6_nexthop_copy (>nexthop[i],
> _entry->nexthop[i]);
>  }
>
> diff --git a/ospf6d/ospf6_route.c b/ospf6d/ospf6_route.c
> index 5057556..07a4e09 100644
> --- a/ospf6d/ospf6_route.c
> +++ b/ospf6d/ospf6_route.c
> @@ -821,8 +821,8 @@ ospf6_route_show (struct vty *vty, struct ospf6_route
> *route)
> OSPF6_PATH_TYPE_SUBSTR (route->path.type),
> destination, nexthop, IFNAMSIZ, ifname, duration, VNL);
>
> -  for (i = 1; ospf6_nexthop_is_set (>nexthop[i]) &&
> -   i < OSPF6_MULTI_PATH_LIMIT; i++)
> +  for (i = 1; i < OSPF6_MULTI_PATH_LIMIT &&
> +   ospf6_nexthop_is_set (>nexthop[i]); i++)
>  {
>/* nexthop */
>inet_ntop (AF_INET6, >nexthop[i].address, nexthop,
> @@ -918,8 +918,8 @@ ospf6_route_show_detail (struct vty *vty, struct
> ospf6_route *route)
>
>/* Nexthops */
>vty_out (vty, "Nexthop:%s", VNL);
> -  for (i = 0; ospf6_nexthop_is_set (>nexthop[i]) &&
> -   i < OSPF6_MULTI_PATH_LIMIT; i++)
> +  for (i = 0; i < OSPF6_MULTI_PATH_LIMIT &&
> +   ospf6_nexthop_is_set (>nexthop[i]); i++)
>  {
>/* nexthop */
>inet_ntop (AF_INET6, >nexthop[i].address, nexthop,
> diff --git a/ospf6d/ospf6_spf.c b/ospf6d/ospf6_spf.c
> index 858398e..6d2e536 100644
> --- a/ospf6d/ospf6_spf.c
> +++ b/ospf6d/ospf6_spf.c
> @@ -307,8 +307,8 @@ ospf6_spf_install (struct ospf6_vertex *v,
>if (IS_OSPF6_DEBUG_SPF (PROCESS))
>  zlog_debug ("  another path found, merge");
>
> -  for (i = 0; ospf6_nexthop_is_set (>nexthop[i]) &&
> -   i < OSPF6_MULTI_PATH_LIMIT; i++)
> +  for (i = 0; i < OSPF6_MULTI_PATH_LIMIT &&
> +   ospf6_nexthop_is_set (>nexthop[i]); i++)
>  {
>for (j = 0; j < OSPF6_MULTI_PATH_LIMIT; j++)
>  {
> @@ -356,8 +356,8 @@ ospf6_spf_install (struct ospf6_vertex *v,
>route->path.options[1] = v->options[1];
>route->path.options[2] = v->options[2];
>
> -  for (i = 0; ospf6_nexthop_is_set (>nexthop[i]) &&
> -   i < OSPF6_MULTI_PATH_LIMIT; i++)
> +  for (i = 0; i < OSPF6_MULTI_PATH_LIMIT &&
> +   ospf6_nexthop_is_set (>nexthop[i]); i++)
>  ospf6_nexthop_copy (>nexthop[i], >nexthop[i]);
>
>if (v->parent)
> @@ -499,8 +499,8 @@ ospf6_spf_calculation (u_int32_t router_id,
>  ospf6_nexthop_calc (w, v, lsdesc);
>else
>  {
> -  for (i = 0; ospf6_nexthop_is_set (>nexthop[i]) &&
> -   i < OSPF6_MULTI_PATH_LIMIT; i++)
> +  for (i = 0; i < OSPF6_MULTI_PATH_LIMIT &&
> +   ospf6_nexthop_is_set (>nexthop[i]); i++)
>  ospf6_nexthop_copy (>nexthop[i], >nexthop[i]);
>  }
>
> --
> 2.8.0
>
>
> ___
> 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 15598] Re: [PATCH 08/16] ospfd: fix double assignment in ospf_vl_set_timers

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Tue, Jun 14, 2016 at 2:07 PM, Christian Franke <
ch...@opensourcerouting.org> wrote:

> From: Christian Franke <nob...@nowhere.ws>
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  ospfd/ospf_vty.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ospfd/ospf_vty.c b/ospfd/ospf_vty.c
> index fb17dff..a118794 100644
> --- a/ospfd/ospf_vty.c
> +++ b/ospfd/ospf_vty.c
> @@ -886,7 +886,7 @@ static int
>  ospf_vl_set_timers (struct ospf_vl_data *vl_data,
> struct ospf_vl_config_data *vl_config)
>  {
> -  struct interface *ifp = ifp = vl_data->vl_oi->ifp;
> +  struct interface *ifp = vl_data->vl_oi->ifp;
>/* Virtual Link data initialised to defaults, so only set
>   if a value given */
>if (vl_config->hello_interval)
> --
> 2.8.0
>
>
> ___
> 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 15589] Re: [PATCH 07/16] bgpd: fix memory leaks in show commands

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Tue, Jun 14, 2016 at 2:07 PM, Christian Franke <
ch...@opensourcerouting.org> wrote:

> From: Christian Franke <nob...@nowhere.ws>
>
> sockunion_str2su allocates a struct sockunion that used to be leaked
> in the show commands. Use str2sockunion and keep the information
> on the stack instead.
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  bgpd/bgp_encap.c   | 38 +-
>  bgpd/bgp_mplsvpn.c | 18 --
>  bgpd/bgp_route.c   | 10 ++
>  3 files changed, 31 insertions(+), 35 deletions(-)
>
> diff --git a/bgpd/bgp_encap.c b/bgpd/bgp_encap.c
> index 1a09ba6..73ab8958 100644
> --- a/bgpd/bgp_encap.c
> +++ b/bgpd/bgp_encap.c
> @@ -649,24 +649,23 @@ DEFUN (show_bgp_ipv4_encap_neighbor_routes,
> "Neighbor to display information about\n"
> "Display routes learned from neighbor\n")
>  {
> -  union sockunion *su;
> +  union sockunion su;
>struct peer *peer;
> -
> -  su = sockunion_str2su (argv[0]);
> -  if (su == NULL)
> +
> +  if (str2sockunion(argv[0], ))
>  {
>vty_out (vty, "Malformed address: %s%s", argv[0], VTY_NEWLINE);
> return CMD_WARNING;
>  }
>
> -  peer = peer_lookup (NULL, su);
> +  peer = peer_lookup (NULL, );
>if (! peer || ! peer->afc[AFI_IP][SAFI_ENCAP])
>  {
>vty_out (vty, "%% No such neighbor or address family%s",
> VTY_NEWLINE);
>return CMD_WARNING;
>  }
>
> -  return bgp_show_encap (vty, AFI_IP, NULL, bgp_show_type_neighbor, su,
> 0);
> +  return bgp_show_encap (vty, AFI_IP, NULL, bgp_show_type_neighbor, ,
> 0);
>  }
>
>  DEFUN (show_bgp_ipv6_encap_neighbor_routes,
> @@ -680,24 +679,23 @@ DEFUN (show_bgp_ipv6_encap_neighbor_routes,
> "Neighbor to display information about\n"
> "Display routes learned from neighbor\n")
>  {
> -  union sockunion *su;
> +  union sockunion su;
>struct peer *peer;
>
> -  su = sockunion_str2su (argv[0]);
> -  if (su == NULL)
> +  if (str2sockunion(argv[0], ))
>  {
>vty_out (vty, "Malformed address: %s%s", argv[0], VTY_NEWLINE);
> return CMD_WARNING;
>  }
>
> -  peer = peer_lookup (NULL, su);
> +  peer = peer_lookup (NULL, );
>if (! peer || ! peer->afc[AFI_IP6][SAFI_ENCAP])
>  {
>vty_out (vty, "%% No such neighbor or address family%s",
> VTY_NEWLINE);
>return CMD_WARNING;
>  }
>
> -  return bgp_show_encap (vty, AFI_IP6, NULL, bgp_show_type_neighbor, su,
> 0);
> +  return bgp_show_encap (vty, AFI_IP6, NULL, bgp_show_type_neighbor, ,
> 0);
>  }
>
>  DEFUN (show_bgp_ipv4_encap_rd_neighbor_routes,
> @@ -715,7 +713,7 @@ DEFUN (show_bgp_ipv4_encap_rd_neighbor_routes,
> "Display routes learned from neighbor\n")
>  {
>int ret;
> -  union sockunion *su;
> +  union sockunion su;
>struct peer *peer;
>struct prefix_rd prd;
>
> @@ -726,21 +724,20 @@ DEFUN (show_bgp_ipv4_encap_rd_neighbor_routes,
>return CMD_WARNING;
>  }
>
> -  su = sockunion_str2su (argv[1]);
> -  if (su == NULL)
> +  if (str2sockunion(argv[1], ))
>  {
>vty_out (vty, "Malformed address: %s%s", argv[1], VTY_NEWLINE);
> return CMD_WARNING;
>  }
>
> -  peer = peer_lookup (NULL, su);
> +  peer = peer_lookup (NULL, );
>if (! peer || ! peer->afc[AFI_IP][SAFI_ENCAP])
>  {
>vty_out (vty, "%% No such neighbor or address family%s",
> VTY_NEWLINE);
>return CMD_WARNING;
>  }
>
> -  return bgp_show_encap (vty, AFI_IP, , bgp_show_type_neighbor, su,
> 0);
> +  return bgp_show_encap (vty, AFI_IP, , bgp_show_type_neighbor, ,
> 0);
>  }
>
>  DEFUN (show_bgp_ipv6_encap_rd_neighbor_routes,
> @@ -758,7 +755,7 @@ DEFUN (show_bgp_ipv6_encap_rd_neighbor_routes,
> "Display routes learned from neighbor\n")
>  {
>int ret;
> -  union sockunion *su;
> +  union sockunion su;
>struct peer *peer;
>struct prefix_rd prd;
>
> @@ -769,21 +766,20 @@ DEFUN (show_bgp_ipv6_encap_rd_neighbor_routes,
>return CMD_WARNING;
>  }
>
> -  su = sockunion_str2su (argv[1]);
> -  if (su == NULL)
> +  if (str2sockunion(argv[1], ))
>  {
>vty_out (vty, "Malformed address: %s%s", argv[1], VTY_NEWLINE);
> return CMD_WARNING;
>  }
>
> -  peer = peer_lookup (NULL, su);
> +  peer = peer_lookup (NULL, );
>if (! peer || ! peer->afc[AFI_IP6][S

[quagga-dev 15587] Re: [PATCH 06/16] bgpd: fix off-by-one in attribute flags handling

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Tue, Jun 14, 2016 at 2:07 PM, Christian Franke <
ch...@opensourcerouting.org> wrote:

> From: Christian Franke <nob...@nowhere.ws>
>
> bgp_attr_flag_invalid can access beyond the last element of
> attr_flags_values.
> Fix this by initializing attr_flags_values_max to the correct value.
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  bgpd/bgp_attr.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/bgpd/bgp_attr.c b/bgpd/bgp_attr.c
> index f34e649..95c35fb 100644
> --- a/bgpd/bgp_attr.c
> +++ b/bgpd/bgp_attr.c
> @@ -998,8 +998,7 @@ const u_int8_t attr_flags_values [] = {
>[BGP_ATTR_AS4_PATH] = BGP_ATTR_FLAG_OPTIONAL |
> BGP_ATTR_FLAG_TRANS,
>[BGP_ATTR_AS4_AGGREGATOR] =   BGP_ATTR_FLAG_OPTIONAL |
> BGP_ATTR_FLAG_TRANS,
>  };
> -static const size_t attr_flags_values_max =
> -  sizeof (attr_flags_values) / sizeof (attr_flags_values[0]);
> +static const size_t attr_flags_values_max = array_size(attr_flags_values)
> - 1;
>
>  static int
>  bgp_attr_flag_invalid (struct bgp_attr_parser_args *args)
> --
> 2.8.0
>
>
> ___
> 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 15585] Re: [PATCH 04/16] bgpd: fix bgp_table_stats for mpls vpn

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Tue, Jun 14, 2016 at 2:06 PM, Christian Franke <
ch...@opensourcerouting.org> wrote:

> From: Christian Franke <nob...@nowhere.ws>
>
> bgpd uses an internal value SAFI_MPLS_VPN == 4 to index the information
> related to mpls vpn, while the IANA safi value is
> SAFI_MPLS_LABELED_VPN == 128. To access the bgp_table_stats, the internal
> value has to be used, not the wire-format value.
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  bgpd/bgp_route.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bgpd/bgp_route.c b/bgpd/bgp_route.c
> index c364372..2fd1675 100644
> --- a/bgpd/bgp_route.c
> +++ b/bgpd/bgp_route.c
> @@ -11848,7 +11848,7 @@ bgp_table_stats_vty (struct vty *vty, const char
> *name,
> safi = SAFI_UNICAST;
> break;
> case 'v':
> -   safi =  SAFI_MPLS_LABELED_VPN;
> +   safi =  SAFI_MPLS_VPN;
> break;
> case 'e':
> safi = SAFI_ENCAP;
> --
> 2.8.0
>
>
> ___
> 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 15583] Re: [PATCH 02/16] bgpd: setting nexthop doesn't need inet_pton

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Tue, Jun 14, 2016 at 2:06 PM, Christian Franke <
ch...@opensourcerouting.org> wrote:

> From: Christian Franke <nob...@nowhere.ws>
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  bgpd/bgp_routemap.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/bgpd/bgp_routemap.c b/bgpd/bgp_routemap.c
> index 39fa08c..c781ff1 100644
> --- a/bgpd/bgp_routemap.c
> +++ b/bgpd/bgp_routemap.c
> @@ -1990,7 +1990,6 @@ route_set_ipv6_nexthop_peer (void *rule, struct
> prefix *prefix,
>struct in6_addr peer_address;
>struct bgp_info *bgp_info;
>struct peer *peer;
> -  char peer_addr_buf[INET6_ADDRSTRLEN];
>
>if (type == RMAP_BGP)
>  {
> @@ -2003,19 +2002,13 @@ route_set_ipv6_nexthop_peer (void *rule, struct
> prefix *prefix,
>   && peer->su_remote
>   && sockunion_family (peer->su_remote) == AF_INET6)
> {
> - inet_pton (AF_INET6, sockunion2str (peer->su_remote,
> - peer_addr_buf,
> - INET6_ADDRSTRLEN),
> -_address);
> + peer_address = peer->su_remote->sin6.sin6_addr;
> }
>else if (CHECK_FLAG (peer->rmap_type, PEER_RMAP_TYPE_OUT)
>&& peer->su_local
>&& sockunion_family (peer->su_local) == AF_INET6)
> {
> - inet_pton (AF_INET, sockunion2str (peer->su_local,
> -peer_addr_buf,
> -INET6_ADDRSTRLEN),
> -_address);
> + peer_address = peer->su_local->sin6.sin6_addr;
> }
>
>if (IN6_IS_ADDR_LINKLOCAL(_address))
> --
> 2.8.0
>
>
> ___
> 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 15570] Re: Bug Fixes Fast Lane

[Donald Sharp]

Jafar -

I would point out that the new process as outlined, is that once a bug
get's Acked is immediately placed in master by a maintainer.

donald

On Tue, Jun 14, 2016 at 3:03 PM, Jafar Al-Gharaibeh 
wrote:

> Greetings,
>
>  I know the Quagga community is  in the process of improving patch
> handling/reviewing to speed up things, but one thing I would love to see
> happening is a "super" fast lane for bug fixes. We see a lot of one liner
> (maybe a few in some case) patches that are usually bug fixes being pushed
> back and handled the same way a feature patch with hundreds or even
> thousands lines of code. The vast majority of bug fixes are trivial but
> very important to users and developers. I see it happens a lot where the
> same fix is submitted over and over again by different developers! we could
> use their time in better ways :)
>
>  Bug fixes should go into master within few days at the latest, no need to
> hold them off. Maybe the first ACK should trigger such patches to be queued
> up to go into master as soon as one of the maintainers get a chance to do
> it.
>
> Regards,
> Jafar
>
> ___
> 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 15542] Re: [PATCH] vtysh: auto-generated vtysh_cmd.c file should depend on its creator

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Tue, Jun 14, 2016 at 10:06 AM, Paul Jakma <paul.ja...@hpe.com> wrote:

> ---
>  vtysh/Makefile.am | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/vtysh/Makefile.am b/vtysh/Makefile.am
> index d347735..e44cd49 100644
> --- a/vtysh/Makefile.am
> +++ b/vtysh/Makefile.am
> @@ -36,6 +36,5 @@ vtysh_cmd_FILES = $(top_srcdir)/bgpd/*.c
> $(top_srcdir)/isisd/*.c \
>   $(top_srcdir)/zebra/zebra_routemap.c \
>   $(top_srcdir)/zebra/zebra_fpm.c
>
> -vtysh_cmd.c: $(vtysh_cmd_FILES)
> -   ./$(EXTRA_DIST) $(vtysh_cmd_FILES) > vtysh_cmd.c
> -
> +vtysh_cmd.c: $(vtysh_cmd_FILES) extract.pl
> +   ./extract.pl $(vtysh_cmd_FILES) > vtysh_cmd.c
> --
> 2.5.5
>
>
> ___
> 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 15540] Re: Round 8

[Donald Sharp]

I would recommend reverting:

ceecc7e *: Consolidate all double VIEW_NODE and ENABLE_NODE's
0dbe0d2 lib: Consolidate VIEW_NODE to be ENABLE_NODE as well

They are the cause of this breakage.

Shall I do this?

thanks!

donald

On Tue, Jun 14, 2016 at 10:45 AM, Donald Sharp <sha...@cumulusnetworks.com>
wrote:

> I'm getting this crash in zebra:
>
> root@robot:/etc/quagga# /usr/lib/quagga/zebra --daemon -A 127.0.0.1
> Aborted (core dumped)
> root@robot:/etc/quagga#
>
> (gdb) r -A 127.0.0.1
> Starting program: /usr/lib/quagga/zebra -A 127.0.0.1
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
> Program received signal SIGABRT, Aborted.
> 0x777e0418 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x777e0418 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x777e201a in __GI_abort () at abort.c:89
> #2  0x77ba5964 in _zlog_assert_failed 
> (assertion=assertion@entry=0x77bb587d
> "0",
> file=file@entry=0x77bb13bf "command.c", line=line@entry=620,
> function=function@entry=0x77bb3820 <__func__.10624>
> "install_element") at log.c:669
> #3  0x77b959df in install_element (ntype=,
> cmd=0x77dcde00 ) at command.c:620
> #4  0x77b95ffd in cmd_init (terminal=terminal@entry=1) at
> command.c:4165
> #5  0x0040bdc0 in main (argc=3, argv=0x7fffe608) at main.c:404
> (gdb)
>
> donald
>
> On Tue, Jun 14, 2016 at 10:42 AM, Lou Berger <lber...@labn.net> wrote:
>
>> Paul,
>>
>> On 6/14/2016 9:02 AM, Paul Jakma wrote:
>> > Note: I've had a good few conflicts on 'install_element' lines, due to
>> > various patches adding/removing commands with the restricted node and
>> > 'auto-install view commands into enable' patches. I didn't look too
>> > closely as to whether I resolved them correctly.
>> Looks like there's more to do in bgp...
>>
>> #0  0x0034e0232625 in raise () from /lib64/libc.so.6
>> #1  0x0034e0233e05 in abort () from /lib64/libc.so.6
>> #2  0x004cf7ce in _zlog_assert_failed (assertion=0x52ce72 "0",
>> file=0x52ce68 "command.c", line=620, function=0x52fb80
>> "install_element")
>> at log.c:669
>> #3  0x004b02ae in install_element (ntype=ENABLE_NODE,
>> cmd=0x7736c0)
>> at command.c:620
>> #4  0x004b02bf in install_element (ntype=VIEW_NODE, cmd=0x7736c0)
>> at command.c:623
>> #5  0x004b6e5d in cmd_init (terminal=1) at command.c:4165
>> #6  0x00421f8f in main (argc=1, argv=0x7fffe5d8) at
>> bgp_main.c:452
>>
>> Lou
>>
>>
>>
>> ___
>> 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 15538] Re: Round 8

[Donald Sharp]

I'm getting this crash in zebra:

root@robot:/etc/quagga# /usr/lib/quagga/zebra --daemon -A 127.0.0.1
Aborted (core dumped)
root@robot:/etc/quagga#

(gdb) r -A 127.0.0.1
Starting program: /usr/lib/quagga/zebra -A 127.0.0.1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGABRT, Aborted.
0x777e0418 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x777e0418 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x777e201a in __GI_abort () at abort.c:89
#2  0x77ba5964 in _zlog_assert_failed
(assertion=assertion@entry=0x77bb587d
"0",
file=file@entry=0x77bb13bf "command.c", line=line@entry=620,
function=function@entry=0x77bb3820 <__func__.10624>
"install_element") at log.c:669
#3  0x77b959df in install_element (ntype=,
cmd=0x77dcde00 ) at command.c:620
#4  0x77b95ffd in cmd_init (terminal=terminal@entry=1) at
command.c:4165
#5  0x0040bdc0 in main (argc=3, argv=0x7fffe608) at main.c:404
(gdb)

donald

On Tue, Jun 14, 2016 at 10:42 AM, Lou Berger  wrote:

> Paul,
>
> On 6/14/2016 9:02 AM, Paul Jakma wrote:
> > Note: I've had a good few conflicts on 'install_element' lines, due to
> > various patches adding/removing commands with the restricted node and
> > 'auto-install view commands into enable' patches. I didn't look too
> > closely as to whether I resolved them correctly.
> Looks like there's more to do in bgp...
>
> #0  0x0034e0232625 in raise () from /lib64/libc.so.6
> #1  0x0034e0233e05 in abort () from /lib64/libc.so.6
> #2  0x004cf7ce in _zlog_assert_failed (assertion=0x52ce72 "0",
> file=0x52ce68 "command.c", line=620, function=0x52fb80
> "install_element")
> at log.c:669
> #3  0x004b02ae in install_element (ntype=ENABLE_NODE, cmd=0x7736c0)
> at command.c:620
> #4  0x004b02bf in install_element (ntype=VIEW_NODE, cmd=0x7736c0)
> at command.c:623
> #5  0x004b6e5d in cmd_init (terminal=1) at command.c:4165
> #6  0x00421f8f in main (argc=1, argv=0x7fffe5d8) at
> bgp_main.c:452
>
> Lou
>
>
>
> ___
> 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 15524] Re: [PATCH 3/4] lib: AgentX: use threads instead of eventloop hack

[Donald Sharp]

As a point of discussion:

Why shouldn't we drop support for snmp:

1) The license for quagga is incompatible with the snmp licensing
(Yes I'm aware that some people/distributions don't care)
2) There hasn't been any recent developments in quagga for snmp, nor does
it look like it's really on anyone's radar.
3) snmp support in quagga is incomplete in that I'm not aware of a mib that
is even fully implemented.  Leaving people who do attempt to use it with a
false impression of usability
4) new features being added to Quagga are not taking snmp into account.
5) The library is stuck with select mechanics and don't allow more than 1k
fd's.  This prevents easy moving forward to implement better epoll/kpoll
semantics.

thoughts?

donald

On Mon, Jun 13, 2016 at 11:29 AM, David Lamparter <
equi...@opensourcerouting.org> wrote:

> AgentX fd/timeout handling is rather hackishly monkeyed into thread.c.
> Replace with code that uses plain thread_* functions.
>
> NB: Net-SNMP's API rivals Quagga's in terms of age and absence of
> documentation.  netsnmp_check_outstanding_agent_requests() in particular
> seems to be unused and is therefore untested.
>
> The most useful documentation on this is actually the blog post Vincent
> Bernat wrote when he originally integrated this into lldpd and Quagga:
> https://vincent.bernat.im/en/blog/2012-snmp-event-loop.html
>
> Signed-off-by: David Lamparter 
> ---
>  lib/agentx.c | 104
> ++-
>  lib/thread.c |  52 ++
>  2 files changed, 105 insertions(+), 51 deletions(-)
>
> diff --git a/lib/agentx.c b/lib/agentx.c
> index be6b432..5d7d057 100644
> --- a/lib/agentx.c
> +++ b/lib/agentx.c
> @@ -24,11 +24,108 @@
>  #if defined HAVE_SNMP && defined SNMP_AGENTX
>  #include 
>  #include 
> +#include 
> +#include 
>
>  #include "command.h"
>  #include "smux.h"
>
> -int agentx_enabled = 0;
> +static int agentx_enabled = 0;
> +
> +static struct thread_master *agentx_tm;
> +static struct thread *timeout_thr = NULL;
> +static struct list *events = NULL;
> +
> +static void agentx_events_update(void);
> +
> +static int
> +agentx_timeout(struct thread *t)
> +{
> +  timeout_thr = NULL;
> +
> +  snmp_timeout ();
> +  run_alarms ();
> +  netsnmp_check_outstanding_agent_requests ();
> +  agentx_events_update ();
> +  return 0;
> +}
> +
> +static int
> +agentx_read(struct thread *t)
> +{
> +  fd_set fds;
> +  struct listnode *ln = THREAD_ARG (t);
> +  list_delete_node (events, ln);
> +
> +  FD_ZERO ();
> +  FD_SET (THREAD_FD (t), );
> +  snmp_read ();
> +
> +  netsnmp_check_outstanding_agent_requests ();
> +  agentx_events_update ();
> +  return 0;
> +}
> +
> +static void
> +agentx_events_update(void)
> +{
> +  int maxfd = 0;
> +  int block = 1;
> +  struct timeval timeout = { .tv_sec = 0, .tv_usec = 0 };
> +  fd_set fds;
> +  struct listnode *ln;
> +  struct thread *thr;
> +  int fd, thr_fd;
> +
> +  THREAD_OFF (timeout_thr);
> +
> +  FD_ZERO ();
> +  snmp_select_info (, , , );
> +
> +  if (!block)
> +timeout_thr = thread_add_timer_tv (agentx_tm, agentx_timeout, NULL,
> );
> +
> +  ln = listhead (events);
> +  thr = ln ? listgetdata (ln) : NULL;
> +  thr_fd = thr ? THREAD_FD (thr) : -1;
> +
> +  /* "two-pointer" / two-list simultaneous iteration
> +   * ln/thr/thr_fd point to the next existing event listener to hit while
> +   * fd counts to catch up */
> +  for (fd = 0; fd < maxfd; fd++)
> +{
> +  /* caught up */
> +  if (thr_fd == fd)
> +{
> +  struct listnode *nextln = listnextnode (ln);
> +  if (!FD_ISSET (fd, ))
> +{
> +  thread_cancel (thr);
> +  list_delete_node (events, ln);
> +}
> +  ln = nextln;
> +  thr = ln ? listgetdata (ln) : NULL;
> +  thr_fd = thr ? THREAD_FD (thr) : -1;
> +}
> +  /* need listener, but haven't hit one where it would be */
> +  else if (FD_ISSET (fd, ))
> +{
> +  struct listnode *newln;
> +  thr = thread_add_read (agentx_tm, agentx_read, NULL, fd);
> +  newln = listnode_add_before (events, ln, thr);
> +  thr->arg = newln;
> +}
> +}
> +
> +  /* leftover event listeners at this point have fd > maxfd, delete them
> */
> +  while (ln)
> +{
> +  struct listnode *nextln = listnextnode (ln);
> +  thread_cancel (listgetdata (ln));
> +  list_delete_node (events, ln);
> +  ln = nextln;
> +}
> +}
>
>  /* AgentX node. */
>  static struct cmd_node agentx_node =
> @@ -77,6 +174,8 @@ DEFUN (agentx_enable,
>if (!agentx_enabled)
>  {
>init_snmp("quagga");
> +  events = list_new();
> +  agentx_events_update ();
>agentx_enabled = 1;
>return CMD_SUCCESS;
>  }
> @@ -99,6 +198,8 @@ DEFUN (no_agentx,
>  void
>  smux_init (struct thread_master *tm)
>  {
> +  agentx_tm = tm;
> +
>netsnmp_enable_subagent ();
>snmp_disable_log 

[quagga-dev 15522] Re: round 7, can you test?

[Donald Sharp]

Crash traceback that I saw:

Backtrace for 11 stack frames:
/usr/lib/libzebra.so.0(zlog_backtrace_sigsafe+0x2c)[0x7fa781d97bf8]
/usr/lib/libzebra.so.0(zlog_signal+0x2ba)[0x7fa781d9750a]
/usr/lib/libzebra.so.0(+0x3a3c6)[0x7fa781da13c6]
/lib/x86_64-linux-gnu/libc.so.6(+0x354a0)[0x7fa78138d4a0]
/usr/lib/quagga/ospf6d(ospf6_clean+0x10)[0x42b66a]
/usr/lib/quagga/ospf6d[0x40a064]
/usr/lib/libzebra.so.0(quagga_sigevent_process+0x45)[0x7fa781da11b1]
/usr/lib/libzebra.so.0(thread_fetch+0x27e)[0x7fa781d8c0fa]
/usr/lib/quagga/ospf6d(main+0x357)[0x40a3da]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fa781378830]
/usr/lib/quagga/ospf6d(_start+0x29)[0x409f59]
no thread information available


Useless I know.  I can't make it happen again and I'm not sure what I did
to make it happen.  I wasn't even using osp6d, it just happened to be
running.  So I wasn't paying a whole lot of attention to it.  None of the
patches that just got merged down into master should affect this either, so
it's probably a standing problem.  This has my vote for not holding
anything up.

donald




On Fri, Jun 10, 2016 at 2:30 PM, Paul Jakma  wrote:

> On Thu, 9 Jun 2016, Martin Winter wrote:
>
> 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.
>>
>
> Done. Some grumblings on IRC from Donald about seeing some ospf6d crashes.
>
> regards,
> --
> Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
> Fortune:
> I must have a prodigious quantity of mind; it takes me as much as a
> week sometimes to make it up.
> -- Mark Twain, "The Innocents Abroad"
>
>
> ___
> 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 15511] [PATCH 1/2] pimd: Fix of using uninitialized Memory

[Donald Sharp]

Valgrind is reporting that pimd is using uninitialized
memory for comparisons.  This commit addresses
the issues found there.

Signed-off-by: Donald Sharp <sha...@cumulusnetworks.com>
---
 pimd/pim_iface.c | 1 +
 pimd/pim_ifchannel.c | 7 +--
 pimd/pim_igmpv3.c| 5 -
 pimd/pim_pim.c   | 5 -
 4 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/pimd/pim_iface.c b/pimd/pim_iface.c
index 2533d0f..ddad6cb 100644
--- a/pimd/pim_iface.c
+++ b/pimd/pim_iface.c
@@ -107,6 +107,7 @@ struct pim_interface *pim_if_new(struct interface *ifp, int 
igmp, int pim)
   pim_ifp->igmp_socket_list = 0;
   pim_ifp->pim_neighbor_list = 0;
   pim_ifp->pim_ifchannel_list = 0;
+  pim_ifp->pim_generation_id = 0;
 
   /* list of struct igmp_sock */
   pim_ifp->igmp_socket_list = list_new();
diff --git a/pimd/pim_ifchannel.c b/pimd/pim_ifchannel.c
index e801f4e..ad97879 100644
--- a/pimd/pim_ifchannel.c
+++ b/pimd/pim_ifchannel.c
@@ -223,6 +223,11 @@ static struct pim_ifchannel *pim_ifchannel_new(struct 
interface *ifp,
   ch->t_ifjoin_prune_pending_timer = 0;
   ch->ifjoin_creation  = 0;
 
+  ch->ifassert_my_metric = pim_macro_ch_my_assert_metric_eval(ch);
+  ch->ifassert_winner_metric = pim_macro_ch_my_assert_metric_eval (ch);
+
+  ch->ifassert_winner.s_addr = 0;
+
   /* Assert state */
   ch->t_ifassert_timer   = 0;
   reset_ifassert_state(ch);
@@ -236,8 +241,6 @@ static struct pim_ifchannel *pim_ifchannel_new(struct 
interface *ifp,
   else
 PIM_IF_FLAG_UNSET_ASSERT_TRACKING_DESIRED(ch->flags);
 
-  ch->ifassert_my_metric = pim_macro_ch_my_assert_metric_eval(ch);
-
   /* Attach to list */
   listnode_add(pim_ifp->pim_ifchannel_list, ch);
 
diff --git a/pimd/pim_igmpv3.c b/pimd/pim_igmpv3.c
index 3657f2f..e5001f7 100644
--- a/pimd/pim_igmpv3.c
+++ b/pimd/pim_igmpv3.c
@@ -1670,14 +1670,9 @@ void pim_igmp_send_membership_query(struct igmp_group 
*group,
   querier_query_interval, qqic, checksum);
   }
 
-#if 0
   memset(, 0, sizeof(to));
-#endif
   to.sin_family = AF_INET;
   to.sin_addr = dst_addr;
-#if 0
-  to.sin_port = htons(0);
-#endif
   tolen = sizeof(to);
 
   sent = sendto(fd, query_buf, msg_size, MSG_DONTWAIT,
diff --git a/pimd/pim_pim.c b/pimd/pim_pim.c
index c522475..c52b0d3 100644
--- a/pimd/pim_pim.c
+++ b/pimd/pim_pim.c
@@ -473,14 +473,9 @@ int pim_msg_send(int fd,
   *(uint16_t *) PIM_MSG_HDR_OFFSET_CHECKSUM(pim_msg));
   }
 
-#if 0
   memset(, 0, sizeof(to));
-#endif
   to.sin_family = AF_INET;
   to.sin_addr = dst;
-#if 0
-  to.sin_port = htons(0);
-#endif
   tolen = sizeof(to);
 
   if (PIM_DEBUG_PIM_PACKETDUMP_SEND) {
-- 
2.7.4


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

[quagga-dev 15510] [PATCH 2/2] *: Fix warnings generated by clang

[Donald Sharp]

Clang is finding a new set of problems.
Fix them.

Signed-off-by: Donald Sharp <sha...@cumulusnetworks.com>
---
 bgpd/bgp_attr.c| 4 ++--
 bgpd/bgpd.h| 1 +
 lib/vty.c  | 2 +-
 zebra/rt_netlink.c | 2 +-
 4 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/bgpd/bgp_attr.c b/bgpd/bgp_attr.c
index f34e649..a9ecae6 100644
--- a/bgpd/bgp_attr.c
+++ b/bgpd/bgp_attr.c
@@ -1870,8 +1870,8 @@ bgp_attr_encap(
   }
 
   while (length >= 4) {
-uint16_t   subtype;
-uint16_t   sublength;
+uint16_t   subtype = BGP_ATTR_UNKNOWN;
+uint16_t   sublength = 0;
 struct bgp_attr_encap_subtlv *tlv;
 
 if (BGP_ATTR_ENCAP == type) {
diff --git a/bgpd/bgpd.h b/bgpd/bgpd.h
index 7665d9d..531d047 100644
--- a/bgpd/bgpd.h
+++ b/bgpd/bgpd.h
@@ -627,6 +627,7 @@ struct bgp_nlri
 #define BGP_OPEN_OPT_CAP 2
 
 /* BGP4 attribute type codes.  */
+#define BGP_ATTR_UNKNOWN 0
 #define BGP_ATTR_ORIGIN  1
 #define BGP_ATTR_AS_PATH 2
 #define BGP_ATTR_NEXT_HOP3
diff --git a/lib/vty.c b/lib/vty.c
index e4510f8..aafa271 100644
--- a/lib/vty.c
+++ b/lib/vty.c
@@ -423,7 +423,7 @@ vty_command (struct vty *vty, char *buf)
   snprintf(vty_str, sizeof(vty_str), "vty[??]@%s", vty->address);
   if (vty)
 for (i = 0; i < vector_active (vtyvec); i++)
-  if ((vty == vector_slot (vtyvec, i)))
+  if (vty == vector_slot (vtyvec, i))
 {
   snprintf(vty_str, sizeof(vty_str), "vty[%d]@%s",
  i, vty->address);
diff --git a/zebra/rt_netlink.c b/zebra/rt_netlink.c
index e4505de..b38c75d 100644
--- a/zebra/rt_netlink.c
+++ b/zebra/rt_netlink.c
@@ -1355,7 +1355,7 @@ rta_addattr_l (struct rtattr *rta, int maxlen, int type, 
void *data, int alen)
 
   len = RTA_LENGTH (alen);
 
-  if (RTA_ALIGN (rta->rta_len) + len > maxlen)
+  if ((int)RTA_ALIGN (rta->rta_len) + len > maxlen)
 return -1;
 
   subrta = (struct rtattr *) (((char *) rta) + RTA_ALIGN (rta->rta_len));
-- 
2.7.4


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

[quagga-dev 15507] Re: [PATCH] vtysh: send "no interface" command to all daemons that support it

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Thu, Jun 9, 2016 at 9:44 AM, Igor Ryzhov <iryz...@nfware.com> wrote:

> Signed-off-by: Igor Ryzhov <iryz...@nfware.com>
> ---
>  vtysh/vtysh.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/vtysh/vtysh.c b/vtysh/vtysh.c
> index 63b596a..7149dc3 100644
> --- a/vtysh/vtysh.c
> +++ b/vtysh/vtysh.c
> @@ -1314,8 +1314,7 @@ ALIAS_SH (VTYSH_ZEBRA,
>  "Interface's name\n"
>  VRF_CMD_HELP_STR)
>
> -/* TODO Implement "no interface command in isisd. */
> -DEFSH (VTYSH_ZEBRA|VTYSH_RIPD|VTYSH_RIPNGD|VTYSH_OSPFD|VTYSH_OSPF6D,
> +DEFSH (VTYSH_INTERFACE,
> vtysh_no_interface_cmd,
> "no interface IFNAME",
> NO_STR
> --
> 2.6.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 15486] Re: [PATCH] bgpd: bgp_update_receive ignores non present NLRI

[Donald Sharp]

Should we have the opportunity to log something here if we receive this
error condition?

donald

On Wed, Jun 8, 2016 at 2:37 AM, Philippe Guibert  wrote:

> Fixes 518a4b7eadcb "bgpd: Regularise bgp_update_receive,
> add missing notifies and checks"
> Error message "UPDATE with unsupported AFI/SAFI 0/0" is wrongly
> displayed for a packet which does not have the matching NLRI entry.
> The patch checks presence of nlri in bgp update message.
>
> Signed-off-by: Philippe Guibert 
> ---
>  bgpd/bgp_packet.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/bgpd/bgp_packet.c b/bgpd/bgp_packet.c
> index 740b0f1ce603..601d39d1c1ad 100644
> --- a/bgpd/bgp_packet.c
> +++ b/bgpd/bgp_packet.c
> @@ -1781,6 +1781,14 @@ bgp_update_receive (struct peer *peer, bgp_size_t
> size)
>/* Parse any given NLRIs */
>for (i = NLRI_UPDATE; i < NLRI_TYPE_MAX; i++)
>  {
> +  /* ignore empty nlri entries */
> +  if ((i == NLRI_WITHDRAW) && (withdraw_len == 0))
> +continue;
> +  else if ((i == NLRI_UPDATE) && (update_len == 0))
> +continue;
> +  else if ( ((i == NLRI_MP_UPDATE) || (i == NLRI_MP_WITHDRAW)) &&  \
> +(attribute_len == 0))
> +continue;
>/* We use afi and safi as indices into tables and what not.  It
> would
> * be impossible, at this time, to support unknown afi/safis.  And
> * anyway, the peer needs to be configured to enable the afi/safi
> --
> 2.1.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 15481] Re: [PATCH] zebra: make fpm netlink_route_info_fill more robust

[Donald Sharp]

I suspected this was a Static Analysis change.  I'd prefer (b), but don't
care enough really to complain if I got a (c) as well.

donald

On Tue, Jun 7, 2016 at 1:26 PM, Christian Franke <
ch...@opensourcerouting.org> wrote:

> On 06/07/2016 04:10 AM, Donald Sharp wrote:
> > Christian -
> >
> > How is this possible?  In zfpm_encode_route we set cmd == RTM_DELROUTE
> > if rib == NULL.
>
> Yes you are right, this seems not to be an issue in practice, I misread
> what zfpm_encode_route does, yesterday.
>
> The change came up from an issue found by coverity that boils down to
> this check that I removed:
>
> > -  if (rib)
> > -ri->rtm_protocol = netlink_proto_from_route_type (rib->type);
>
> Coverity infers from the existance of the check that rib might be NULL
> at that point and complains about rib being dereferenced later on,
> without any guard for NULL:
>
> >if ((rib->flags & ZEBRA_FLAG_BLACKHOLE) || (rib->flags &
> > ZEBRA_FLAG_REJECT))
> >  discard = 1;
>
> Given that we never have rib == NULL and cmd != RTM_DELROUTE the way
> that it's currently called, I see the following options:
>
> a) Leave it as is and mark the coverity issue as non-problematic and
>live with the code that is a bit misleading to read
> b) Remove the if (rib) guard
> c) Remove it and add an assert(rib != NULL)
>
> I am fine with either and would tend to go with c), but I am open to
> suggestions.
>
> -Christian
>
>
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15464] Re: [PATCH] bgpd: fix potential crash in community_list_dup_check

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Mon, Jun 6, 2016 at 4:22 PM, Christian Franke <
ch...@opensourcerouting.org> wrote:

> From: Christian Franke <nob...@nowhere.ws>
>
> extcommunity_list_set may set the ->config for an entry
> to NULL. In this case, the old code in community_list_dup_check
> would cause a NULL pointer dereference.
>
> Adjust the code so it behaves the same in the absence of NULL
> pointers and otherwise checks if both are NULL to determine
> equality.
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  bgpd/bgp_clist.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/bgpd/bgp_clist.c b/bgpd/bgp_clist.c
> index bb06028..1f1a4e7 100644
> --- a/bgpd/bgp_clist.c
> +++ b/bgpd/bgp_clist.c
> @@ -644,7 +644,10 @@ community_list_dup_check (struct community_list *list,
>break;
>  case COMMUNITY_LIST_EXPANDED:
>  case EXTCOMMUNITY_LIST_EXPANDED:
> -  if (strcmp (entry->config, new->config) == 0)
> +  if (entry->config && new->config
> +  && strcmp (entry->config, new->config) == 0)
> +return 1;
> +  if (!entry->config && !new->config)
>  return 1;
>break;
>  default:
> --
> 2.8.0
>
>
> ___
> 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 15462] Re: [PATCH] zebra: make fpm netlink_route_info_fill more robust

[Donald Sharp]

Christian -

How is this possible?  In zfpm_encode_route we set cmd == RTM_DELROUTE if
rib == NULL.

Is this setup for some new code?

donald

On Mon, Jun 6, 2016 at 4:04 PM, Christian Franke <
ch...@opensourcerouting.org> wrote:

> From: Christian Franke 
>
> Having an RTM_ADDROUTE with a rib == NULL would lead
> to a crash due to a NULL pointer dereference.
>
> Since an RTM_ADDROUTE without a rib object doesn't make
> much sense, print a warning and remove the concerned
> route instead.
>
> Signed-off-by: Christian Franke 
> ---
>  zebra/zebra_fpm_netlink.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/zebra/zebra_fpm_netlink.c b/zebra/zebra_fpm_netlink.c
> index 0173000..e2c6b8b 100644
> --- a/zebra/zebra_fpm_netlink.c
> +++ b/zebra/zebra_fpm_netlink.c
> @@ -251,11 +251,16 @@ netlink_route_info_fill (netlink_route_info_t *ri,
> int cmd,
> * An RTM_DELROUTE need not be accompanied by any nexthops,
> * particularly in our communication with the FPM.
> */
> -  if (cmd == RTM_DELROUTE && !rib)
> +  if (cmd == RTM_DELROUTE)
>  goto skip;
>
> -  if (rib)
> -ri->rtm_protocol = netlink_proto_from_route_type (rib->type);
> +  if (!rib)
> +{
> +  zlog_err("netlink_route_info_fill RTM_ADDROUTE called without rib
> info");
> +  return 0;
> +}
> +
> +  ri->rtm_protocol = netlink_proto_from_route_type (rib->type);
>
>if ((rib->flags & ZEBRA_FLAG_BLACKHOLE) || (rib->flags &
> ZEBRA_FLAG_REJECT))
>  discard = 1;
> --
> 2.8.0
>
>
> ___
> 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 15460] Re: CI Testresult: FAILED (Re: [quagga-dev, 15452, 3/3] pimd: Remove igmp_add_group_by_addr unneeded parameter)

[Donald Sharp]

Martin -

Looks like something went wrong with your test system?

donald

On Mon, Jun 6, 2016 at 9:40 PM,  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 .
>
> 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 15458] Re: [PATCH] isisd: exit if daemonizing fails

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Mon, Jun 6, 2016 at 3:13 PM, Christian Franke <
ch...@opensourcerouting.org> wrote:

> From: Christian Franke <nob...@nowhere.ws>
>
> The other daemons in Quagga exit with an error if they cannot fork.
> Change isisd to behave consistently.
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  isisd/isis_main.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/isisd/isis_main.c b/isisd/isis_main.c
> index 3a73087..02ea0d7 100644
> --- a/isisd/isis_main.c
> +++ b/isisd/isis_main.c
> @@ -355,8 +355,11 @@ main (int argc, char **argv, char **envp)
>  return(0);
>
>/* demonize */
> -  if (daemon_mode)
> -daemon (0, 0);
> +  if (daemon_mode && daemon (0, 0) < 0)
> +{
> +  zlog_err("IS-IS daemon failed: %s", strerror(errno));
> +  exit (1);
> +}
>
>/* Process ID file creation. */
>if (pid_file[0] != '\0')
> --
> 2.8.0
>
>
> ___
> 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 15455] Re: [PATCH] ospf6d: remove unused broken function

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Mon, Jun 6, 2016 at 3:49 PM, Christian Franke <
ch...@opensourcerouting.org> wrote:

> From: Christian Franke <nob...@nowhere.ws>
>
> ospf6_interface_if_del has not been in use since for quite some
> years and is broken. (Will crash ospf6d if oi->area == NULL)
>
> Since it is not used, just remove it.
>
> Signed-off-by: Christian Franke <ch...@opensourcerouting.org>
> ---
>  ospf6d/ospf6_interface.c | 23 ---
>  ospf6d/ospf6_interface.h |  1 -
>  ospf6d/ospf6_zebra.c |  7 ---
>  3 files changed, 31 deletions(-)
>
> diff --git a/ospf6d/ospf6_interface.c b/ospf6d/ospf6_interface.c
> index 26f68ac..c31f896 100644
> --- a/ospf6d/ospf6_interface.c
> +++ b/ospf6d/ospf6_interface.c
> @@ -340,29 +340,6 @@ ospf6_interface_if_add (struct interface *ifp)
>  }
>
>  void
> -ospf6_interface_if_del (struct interface *ifp)
> -{
> -  struct ospf6_interface *oi;
> -
> -  oi = (struct ospf6_interface *) ifp->info;
> -  if (oi == NULL)
> -return;
> -
> -  /* interface stop */
> -  if (oi->area)
> -thread_execute (master, interface_down, oi, 0);
> -
> -  listnode_delete (oi->area->if_list, oi);
> -  oi->area = (struct ospf6_area *) NULL;
> -
> -  /* cut link */
> -  oi->interface = NULL;
> -  ifp->info = NULL;
> -
> -  ospf6_interface_delete (oi);
> -}
> -
> -void
>  ospf6_interface_state_update (struct interface *ifp)
>  {
>struct ospf6_interface *oi;
> diff --git a/ospf6d/ospf6_interface.h b/ospf6d/ospf6_interface.h
> index 95a377f..8dffa7c 100644
> --- a/ospf6d/ospf6_interface.h
> +++ b/ospf6d/ospf6_interface.h
> @@ -153,7 +153,6 @@ extern void ospf6_interface_enable (struct
> ospf6_interface *);
>  extern void ospf6_interface_disable (struct ospf6_interface *);
>
>  extern void ospf6_interface_if_add (struct interface *);
> -extern void ospf6_interface_if_del (struct interface *);
>  extern void ospf6_interface_state_update (struct interface *);
>  extern void ospf6_interface_connected_route_update (struct interface *);
>
> diff --git a/ospf6d/ospf6_zebra.c b/ospf6d/ospf6_zebra.c
> index c8f20d8..b8366af 100644
> --- a/ospf6d/ospf6_zebra.c
> +++ b/ospf6d/ospf6_zebra.c
> @@ -120,13 +120,6 @@ ospf6_zebra_if_del (int command, struct zclient
> *zclient, zebra_size_t length,
>  zlog_debug ("Zebra Interface delete: %s index %d mtu %d",
> ifp->name, ifp->ifindex, ifp->mtu6);
>
> -#if 0
> -  /* XXX: ospf6_interface_if_del is not the right way to handle this,
> -   * because among other thinkable issues, it will also clear all
> -   * settings as they are contained in the struct ospf6_interface. */
> -  ospf6_interface_if_del (ifp);
> -#endif /*0*/
> -
>ifp->ifindex = IFINDEX_INTERNAL;
>return 0;
>  }
> --
> 2.8.0
>
>
> ___
> 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 15454] [PATCH] pimd: Add ability to safely ignore route-maps

[Donald Sharp]

pim was not parsing route-map code and causing issues
using vtysh because of this.  Add code to safely
ignore the route-map code and set us up for future
expansion into route-maps if neeeded.

Signed-off-by: Donald Sharp <sha...@cumulusnetworks.com>
---
 pimd/Makefile.am|  3 ++-
 pimd/pim_main.c |  4 
 pimd/pim_routemap.c | 32 
 pimd/pimd.h |  2 ++
 4 files changed, 40 insertions(+), 1 deletion(-)
 create mode 100644 pimd/pim_routemap.c

diff --git a/pimd/Makefile.am b/pimd/Makefile.am
index f57c4c2..d045436 100644
--- a/pimd/Makefile.am
+++ b/pimd/Makefile.am
@@ -52,7 +52,8 @@ libpim_a_SOURCES = \
pim_oil.c pim_zlookup.c pim_pim.c pim_tlv.c pim_neighbor.c \
pim_hello.c pim_ifchannel.c pim_join.c pim_assert.c \
pim_msg.c pim_upstream.c pim_rpf.c pim_macro.c \
-   pim_igmp_join.c pim_ssmpingd.c pim_int.c pim_static.c
+   pim_igmp_join.c pim_ssmpingd.c pim_int.c pim_static.c \
+pim_routemap.c
 
 noinst_HEADERS = \
pimd.h pim_version.h pim_cmd.h pim_signals.h pim_iface.h \
diff --git a/pimd/pim_main.c b/pimd/pim_main.c
index 5f4711e..ea70a8f 100644
--- a/pimd/pim_main.c
+++ b/pimd/pim_main.c
@@ -36,6 +36,8 @@
 #include "vty.h"
 #include "sigevent.h"
 #include "version.h"
+#include "prefix.h"
+#include "plist.h"
 
 #include "pimd.h"
 #include "pim_version.h"
@@ -200,6 +202,8 @@ int main(int argc, char** argv, char** envp) {
   memory_init();
   vrf_init();
   access_list_init();
+  prefix_list_init ();
+  pim_route_map_init ();
   pim_init();
 
   /*
diff --git a/pimd/pim_routemap.c b/pimd/pim_routemap.c
new file mode 100644
index 000..9cc13be
--- /dev/null
+++ b/pimd/pim_routemap.c
@@ -0,0 +1,32 @@
+/* PIM Route-map Code
+ * Copyright (C) 2016 Cumulus Networks <sha...@cumulusnetworks.com>
+ *
+ * This file is part of Quagga
+ *
+ * Quagga is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * Quagga is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with Quagga; see the file COPYING.  If not, write to the Free
+ * Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+ * 02111-1307, USA.
+ */
+#include 
+
+#include "routemap.h"
+
+#include "pimd.h"
+
+void
+pim_route_map_init (void)
+{
+  route_map_init ();
+  route_map_init_vty ();
+}
diff --git a/pimd/pimd.h b/pimd/pimd.h
index aed26be..9a7e605 100644
--- a/pimd/pimd.h
+++ b/pimd/pimd.h
@@ -159,4 +159,6 @@ struct list  *qpim_static_route_list; /* list 
of routes added static
 void pim_init(void);
 void pim_terminate(void);
 
+extern void pim_route_map_init (void);
+
 #endif /* PIMD_H */
-- 
2.5.5


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

[quagga-dev 15452] [PATCH 3/3] pimd: Remove igmp_add_group_by_addr unneeded parameter

[Donald Sharp]

The interface name is already passed in as
part of the 'struct igrmp *group' pointer.
No need to do it twice.

Signed-off-by: Donald Sharp <sha...@cumulusnetworks.com>
---
 pimd/pim_igmp.c   | 13 ++---
 pimd/pim_igmp.h   |  3 +--
 pimd/pim_igmpv3.c | 11 +--
 3 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/pimd/pim_igmp.c b/pimd/pim_igmp.c
index 7baf2e3..0561d70 100644
--- a/pimd/pim_igmp.c
+++ b/pimd/pim_igmp.c
@@ -622,7 +622,7 @@ static int igmp_v2_report(struct igmp_sock *igmp,
   memcpy(_addr, igmp_msg + 4, sizeof(struct in_addr));
 
   /* non-existant group is created as INCLUDE {empty} */
-  group = igmp_add_group_by_addr(igmp, group_addr, ifp->name);
+  group = igmp_add_group_by_addr(igmp, group_addr);
   if (!group) {
 return -1;
   }
@@ -679,7 +679,7 @@ static int igmp_v1_report(struct igmp_sock *igmp,
   memcpy(_addr, igmp_msg + 4, sizeof(struct in_addr));
 
   /* non-existant group is created as INCLUDE {empty} */
-  group = igmp_add_group_by_addr(igmp, group_addr, ifp->name);
+  group = igmp_add_group_by_addr(igmp, group_addr);
   if (!group) {
 return -1;
   }
@@ -1357,8 +1357,7 @@ static struct igmp_group *find_group_by_addr(struct 
igmp_sock *igmp,
 }
 
 struct igmp_group *igmp_add_group_by_addr(struct igmp_sock *igmp,
- struct in_addr group_addr,
- const char *ifname)
+ struct in_addr group_addr)
 {
   struct igmp_group *group;
 
@@ -1396,8 +1395,8 @@ struct igmp_group *igmp_add_group_by_addr(struct 
igmp_sock *igmp,
   }
   group->group_source_list->del = (void (*)(void *)) igmp_source_free;
 
-  group->t_group_timer = 0;
-  group->t_group_query_retransmit_timer= 0;
+  group->t_group_timer = NULL;
+  group->t_group_query_retransmit_timer= NULL;
   group->group_specific_query_retransmit_count = 0;
   group->group_addr= group_addr;
   group->group_igmp_sock   = igmp;
@@ -1414,7 +1413,7 @@ struct igmp_group *igmp_add_group_by_addr(struct 
igmp_sock *igmp,
 char group_str[100];
 pim_inet4_dump("<group?>", group->group_addr, group_str, 
sizeof(group_str));
 zlog_debug("Creating new IGMP group %s on socket %d interface %s",
-  group_str, group->group_igmp_sock->fd, ifname);
+  group_str, igmp->fd, igmp->interface->name);
   }
 
   /*
diff --git a/pimd/pim_igmp.h b/pimd/pim_igmp.h
index f8a31cd..ab39615 100644
--- a/pimd/pim_igmp.h
+++ b/pimd/pim_igmp.h
@@ -163,8 +163,7 @@ struct igmp_group {
 };
 
 struct igmp_group *igmp_add_group_by_addr(struct igmp_sock *igmp,
- struct in_addr group_addr,
- const char *ifname);
+ struct in_addr group_addr);
 
 void igmp_group_delete_empty_include(struct igmp_group *group);
 
diff --git a/pimd/pim_igmpv3.c b/pimd/pim_igmpv3.c
index 1a2e936..8a32a32 100644
--- a/pimd/pim_igmpv3.c
+++ b/pimd/pim_igmpv3.c
@@ -542,12 +542,11 @@ static void allow(struct igmp_sock *igmp, struct in_addr 
from,
  struct in_addr group_addr,
  int num_sources, struct in_addr *sources)
 {
-  struct interface *ifp = igmp->interface;
   struct igmp_group *group;
   inti;
 
   /* non-existant group is created as INCLUDE {empty} */
-  group = igmp_add_group_by_addr(igmp, group_addr, ifp->name);
+  group = igmp_add_group_by_addr(igmp, group_addr);
   if (!group) {
 return;
   }
@@ -688,7 +687,7 @@ void igmpv3_report_isex(struct igmp_sock *igmp, struct 
in_addr from,
   ifp, from, group_addr, num_sources, sources);
 
   /* non-existant group is created as INCLUDE {empty} */
-  group = igmp_add_group_by_addr(igmp, group_addr, ifp->name);
+  group = igmp_add_group_by_addr(igmp, group_addr);
   if (!group) {
 return;
   }
@@ -810,7 +809,7 @@ void igmpv3_report_toin(struct igmp_sock *igmp, struct 
in_addr from,
   ifp, from, group_addr, num_sources, sources);
 
   /* non-existant group is created as INCLUDE {empty} */
-  group = igmp_add_group_by_addr(igmp, group_addr, ifp->name);
+  group = igmp_add_group_by_addr(igmp, group_addr);
   if (!group) {
 return;
   }
@@ -960,7 +959,7 @@ void igmpv3_report_toex(struct igmp_sock *igmp, struct 
in_addr from,
   ifp, from, group_addr, num_sources, sources);
 
   /* non-existant group is created as INCLUDE {empty} */
-  group = igmp_add_group_by_addr(igmp, group_addr, ifp->name);
+  group = igmp_add_group_by_addr(igmp, group_addr);
   if (!group) {
 return;
   }
@@ -1481,7 +1480,7 @@ void igmpv3_report_block(struct igmp_sock *igmp, struct 
in_addr from,
   ifp, from, group_addr, num_sources, sources);
 
   /* non-existant group is crea

[quagga-dev 15451] [PATCH 2/3] pimd: Remove source_new unneeded parameter

[Donald Sharp]

The interface name is already passed in as
part of the 'struct igmp_group *group' pointer.
No need to do it twice.

Signed-off-by: Donald Sharp <sha...@cumulusnetworks.com>
---
 pimd/pim_igmp.h   |  3 +++
 pimd/pim_igmpv3.c | 40 
 2 files changed, 19 insertions(+), 24 deletions(-)

diff --git a/pimd/pim_igmp.h b/pimd/pim_igmp.h
index d45f223..f8a31cd 100644
--- a/pimd/pim_igmp.h
+++ b/pimd/pim_igmp.h
@@ -173,4 +173,7 @@ void igmp_startup_mode_on(struct igmp_sock *igmp);
 void igmp_group_timer_on(struct igmp_group *group,
 long interval_msec, const char *ifname);
 
+struct igmp_source *
+source_new (struct igmp_group *group,
+   struct in_addr src_addr);
 #endif /* PIM_IGMP_H */
diff --git a/pimd/pim_igmpv3.c b/pimd/pim_igmpv3.c
index 3657f2f..1a2e936 100644
--- a/pimd/pim_igmpv3.c
+++ b/pimd/pim_igmpv3.c
@@ -477,9 +477,9 @@ struct igmp_source *igmp_find_source_by_addr(struct 
igmp_group *group,
   return 0;
 }
 
-static struct igmp_source *source_new(struct igmp_group *group,
- struct in_addr src_addr,
- const char *ifname)
+struct igmp_source *
+source_new (struct igmp_group *group,
+   struct in_addr src_addr)
 {
   struct igmp_source *src;
 
@@ -491,7 +491,7 @@ static struct igmp_source *source_new(struct igmp_group 
*group,
 zlog_debug("Creating new IGMP source %s for group %s on socket %d 
interface %s",
   source_str, group_str,
   group->group_igmp_sock->fd,
-  ifname);
+  group->group_igmp_sock->interface->name);
   }
 
   src = XMALLOC(MTYPE_PIM_IGMP_GROUP_SOURCE, sizeof(*src));
@@ -501,13 +501,13 @@ static struct igmp_source *source_new(struct igmp_group 
*group,
 return 0; /* error, not found, could not create */
   }
   
-  src->t_source_timer= 0;
+  src->t_source_timer= NULL;
   src->source_group  = group; /* back pointer */
   src->source_addr   = src_addr;
   src->source_creation   = pim_time_monotonic_sec();
   src->source_flags  = 0;
   src->source_query_retransmit_count = 0;
-  src->source_channel_oil= 0;
+  src->source_channel_oil= NULL;
 
   listnode_add(group->group_source_list, src);
 
@@ -521,8 +521,7 @@ static struct igmp_source *source_new(struct igmp_group 
*group,
 
 static struct igmp_source *add_source_by_addr(struct igmp_sock *igmp,
  struct igmp_group *group,
- struct in_addr src_addr,
- const char *ifname)
+ struct in_addr src_addr)
 {
   struct igmp_source *src;
 
@@ -531,7 +530,7 @@ static struct igmp_source *add_source_by_addr(struct 
igmp_sock *igmp,
 return src;
   }
 
-  src = source_new(group, src_addr, ifname);
+  src = source_new(group, src_addr);
   if (!src) {
 return 0;
   }
@@ -560,7 +559,7 @@ static void allow(struct igmp_sock *igmp, struct in_addr 
from,
 
 src_addr = sources + i;
 
-source = add_source_by_addr(igmp, group, *src_addr,ifp->name);
+source = add_source_by_addr(igmp, group, *src_addr);
 if (!source) {
   continue;
 }
@@ -616,8 +615,7 @@ static void isex_excl(struct igmp_group *group,
 }
 else {
   /* E.4: if not found, create source with timer=GMI: (A-X-Y) */
-  source = source_new(group, *src_addr,
- group->group_igmp_sock->interface->name);
+  source = source_new(group, *src_addr);
   if (!source) {
/* ugh, internal malloc failure, skip source */
continue;
@@ -659,8 +657,7 @@ static void isex_incl(struct igmp_group *group,
 }
 else {
   /* I.4: if not found, create source with timer=0 (B-A) */
-  source = source_new(group, *src_addr,
- group->group_igmp_sock->interface->name);
+  source = source_new(group, *src_addr);
   if (!source) {
/* ugh, internal malloc failure, skip source */
continue;
@@ -737,8 +734,7 @@ static void toin_incl(struct igmp_group *group,
 }
 else {
   /* If not found, create new source */
-  source = source_new(group, *src_addr,
- group->group_igmp_sock->interface->name);
+  source = source_new(group, *src_addr);
   if (!source) {
/* ugh, internal malloc failure, skip source */
continue;
@@ -783,8 +779,7 @@ static void toin_excl(struct igmp_group *group,
 }
 else {
   /* If not found, create new source */
-  source = source_new(group, *src_addr,
- group->group_igmp_sock->interface->name);
+  source = source_new(group, *src_addr);
   if (!source) {
 

[quagga-dev 15449] [PATCH] bgpd: Fix route-map and redistribution

[Donald Sharp]

Commit f3cfc46 introduced this issue.  A route-map
lookup was being done for IPv6, using IPv4 information.

Signed-off-by: Donald Sharp <sha...@cumulusnetworks.com>
---
 bgpd/bgp_routemap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bgpd/bgp_routemap.c b/bgpd/bgp_routemap.c
index 39fa08c..98d5f1f 100644
--- a/bgpd/bgp_routemap.c
+++ b/bgpd/bgp_routemap.c
@@ -2389,7 +2389,7 @@ bgp_route_map_update (const char *unused)
  route_map_lookup_by_name (bgp->rmap[AFI_IP][i].name);
  if (bgp->rmap[AFI_IP6][i].name)
bgp->rmap[AFI_IP6][i].map =
- route_map_lookup_by_name (bgp->rmap[AFI_IP][i].name);
+ route_map_lookup_by_name (bgp->rmap[AFI_IP6][i].name);
}
 }
 }
-- 
2.5.5


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

[quagga-dev 15415] Quagga Release Process Meeting Notes

[Donald Sharp]

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 15402] Strawman Quagga Release Process

[Donald Sharp]

All -

Lou and I have taken a first pass at the release document that was
discussed in the meeting.

This description was inspired by, and loosely based on the Ubuntu release
process [https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess].

This document is available at the google doc listed below, so that all can
edit as they see fit.

https://docs.google.com/document/d/1xYrpTKYDvK23BCxXP-dbE6nOuvBxbGIilNLfVkI3j-I/edit

Thanks!

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

[quagga-dev 15373] Re: [quagga-users 14335] EIGRP Quagga not working

[Donald Sharp]

Jan/Donnie -

My assumption is, is that I have a wrong branch that I forward ported to
1.0.  What branch should be used?

donald

On Tue, May 24, 2016 at 7:32 AM,  wrote:

> Hi
> i have downloaded Quagga with EIGRP Support from
> https://github.com/donaldsharp/quagga/tree/EIGRP-Development.
> i have configured the following configuration to quagga :
> {
> interface enp0s8
>  ip address 192.168.56.102/24
>  link-detect
>
> router eigrp 100
> network 192.168.56.0/24
> }
> and it is saved to running configuration. but when i type "show ip eigrp
> interface" it does not list my enp0s8 interface as an EIGRP enabled
> Interface and as a result it does not send Hello packet out that interface
> and finally can not make a neighborship with other routers.
>
>
> *the point is : EIGRP is not enabled in enp0s8 interface although i have
> configured the network command. *
> Thanks very much
>
>
> ___
> Quagga-users mailing list
> quagga-us...@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-users
>
>
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15353] Re: Patch Submittal Process Going Forward Discussion.

[Donald Sharp]

All --

The meeting is tomorrow.  If you have a proposal for how you would like the
Patch submittal process to work, I would like to have it in an email format
before the meeting tomorrow.

Additionally if you would like to attend, please send me a email and I'll
add you to the list of invites.


thanks!

donald

On Tue, May 17, 2016 at 11:45 AM, Donald Sharp <sha...@cumulusnetworks.com>
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.
>
> Proposal for going forward:
>
>1. Patch Submitted
>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.
>
> 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 15338] Re: Patch Submittal Process Going Forward Discussion.

[Donald Sharp]

Paul -

On Fri, May 20, 2016 at 5:38 AM, Paul Jakma  wrote:

>
> - "resolve issues at a faster rate", by which you really mean "Ignore
>   having to address the former".
>
>
Please stop putting words in my mouth.  I've never said that and I really
don't appreciate this continued insinuation that I'm actively ignoring
comments.


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

[quagga-dev 15321] Re: Patch Submittal Process Going Forward Discussion.

[Donald Sharp]

The point of all of this wasn't about Cumulus or not.  We've had multiple
people state that the process takes too long multiple times recently.  The
point was that patches are piling up across the *community* at a rate
greater than they are even being looked at.  I see no way that we can reach
unanimity for every patch.  Nor do I see any advantage to 2 month long
arguments about issues.  I would like a process where we can resolve issues
at a faster rate.

donald


On Wed, May 18, 2016 at 8:54 AM, Paul Jakma <p...@jakma.org> wrote:

> On Tue, 17 May 2016, Donald Sharp wrote:
>
> Proposal for going forward:
>>
>>   1. Patch Submitted
>>   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.
>>
>
>
> 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.
>>
>
> In general, I don't think it is correct to have a globally distributed
> open-source project rely on a "must be present at this specific point of
> time" protocol for resolving things. On "If you can't be bothered to attend
> then the decision wasn't important to you", I will accept this if you're
> happy to get up in the middle of the night for calls.
>
> E.g., there definitely are engineers in, say, India working on Quagga. If
> not working on Quagga.net, I'd like them to be able to at least in time.
>
> The issue is to have time-bounded and clear decisions. There is 0 reason
> why the final vote can not be done with structured voting protocols via a
> mailing list, with a wider window of time that is easier for a wider group
> of people to deal with and with a clear deadline.
>
> Moving to what is driving this, the Cumulus backlog, I am somewhat uneasy
> at moving to a process driven just by that. I am uneasy at moving to a
> process that makes it easier for one set of contributors to club together
> and over-ride other contributors.
>
> In particular, I have some concerns that a factor driving this is that
> Cumulus is somewhat resistant to review, and in particular quite resistant
> to dropping patches.
>
> There are of course many issues that got us here. Quagga had a resource
> problem for a while, maintainers were getting burned out (I certainly was
> very burned out around '08). Those issues were of course significant in
> Cumulus building up that initial backlog. No doubt that in part led Cumulus
> to disengage to some degree. However, attempts to re-engage and deal with
> the back-log have had problems.
>
> Things have improved significantly with your arrival, and I think we've
> made improvements on speed of getting stuff in, and on process. Least we
> were, but it seems to have stalled a bit again.
>
> And I am concerned about some things. The take-3 branch has patches that I
> reviewed in *2014*. I started with NetDEF and started going through the
> Cumulus tree then, along with David. We got some stuff in (about half of
> the patches looked at) and some stuff I sent queries or comments or
> pushback on to Cumulus. I never heard anything back. The same patches keep
> coming back too. Even in recent times, I have queried patches, not heard
> anything back and then they just re-appear in the next submission.
>
> On take-3, I spent a non-trivial amount of time going through that. And
> gave comments. Most can go in. Some have nits (e.g. random other unrelated
> changes), some nits I just fixed there and then. Other patches are odd -
> the commit message doesn't explain why it exists (the one I'm thinking of
> is one of the ones I similarly queried in 2014). Another set of patches are
> blocked by changes needed to one patch, change I think we agreed on.
>
> However, roun

[quagga-dev 15320] Re: Patch Submittal Process Going Forward Discussion.

[Donald Sharp]

On Thu, May 19, 2016 at 6:15 AM, Martin Winter <
mwin...@opensourcerouting.org> wrote:

> On 17 May 2016, at 8:45, Donald Sharp wrote:
>
>>
>>
>> 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?
>
>
No, that was not my intent.  I was attempting to clarify a point that was
inconsequential to suggested rewording by Lou.   I've just resent the
proposal and I feel like it clarifies both your and Lou's concerns.



> 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?
>
>
I intentionally left this vague to allow maintainer to apply the golden
rule and brain cells to the issue.  I'm not sure I would like to codify
this further.

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

[quagga-dev 15293] Patch Submittal Process Going Forward Discussion.

[Donald Sharp]

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.

Proposal for going forward:

   1. Patch Submitted
   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.

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 15289] Monthly Meeting Notes and proposal for moving forward

[Donald Sharp]

Monthly meeting:

Discussion of slowness of getting patches in.  General dissatisfaction with
current process and lots of discussion on how to improve.  General issue
boiled down to unanimity -vs- consensus.

Discussion of process of how to move forward.
   -> Donald to send an email to alias with proposal.  In addition we will
have another meeting next week to finalize.  Details to follow.

Some discussion of alternate tools to use, decided to fix the process of
arguing that we see first before tools are changed.

Lou proposed the setup a Bi-directional github repository of quagga.
Martin and Paul to make happen

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

[quagga-dev 15256] Reminder

[Donald Sharp]

We have the monthly quagga-dev meeting this tuesday 5/17 @ 9:00AM EDT.  If
you would like to attend and don't have an invite please send me an email
and I'll get you one.

Also topics for discussion are being solicited.

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

[quagga-dev 15236] Re: git archive error.

[Donald Sharp]

Your missing some part of the git package.  Probably git-buildpackage?
What does dpkg -l | grep git return?

donald

On Fri, May 6, 2016 at 8:35 AM, dexter i  wrote:

> i'm following the quagga hacking guide. As per the guide when i run the
> following
> command, i'm getting this error. can someone tell me what is missing here.
>
> git archive --remote=git://code.quagga.net/quagga.git
> --prefix=quagga-release/ master | tar -xf -
> bash: git-archive: command not found
> tar: This does not look like a tar archive
> tar: Exiting with failure status due to previous errors
>
> thanks
> dexter
>
> ___
> 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 15235] Re: [PATCH v2 08/30] lib: add facility to log all CLI commands

[Donald Sharp]

Either would be fine from my perspective too.

donald

On Fri, May 6, 2016 at 8:33 AM, Lou Berger <lber...@labn.net> wrote:

>
>
> On 5/6/2016 8:29 AM, Donald Sharp wrote:
> > I agree with Lou that this is a good thing to do.  If necessary to get
> > this in, I wouldn't be adverse to having a compile time option to
> > control for people who may be interested.
> >
> I like command line flag better, but would be okay with configure option
> too..
>
> Lou
>
> > Although if you are not rotating your logs, I'm not sure that I care
> > that your log file suddenly has more info in it.
> >
> > doanld
> >
> > On Fri, May 6, 2016 at 5:50 AM, Paul Jakma <p...@jakma.org
> > <mailto:p...@jakma.org>> wrote:
> >
> > Hi Lou,
> >
> > Logging every command unconditionally causes issues with spam to
> > the logs - not all commands are interesting (especially not any
> > regular monitoring commands).
> >
> > Can we fix this? :)
> >
> > regards,
> > --
> > Paul Jakma  p...@jakma.org <mailto:p...@jakma.org>  @pjakma
> > Key ID: 64A2FF6A
> > Fortune:
> > The days are all empty and the nights are unreal.
> >
> >
> > ___
> > Quagga-dev mailing list
> > Quagga-dev@lists.quagga.net <mailto: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 15221] Re: [PATCH] lib: Remove dead code from zrealloc

[Donald Sharp]

Well Lou added the code.  The commit log referenced some memory issue that
was found that this fixes.  Might be worthwhile getting some feedback on
that.

I'm not sure we should go carte-blanch back to what we have :)

donald

On Tue, May 3, 2016 at 2:03 PM, Christian Franke <
ch...@opensourcerouting.org> wrote:

> On 05/03/2016 07:46 PM, Donald Sharp wrote:
> > You are right for the upstream behavior.  The version that we have in
> > the cumulus tree is this:
> >
> > 106 void *
> > 107 zrealloc (int type, void *ptr, size_t size)
> > 108 {
> > 109   void *memory;
> > 110
> > 111   memory = realloc (ptr, size);
> > 112   if (memory == NULL)
> > 113 zerror ("realloc", type, size);
> > 114   if (ptr == NULL)
> > 115 alloc_inc (type);
> > 116
> > 117   return memory;
> > 118 }
> >
> >
> > Which would not work too well with your patch :)
> >
> > ah well.  My mistake.
> >
> > acked-by: Donald Sharp <sha...@cumulusnetworks.com
> > <mailto:sha...@cumulusnetworks.com>>
>
> Then let's stick with your version. Imho, either is fine and it's
> probably good to keep merge conflicts low.
>
> -Christian
>
>
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15189] Re: IPv6 BGP default route ignored when using SLAAC

[Donald Sharp]

Alex -

I haven't answered because I don't know the answers to your question
without some research and investigation.  Unfortunately routing protocols
are complicated and It's sometimes a non-trivial amount of work to answer
someone's question.

donald

On Mon, Apr 25, 2016 at 3:13 AM,  wrote:

>
> I'm starting to feel stupid talking to myself here.  What are the
> magic words I need to say to get any kind of response to this issue?
>
> It's a rather fundamental difference in behaviuor and it breaks my use
> case.  Help, please.
>
> --
> Alex
>
> On Wed, 30 Mar 2016 12:36:20 +0200, g...@switch.ch said:
>
> > Can someone please comment at least on the differing behaviour of
> > zebrad with respect to routes of type "ra" and "kernel"?
>
> > Should "ra" be trated like "kernel"?  If not, why?
>
> > --
> > Alex
>
> > On Mon, 21 Mar 2016 14:57:17 +0100, g...@switch.ch said:
>
> >> I've been using quagga for a long time to implement router-style
> >> "loopback" addresses on multi-homed hosts, i.e. I configure a /128 on
> >> the lo device and announce it via BGP.  The host receives a default
> >> route ::/0 and I use BGP policies to select which interface to prefer
> >> for outbound traffic.  At the same time, the host uses SLAAC to
> >> set up a default route on each interface as a fallback.
>
> >> Here is an example using Quagga 0.99.22.4 on Linux 3.2.0 which works
> >> as desired:
>
> >> $ ip -6 r l | grep default
> >> default via fe80::2a94:fff:fefd:5bc0 dev eth2  proto zebra  metric 10
> >> default via fe80::2a94:fff:fefd:5bc0 dev eth0  proto kernel  metric
> 1024  expires 1794sec hoplimit 64
> >> default via fe80::2a94:fff:fefd:5bc0 dev eth2  proto kernel  metric
> 1024  expires 1783sec hoplimit 64
> >> default via fe80::2a94:fff:fefd:4940 dev eth3  proto kernel  metric
> 1024  expires 1676sec hoplimit 64
> >> default via fe80::2a94:fff:fefd:4940 dev eth1  proto kernel  metric
> 1024  expires 1794sec hoplimit 64
>
> zebrad> sh ipv6 ro
> >> Codes: K - kernel route, C - connected, S - static, R - RIPng,
> >> O - OSPFv6, I - IS-IS, B - BGP, A - Babel,
> >>> - selected route, * - FIB route
>
> B> * ::/0 [20/10] via fe80::2a94:fff:fefd:5bc0, eth2, 03w3d01h
> C> * ::1/128 is directly connected, lo
> C> * 2001:620::1a/128 is directly connected, lo
> C> * 2001:620:0:ff::3/128 is directly connected, lo
> C> * 2001:620:0:800c::/64 is directly connected, eth0
> C> * 2001:620:0:800d::/64 is directly connected, eth2
> C> * 2001:620:0:800e::/64 is directly connected, eth1
> C> * 2001:620:0:800f::/64 is directly connected, eth3
> >> C * fe80::/64 is directly connected, eth3
> >> C * fe80::/64 is directly connected, eth1
> >> C * fe80::/64 is directly connected, eth2
> C> * fe80::/64 is directly connected, eth0
> zebrad> sh ipv6 ro ::/0
> >> Routing entry for ::/0
> >> Known via "bgp", distance 20, metric 10, best
> >> Last update 03w3d01h ago
> >> * fe80::2a94:fff:fefd:5bc0, via eth2
>
> >> The BGP route is installed in the kernel with metric 10 as expected.
> >> If the host looses its BGP peers, it still has the default routes via
> >> SLAAC.
>
> >> On another system running Quagga 0.99.23.1 and Linux 3.16.0, the BGP
> >> route doesn't get installed:
>
> >> $ ip -6 r l | grep default
> >> default via fe80::207:7dff:fe76:5980 dev eth0  proto ra  metric 1024
> expires 1631sec hoplimit 64
> >> default via fe80::207:7dff:fe76:5940 dev eth4  proto ra  metric 1024
> expires 1709sec hoplimit 64
>
> zebrad> sh ipv6 ro
> >> Codes: K - kernel route, C - connected, S - static, R - RIPng,
> >> O - OSPFv6, I - IS-IS, B - BGP, A - Babel,
> >>> - selected route, * - FIB route
>
> >> B   ::/0 [20/1] via fe80::207:7dff:fe76:5940, eth4, 04w3d23h
> K> * ::/0 via fe80::207:7dff:fe76:5940, eth4
> C> * ::1/128 is directly connected, lo
> C> * 2001:620::10/128 is directly connected, lo
> C> * 2001:620:0:8018::/64 is directly connected, eth0
> C> * 2001:620:0:8019::/64 is directly connected, eth4
> >> C * fe80::/64 is directly connected, eth4
> C> * fe80::/64 is directly connected, eth0
> zebrad> sh ipv6 ro ::/0
> >> Routing entry for ::/0
> >> Known via "bgp", distance 20, metric 1
> >> Last update 04w3d23h ago
> >> fe80::207:7dff:fe76:5940, via eth4
>
> >> Routing entry for ::/0
> >> Known via "kernel", distance 0, metric 1024, best
> >> * fe80::207:7dff:fe76:5940, via eth4
>
> >> The difference is that zebrad now picks up one of the default routes
> >> from SLAAC with an administrative distance of 0, which makes it
> >> impossible to override with BGP.
>
> >> The obvious difference is that the 3.16 kernel uses proto "ra" instead
> >> of proto "kernel" for the routes learned via SLAAC (i don't know in
> >> which kernel version this started to happen).  I'm totally unfamiliar
> >> with the Quagga code, but a glance at
> >> zebra/rt_netlink.c:netlink_routing_table() seems to suggest that
> >> routes of type "kernel" are always ignored due to
>
> >> if (rtm->rtm_protocol == RTPROT_KERNEL)
> >> return 0;
>
> >> Since the routes in 

[quagga-dev 15175] Re: proposed 7

[Donald Sharp]

Jafar -

That seems reasonable.  The route-map crash does as well.  Any other votes?

donald

On Mon, Apr 25, 2016 at 11:15 AM, Jafar Al-Gharaibeh <ja...@atcorp.com>
wrote:

> Donald,
>
>If no one has more comments/reservations on the ospfd crash fixes
> related to wrong neighbor index, do you want to push that patch [1902] as
> well?
>
> Thanks,
> Jafar
>
>
> On 4/22/2016 7:49 AM, Donald Sharp wrote:
>
> I've just pushed volatile/patch-tracking/7/proposed/ff to savannah:
>
> e6ec2d6 lib: Fix priviledge modification for vty group specified
> 190591f zserv: [pimd] fix - avoid dereferencing a NULL pointer
> 80f61a9 pimd: Fix hang when doing nexthop lookup from zebra
> 7e73eb7 zebra: handle multihop nexthop changes properly
> 7e7a101 ripd: Fix Null pointer dereference
> e720709 isisd: ignore unknown interfaces when adjusting IS-IS mtu
> 84a4da0 isisd: make sure that all interface addresses are advertised
> 8ed8d0b isisd: fix a crash due to an lsp-mtu issue
> 106e38e isisd: work around route table asserts for deleting node with info
>
>
> These are all bug fixes for crashes or problems reported with the latest
> 1.0.  This branch is intended to be another bug fix release.
> Martin - When you get a chance can you run your basic tests against this
> code?
>
> thanks!
>
> donald
>
>
> ___
> Quagga-dev mailing 
> listQuagga-dev@lists.quagga.nethttps://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 15150] Next Major Release Branch

[Donald Sharp]

This has been asked a couple of times so let's get it out there:

The current plan was to take the take-3 branch (
https://github.com/donaldsharp/quagga/tree/take-3 ) and move that into a
proposed/8 branch.  Paul and I are in discussions to do this:

Current sticking points as I understand it:

(A) Proper Attribution of some patches.  Paul and I are discussing this and
are attempting to work this out properly
(B) route-map behavior after application ( Another email to be sent to
discuss this )
(C) Additional commit commentary needs to be written for some patches
(D) Some patches are a grab bag of issues and should be broken up.
  -> I've already done some of this but the amount of time to get this
right is going to be huge.  Paul indicated he was going to take an attempt
at some of the more egregarious issues.

Paul If I've missed anything let me know.

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

[quagga-dev 15151] Route-Map Behavior

[Donald Sharp]

Paul and I have been discussing this commit:

https://github.com/donaldsharp/quagga/commit/4a77fb6cc78cacfd0c6cd0c35ba766f994a87e11

Quagga behavior without this patch does not take into effect for already
processed events.  So if you change a route-map
you need to reset the peer by hand to make it take into effect.

With this code change a timer is started that gets executed after a small
time that causes all routes to be reprocessed.

Paul suggestion is to add an event on 'conf t' exit to immediately expire
the timer if it is still running.  Which I am planning on writing here
shortly.

Having said that does anyone else have thoughts on this behavior and what
it may or may not do?

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

[quagga-dev 15134] proposed 7

[Donald Sharp]

I've just pushed volatile/patch-tracking/7/proposed/ff to savannah:

e6ec2d6 lib: Fix priviledge modification for vty group specified
190591f zserv: [pimd] fix - avoid dereferencing a NULL pointer
80f61a9 pimd: Fix hang when doing nexthop lookup from zebra
7e73eb7 zebra: handle multihop nexthop changes properly
7e7a101 ripd: Fix Null pointer dereference
e720709 isisd: ignore unknown interfaces when adjusting IS-IS mtu
84a4da0 isisd: make sure that all interface addresses are advertised
8ed8d0b isisd: fix a crash due to an lsp-mtu issue
106e38e isisd: work around route table asserts for deleting node with info


These are all bug fixes for crashes or problems reported with the latest
1.0.  This branch is intended to be another bug fix release.
Martin - When you get a chance can you run your basic tests against this
code?

thanks!

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

[quagga-dev 15073] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support

[Donald Sharp]

I'm confused.  I thought that was the point of the call to gather consensus
as a community.

donald

On Tue, Apr 19, 2016 at 10:34 AM, Paul Jakma  wrote:

> On Tue, 19 Apr 2016, David Lamparter wrote:
>
> On Tue, Apr 19, 2016 at 04:10:04PM +0200, David Lamparter wrote:
>>
>>> The default state of this seems to be "infinite", which is not
>>> RFC-compilant behaviour.  There was unanimous consent in the monthly
>>> meeting that RFC-compliant behaviour should be the default.
>>>
>>
>> s/consent/consensus/
>>
>> (The 2 words not only sound similar but also mix when translated into
>> German...)
>>
>
> The call doesn't decide the consensus. ;)
>
> regards,
> --
> Paul Jakma, HPE Aruba, Advanced Technology Group
> Fortune:
> Computer room being moved.  Our systems are down for the weekend.
>
>
> ___
> 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 15068] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support

[Donald Sharp]

I would prefer that we are rfc compliant as per default and then have a
switch to turn it off if needed.

donald

On Tue, Apr 12, 2016 at 7:58 AM, Paul Jakma  wrote:

> * The current stub-router support in Quagga ospfd took the "[max-metric
>   links] should not be used for transit traffic" part of RFC3137 seriously,
>   as that strict no-transit behavoiur is useful (and what the implementor
>   was after).  However, it seems that wording was not intended to change
>   any standards specified behaviour.
>
>   Quagga as a result has different behaviour to other implementations in
> its
>   SPF when it encounters 0x metric links.  This can lead to routing
>   loops in mixed environments.
>
>   This commit:
>
>   - Makes the SPF behaviour configurable with a
>
>   "compatible max-metric (infinite|follow)"
>
> command.  The state of this setting is explicitly written out, if the
> ospfd config is written out.
>
>   - Allows the administrator to specify a "transit" flag to the max-metric
> command:
>
>   "max-metric router-lsa transit"
>
> to explicitly specify the RFC2328/RFC3187 "discourage, but transit is
> still fine" behaviour the administator desires, and for the stub-router
> to try signal to other routers.
>
> If this "transit" flag is set, then the router-LSA links are advertised
> with 0xfffe cost when stub-router is enabled, which should work
> universally.
>
> Note, this is separate from the 'max-metric router-lsa ...' command to
> enable stub-router advertisement.
>
>   - Additionally, sets the "Host" option bit in the Router-LSA if the
> "transit" flag is not specified to the stub-router command.
>
>   This should allow a Quagga stub-router, at least, to signal its intent
>   clearly:
>
>   - To RFC2328 routers and older Quagga routers, when it /may/ still be
> used
> for transit.
>
>   - To all routers recognising the H-bit and to older Quagga routers, when
> it /should not/ be used for transit.
>
>   If and when the H-bit is widely recognised, and has been deployed in
>   Quagga for long enough, we may be able to change the SPF behaviour
> default
>   to the standards behaviour of "follow".
>
> * libospf.h: Add OSPF_OUTPUT_COST_DISCOURAGE for the 0xfffe cost.
> * ospf_dump.c: Add the H bit.
> * ospf_lsa.c: (ospf_link_cost) The Host-bit configuration controls whether
>   we use infinite/0x or discourage/0xfffe cost for links for
>   stub-routers.
>   (ospf_router_lsa_new) Set H-bit when configured and stub-routed.
> * ospf_spf.c: (ospf_spf_next) Recognise the H-bit.
>   Make the 0x link behaviour admin configurable.
> * ospf_vty.c: (show_ip_ospf) display info on the new flags.
>   (ospf_compatible_max_metric_cmd) Set the SPF compatibility behaviour for
>   maximum metric links.
>   (ospf_max_metric_router_lsa_transit_cmd) Configure whether to advertise
>   transit capability or not, as/when stub-router support is in effect.
>   (config_write_stub_router) write the 2 new flags out.
>   (ospf_vty_init) install commands for new flags.
> * ospfd.c: H-bit advertisement is configured by default as the existing
>   behaviour.
> * ospfd.h: Add H-bit option define. Add ospf instance config flags for
>   the SPF max-metric link behaviour, and h-bit/no-transit.
> * ospfd.texi: Update the docs with the new commands.
> ---
>  doc/ospfd.texi| 137 ++--
>  lib/libospf.h |   2 +
>  ospfd/ospf_dump.c |   3 +-
>  ospfd/ospf_lsa.c  |  12 -
>  ospfd/ospf_spf.c  |  73 --
>  ospfd/ospf_vty.c  | 153
> --
>  ospfd/ospfd.c |   2 +
>  ospfd/ospfd.h |   3 ++
>  8 files changed, 348 insertions(+), 37 deletions(-)
>
> diff --git a/doc/ospfd.texi b/doc/ospfd.texi
> index 86cabe4..b87cbce 100644
> --- a/doc/ospfd.texi
> +++ b/doc/ospfd.texi
> @@ -129,6 +129,7 @@ advertise non-OSPF links into stub areas.
>
>  @deffn {OSPF Command} {timers throttle spf @var{delay}
> @var{initial-holdtime} @var{max-holdtime}} {}
>  @deffnx {OSPF Command} {no timers throttle spf} {}
> +@anchor{OSPF timers throttle spf}
>  This command sets the initial @var{delay}, the @var{initial-holdtime}
>  and the @var{maximum-holdtime} between when SPF is calculated and the
>  event which triggered the calculation. The times are specified in
> @@ -172,23 +173,25 @@ releases.
>  @deffn {OSPF Command} {max-metric router-lsa [on-startup|on-shutdown]
> <5-86400>} {}
>  @deffnx {OSPF Command} {max-metric router-lsa administrative} {}
>  @deffnx {OSPF Command} {no max-metric router-lsa
> [on-startup|on-shutdown|administrative]} {}
> -This enables @cite{RFC3137, OSPF Stub Router Advertisement} support,
> -where the OSPF process describes its transit links in its router-LSA as
> -having infinite distance so that other routers will avoid calculating
> -transit paths through the router while still being able to reach
> -networks through 

[quagga-dev 15033] Re: [PATCH 2/2] zebra: count iface up/down events and keep last time of their occurrence

[Donald Sharp]

I think there is value to know the number of times an interface has flapped
in addition to the last time it happened.

The interface flapped over the weekend?  Not sure I care that much.  The
interface last flapped over the weekend and the counter went up 6000
times?  I probably need to check it out.

donald

On Mon, Apr 11, 2016 at 4:48 AM, Paul Jakma  wrote:

> On Thu, 7 Apr 2016, Christian Franke wrote:
>
> From: Christian Franke 
>>
>> It is quite useful to be able to assert whether specific interfaces have
>> flapped or also to verify that specific interfaces have not flapped.
>>
>
> By having counters for those events and storing the last time of their
>> occurrence, this is made possible.
>>
>
> +  unsigned int up_count;
>> +  char up_last[QUAGGA_TIMESTAMP_LEN];
>> +  unsigned int down_count;
>> +  char down_last[QUAGGA_TIMESTAMP_LEN];
>> +
>>
>
> Why not just store timestamps here?
>
> It'd be nice to have "Move UI out of core processes" as a goal, and it'd
> be nice to keep UI related formatting out of core stuff as a result, or not?
>
> regards,
> --
> Paul Jakma  p...@jakma.org  @pjakma Key ID: 64A2FF6A
> Fortune:
> "I've seen the forgeries I've sent out."
> -- John F. Haugh II (j...@rpp386.dallas.tx.us), about forging net news
> articles
>
>
> ___
> 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 15025] [PATCH] lib: Fix priviledge modification for vty group specified

[Donald Sharp]

When attempting to switch runtime permissions over to
the correct group specified for the vty group, if the
user specified to run as does not have that vty group
then do warn about the issue and stop running

Signed-off-by: Donald Sharp <sha...@cumulusnetworks.com>
Reported-by: Thomas Martin <tmartin...@gmail.com>
---
 lib/privs.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lib/privs.c b/lib/privs.c
index 0ca8783..e6d76b6 100644
--- a/lib/privs.c
+++ b/lib/privs.c
@@ -664,6 +664,7 @@ zprivs_init(struct zebra_privs_t *zprivs)
   struct group *grentry = NULL;
   gid_t groups[NGROUPS_MAX];
   int i, ngroups = 0;
+  int found = 0;
 
   if (!zprivs)
 {
@@ -729,8 +730,17 @@ zprivs_init(struct zebra_privs_t *zprivs)
 
   for ( i = 0; i < ngroups; i++ )
 if ( groups[i] == zprivs_state.vtygrp )
-  break;
+  {
+found++;
+break;
+  }
 
+  if (!found)
+{
+ fprintf (stderr, "privs_init: user(%s) is not part of vty group 
specified(%s)\n",
+  zprivs->user, zprivs->vty_group);
+  exit (1);
+}
   if ( i >= ngroups && ngroups < (int) ZEBRA_NUM_OF(groups) )
 {
   groups[i] = zprivs_state.vtygrp;
-- 
1.9.1


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

[quagga-dev 15022] Re: [PATCH 2/2] zebra: count iface up/down events and keep last time of their occurrence

[Donald Sharp]

Jafar -

You know that, I know that.   End Users are going to see the incongruence
and start asking questions.  If I can stop a question from being asked.  I
think that is a win.

On Fri, Apr 8, 2016 at 11:11 AM, Jafar Al-Gharaibeh <ja...@atcorp.com>
wrote:

>
> On 4/8/2016 7:24 AM, Donald Sharp wrote:
>
> Christian -
>
> If I start Quagga, after the link is already brought up:
>
> dell-s6000-02# show int swp31s2.4
> Interface swp31s2.4 is up, line protocol is up
>   Link ups:   0last: (never)
>   Link downs: 0last: (never)
>   PTM status: disabled
>   vrf: vrf1014
>   index 58 metric 0 mtu 1500
>   flags: <UP,BROADCAST,RUNNING,MULTICAST>
>   HWaddr: 44:38:39:00:85:04
>   inet 169.254.4.17/30
>   inet6 fe80::4638:39ff:fe00:8504/64
>   ND advertised reachable time is 0 milliseconds
>   ND advertised retransmit interval is 0 milliseconds
>   ND router advertisements are sent every 1 seconds
>   ND router advertisements lifetime tracks ra-interval
>   ND router advertisement default router preference is medium
>   Hosts use stateless autoconfig for addresses.
>   Neighbor address(s):
>   inet6 fe80::202:ff:fe00:23/128
> dell-s6000-02#
>
> We never start at an initial Link up.  Possible to get another patch to
> fix that issue?
>
>
>   The way I read this patch (and according to Christian's comment ) is to
> monitor if the
>   interface flapped/went up/down since Quagga started, it is not meant to
> indicate if the interface
>   is currently up or now (there are already ways to know that). So, the
> reported output in your case
>   is correct; the interface never went up/down since Quagga started.
>
> --Jafar
>
>
>
> doanld
>
> On Thu, Apr 7, 2016 at 5:00 PM, Jafar Al-Gharaibeh <ja...@atcorp.com>
> wrote:
>
>> Acked-by: Jafar Al-Gharaibeh <ja...@atcorp.com>
>>
>>
>> On 4/7/2016 2:43 PM, Christian Franke wrote:
>>
>>> From: Christian Franke <nob...@nowhere.ws>
>>>
>>> It is quite useful to be able to assert whether specific interfaces have
>>> flapped or also to verify that specific interfaces have not flapped.
>>>
>>> By having counters for those events and storing the last time of their
>>> occurrence, this is made possible.
>>>
>>> Signed-off-by: Christian Franke < <ch...@opensourcerouting.org>
>>> ch...@opensourcerouting.org>
>>> ---
>>>   zebra/interface.c | 15 +++
>>>   zebra/interface.h |  6 ++
>>>   2 files changed, 21 insertions(+)
>>>
>>> diff --git a/zebra/interface.c b/zebra/interface.c
>>> index 8a9225a..ab0dfb5 100644
>>> --- a/zebra/interface.c
>>> +++ b/zebra/interface.c
>>> @@ -536,6 +536,11 @@ if_up (struct interface *ifp)
>>> struct listnode *next;
>>> struct connected *ifc;
>>> struct prefix *p;
>>> +  struct zebra_if *zif;
>>> +
>>> +  zif = ifp->info;
>>> +  zif->up_count++;
>>> +  quagga_timestamp(2, zif->up_last, sizeof(zif->up_last));
>>>   /* Notify the protocol daemons. */
>>> zebra_interface_up_update (ifp);
>>> @@ -569,6 +574,11 @@ if_down (struct interface *ifp)
>>> struct listnode *next;
>>> struct connected *ifc;
>>> struct prefix *p;
>>> +  struct zebra_if *zif;
>>> +
>>> +  zif = ifp->info;
>>> +  zif->down_count++;
>>> +  quagga_timestamp(2, zif->down_last, sizeof(zif->down_last));
>>>   /* Notify to the protocol daemons. */
>>> zebra_interface_down_update (ifp);
>>> @@ -728,6 +738,11 @@ if_dump_vty (struct vty *vty, struct interface *ifp)
>>>   vty_out (vty, "down%s", VTY_NEWLINE);
>>> }
>>>   +  vty_out (vty, "  Link ups:   %5ulast: %s%s", zebra_if->up_count,
>>> +   zebra_if->up_last[0] ? zebra_if->up_last : "(never)",
>>> VTY_NEWLINE);
>>> +  vty_out (vty, "  Link downs: %5ulast: %s%s", zebra_if->down_count,
>>> +   zebra_if->down_last[0] ? zebra_if->down_last : "(never)",
>>> VTY_NEWLINE);
>>> +
>>> vty_out (vty, "  vrf: %u%s", ifp->vrf_id, VTY_NEWLINE);
>>>   if (ifp->desc)
>>> diff --git a/zebra/interface.h b/zebra/interface.h
>>> index dbb33c5..a7522bc 100644
>>> --- a/zebra/interface.h
>>> +++ b/zebra/interface.h
>>> @@ -188,6 +188,12 @@ struct zebra_if
>>> /* Installed addresses chains tree. */
>>> struct route_table *ipv4_subnets;
>>>   +  /* Information about up/down changes */
>>> +  unsigned int up_count;
>>> +  char up_last[QUAGGA_TIMESTAMP_LEN];
>>> +  unsigned int down_count;
>>> +  char down_last[QUAGGA_TIMESTAMP_LEN];
>>> +
>>>   #if defined(HAVE_RTADV)
>>> struct rtadvconf rtadv;
>>>   #endif /* RTADV */
>>>
>>
>>
>> ___
>> 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 15018] Re: [PATCH 2/2] zebra: count iface up/down events and keep last time of their occurrence

[Donald Sharp]

Christian -

If I start Quagga, after the link is already brought up:

dell-s6000-02# show int swp31s2.4
Interface swp31s2.4 is up, line protocol is up
  Link ups:   0last: (never)
  Link downs: 0last: (never)
  PTM status: disabled
  vrf: vrf1014
  index 58 metric 0 mtu 1500
  flags: 
  HWaddr: 44:38:39:00:85:04
  inet 169.254.4.17/30
  inet6 fe80::4638:39ff:fe00:8504/64
  ND advertised reachable time is 0 milliseconds
  ND advertised retransmit interval is 0 milliseconds
  ND router advertisements are sent every 1 seconds
  ND router advertisements lifetime tracks ra-interval
  ND router advertisement default router preference is medium
  Hosts use stateless autoconfig for addresses.
  Neighbor address(s):
  inet6 fe80::202:ff:fe00:23/128
dell-s6000-02#

We never start at an initial Link up.  Possible to get another patch to fix
that issue?

doanld

On Thu, Apr 7, 2016 at 5:00 PM, Jafar Al-Gharaibeh  wrote:

> Acked-by: Jafar Al-Gharaibeh 
>
>
> On 4/7/2016 2:43 PM, Christian Franke wrote:
>
>> From: Christian Franke 
>>
>> It is quite useful to be able to assert whether specific interfaces have
>> flapped or also to verify that specific interfaces have not flapped.
>>
>> By having counters for those events and storing the last time of their
>> occurrence, this is made possible.
>>
>> Signed-off-by: Christian Franke 
>> ---
>>   zebra/interface.c | 15 +++
>>   zebra/interface.h |  6 ++
>>   2 files changed, 21 insertions(+)
>>
>> diff --git a/zebra/interface.c b/zebra/interface.c
>> index 8a9225a..ab0dfb5 100644
>> --- a/zebra/interface.c
>> +++ b/zebra/interface.c
>> @@ -536,6 +536,11 @@ if_up (struct interface *ifp)
>> struct listnode *next;
>> struct connected *ifc;
>> struct prefix *p;
>> +  struct zebra_if *zif;
>> +
>> +  zif = ifp->info;
>> +  zif->up_count++;
>> +  quagga_timestamp(2, zif->up_last, sizeof(zif->up_last));
>>   /* Notify the protocol daemons. */
>> zebra_interface_up_update (ifp);
>> @@ -569,6 +574,11 @@ if_down (struct interface *ifp)
>> struct listnode *next;
>> struct connected *ifc;
>> struct prefix *p;
>> +  struct zebra_if *zif;
>> +
>> +  zif = ifp->info;
>> +  zif->down_count++;
>> +  quagga_timestamp(2, zif->down_last, sizeof(zif->down_last));
>>   /* Notify to the protocol daemons. */
>> zebra_interface_down_update (ifp);
>> @@ -728,6 +738,11 @@ if_dump_vty (struct vty *vty, struct interface *ifp)
>>   vty_out (vty, "down%s", VTY_NEWLINE);
>> }
>>   +  vty_out (vty, "  Link ups:   %5ulast: %s%s", zebra_if->up_count,
>> +   zebra_if->up_last[0] ? zebra_if->up_last : "(never)",
>> VTY_NEWLINE);
>> +  vty_out (vty, "  Link downs: %5ulast: %s%s", zebra_if->down_count,
>> +   zebra_if->down_last[0] ? zebra_if->down_last : "(never)",
>> VTY_NEWLINE);
>> +
>> vty_out (vty, "  vrf: %u%s", ifp->vrf_id, VTY_NEWLINE);
>>   if (ifp->desc)
>> diff --git a/zebra/interface.h b/zebra/interface.h
>> index dbb33c5..a7522bc 100644
>> --- a/zebra/interface.h
>> +++ b/zebra/interface.h
>> @@ -188,6 +188,12 @@ struct zebra_if
>> /* Installed addresses chains tree. */
>> struct route_table *ipv4_subnets;
>>   +  /* Information about up/down changes */
>> +  unsigned int up_count;
>> +  char up_last[QUAGGA_TIMESTAMP_LEN];
>> +  unsigned int down_count;
>> +  char down_last[QUAGGA_TIMESTAMP_LEN];
>> +
>>   #if defined(HAVE_RTADV)
>> struct rtadvconf rtadv;
>>   #endif /* RTADV */
>>
>
>
> ___
> 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 14975] Re: [PATCH 00/89] Cumulus Take-3 Electric Bugaloooooooooooooooo

[Donald Sharp]

My understanding -

Paul and I are working through a bunch of issues in the background.  I'm
slammed getting a new release out so am pretty busy right now.  The take-3
branch has been rebased to the latest release already.  Paul was going to
take a schwag at fixing up a couple of the issues he had with the branch(
Is my memory correct here Paul? )

I believe the nhrp code has already been rebased ontop of the take-3 branch
as well.

donald

On Wed, Mar 30, 2016 at 11:42 AM, David Lamparter <
da...@opensourcerouting.org> wrote:

> Hi y'all,
>
> with Easter having passed - what's the status / next steps on this?
>
> Thanks,
>
> -David
>
> On Fri, Dec 11, 2015 at 06:50:44PM -0500, Donald Sharp wrote:
> [cut]
>
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14950] Re: Fwd: [PATCH 2/2] bgpd: Addition of bgp dampening configuration commands under IPv4 Multicast address family mode.

[Donald Sharp]

Balaji -

I'm currently working towards getting in the take-3 branch.  Once that is
done the next maintainer will work towards the other backlog

Donald
On Mar 19, 2016 10:38 AM, "Balaji Gurudoss"  wrote:

> Hi
>
> I think these patches didn't get applied. Can you apply it if its fine
> with you.
>
> http://patchwork.quagga.net/patch/1792/
> http://patchwork.quagga.net/patch/1791/
>
> Thanks,
>  - Balaji
>
> -- Forwarded message --
> From: Balaji Gurudoss 
> Date: Wed, Jan 20, 2016 at 10:59 PM
> Subject: [PATCH 2/2] bgpd: Addition of bgp dampening configuration
> commands under IPv4 Multicast address family mode.
> To: quagga-dev@lists.quagga.net
> Cc: Balaji Gurudoss 
>
>
> Signed-off-by: Balaji Gurudoss 
> ---
>  bgpd/bgp_route.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/bgpd/bgp_route.c b/bgpd/bgp_route.c
> index 6a45ccc..17a91f5 100644
> --- a/bgpd/bgp_route.c
> +++ b/bgpd/bgp_route.c
> @@ -13269,6 +13269,14 @@ bgp_route_init (void)
>install_element (BGP_IPV4_NODE, _damp_set3_cmd);
>install_element (BGP_IPV4_NODE, _damp_unset_cmd);
>install_element (BGP_IPV4_NODE, _damp_unset2_cmd);
> +
> +  /* IPv4 Multicast Mode */
> +  install_element (BGP_IPV4M_NODE, _damp_set_cmd);
> +  install_element (BGP_IPV4M_NODE, _damp_set2_cmd);
> +  install_element (BGP_IPV4M_NODE, _damp_set3_cmd);
> +  install_element (BGP_IPV4M_NODE, _damp_unset_cmd);
> +  install_element (BGP_IPV4M_NODE, _damp_unset2_cmd);
> +
>
>/* Deprecated AS-Pathlimit commands */
>install_element (BGP_NODE, _network_ttl_cmd);
> --
> 1.9.1
>
>
>
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14938] Quagga 1.0.20160315 Released

[Donald Sharp]

This release addresses a crash found when using redistribute statements.
It is recommended that all users upgrade to this release.


This release is up on Savannah or download at:


http://download.savannah.gnu.org/releases/quagga

http://download.savannah.gnu.org/releases/quagga/quagga-1.0.20160309.tar.gz

http://download.savannah.gnu.org/releases/quagga/quagga-1.0.20160309.tar.xz

http://download.savannah.gnu.org/releases/quagga/quagga-1.0.20160309.tar.asc


If you encounter a “404” error, Savannah mirrors are probably

still synchronizing the files, please give it another day.

This is a bug fix release of Quagga, there are no Distributor or Major
feature changes.

thanks!

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

[quagga-dev 14933] Re: A question on project roles (was Re: Monthly Quagga Meeting)

[Donald Sharp]

In general I like this proposal.  I would state though I don't see a need
to differentiate between a contributor and reviewer.  I would like to see
more people spending time reviewing incoming code.

donald

On Thu, Mar 10, 2016 at 11:31 AM, Lou Berger <lber...@labn.net> wrote:

>
> Hi Donald, (and anyone else who may have an opinion)
>
> I'm not really sure who to direct this question, but you're mail
> prompted me to send this message - so it's going to you.  My question is?
>
> On 3/10/2016 10:46 AM, Donald Sharp wrote:
> > Call for more gatekeepers
>
> What is a gatekeeper and where are Quagga project roles defined?
>
> From my vantage points I see that there are:
>
> Users:
> Folks who use quagga, and may also fill other project roles. Users
> also report issues they may find and provide feedback on planned changes.
>
> Contributors:
> Folks like me/LabN which (occasionally)  write code that is
> submitted back to the project.  I'm including both folks that fix bugs
> and author new code in this category.  Some may subdivide this category,
> but I haven't for simplicity sake.
>
> Reviewers:
> Folks that review submitted code and provide feedback.  I'm also
> including folks that test contributions and candidate releases.  (I/LabN
> have also done some of this.)
>
> Maintainers:
> Those who help Contributors get their submissions into a branch &
> mainline and shepherd a release. These folks are able to devote
> substantial time to the project either through apparent direct financial
> support for their activity or otherwise make their time available.
>
> Advisors:
> The 'grey beards' who have long(er) term perspective on the project.
>
> I can see where I and others on quagga-dev fit into this breakdown, but
> don't really see this type of breakdown documented anywhere and the
> recent discussion on this topic have (frankly) been a bit confusing to me.
>
> Thanks,
> Lou
>
> PS I'm hoping for a simple answer, but suspect there isn't one - at
> least yet.
>
>
>
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14923] Re: [PATCH 0/6] Protobuf support, and protobuf as FPM format

[Donald Sharp]

Avneesh -

I'm inclined to give an Ack to patches 1-3, especially once the small nits
are fixed.  I'm not convinced we need the ability to call random functions
from the cli even in a dev build so I would lean towards a Nack on 4-6.  I
would be interested in seeing if anyone else has thoughts on the matter
though.

donald

On Fri, Mar 11, 2016 at 3:21 PM, Avneesh Sachdev 
wrote:

> Hi,
>
> This patch set is related to the use of protobuf as a
> messaging/serialization format. A quick overview of the patches:
>
>   - Patch 1
>
> Infrastructure for using protobuf in quagga. This includes
> build-related changes, protobuf definitions for common quagga
> types and a library of routines to convert between quagga and
> protobuf types.
>
>   - Patches 2 & 3
>
> These patches modify zebra to optionally use protobuf as the
> message format over the FPM interface. The netlink format is still
> supported and remains the default.
>
>   - Patch 4
>
> Small patch that introduces the notion of a 'development build' --
> a build that may use code/features/settings that are not suitable
> for deployment.
>
>   - Patch 5
>
> [Development build only]
>
> Infrastructure that allows a user to invoke a function within a
> daemon from vtysh. This allows some white-box testing in a
> realistic setup without requiring the code to be restructured.
>
>   - Patch 6
>
> This patch adds test functions that can be used to compare the
> encode/decode performance of protobuf and netlink using the 'vty
> invoke' functionality added in the previous patch.
>
> Note that the code that defines the message format between zebra and
> FPM is dual-licensed as before (choice between GPLv2 and ISC). For
> protobuf, this includes the definitions in qpb/qpb.proto and
> fpm.proto.
>
> Please let me know if you have any questions about this work.
>
> Thanks,
> Avneesh
>
> Avneesh Sachdev (6):
>   Add support for protobuf.
>   Add protobuf support for FPM.
>   zebra: optionally use protobuf with FPM
>   build: support for "development build"
>   vtysh: support for invoking functions by name
>   zebra: add developer test functions for FPM code
>
>  .gitignore |   3 +
>  Makefile.am|   2 +-
>  common.am  |  41 +
>  configure.ac   |  65 +++-
>  fpm/.gitignore |  15 ++
>  fpm/Makefile.am|  21 +++
>  fpm/fpm.h  |  38 -
>  fpm/fpm.proto  | 119 +++
>  fpm/fpm_pb.h   |  63 
>  lib/Makefile.am|   2 +-
>  lib/thread.h   |   3 +
>  lib/vty.c  |   4 +
>  lib/vty_invoke.c   | 120 +++
>  lib/vty_invoke.h   |  30 
>  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 ++
>  vtysh/vtysh.c  |  78 ++
>  zebra/Makefile.am  |  14 +-
>  zebra/main.c   |  14 +-
>  zebra/zebra_fpm.c  | 139 ++---
>  zebra/zebra_fpm.h  |   3 +-
>  zebra/zebra_fpm_dt.c   | 275 +
>  zebra/zebra_fpm_private.h  |   5 +
>  zebra/zebra_fpm_protobuf.c | 313 ++
>  30 files changed, 2243 insertions(+), 40 deletions(-)
>  create mode 100644 common.am
>  create mode 100644 fpm/.gitignore
>  create mode 100644 fpm/Makefile.am
>  create mode 100644 fpm/fpm.proto
>  create mode 100644 fpm/fpm_pb.h
>  create mode 100644 lib/vty_invoke.c
>  create mode 100644 lib/vty_invoke.h
>  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
>  create mode 100644 zebra/zebra_fpm_dt.c
>  create mode 100644 zebra/zebra_fpm_protobuf.c
>
> --
> 1.9.1
>
>
> ___
> 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 14922] Re: [PATCH 3/6] zebra: optionally use protobuf with FPM

[Donald Sharp]

Can we get a respin of this patch with a 'GNU Zebra' replaced with 'Quagga'
and no introduction of #if def HAVE_IPV6?

thanks!

donald

On Fri, Mar 11, 2016 at 3:21 PM, Avneesh Sachdev 
wrote:

> Change zebra so that it can optionally use protobuf serialization when
> communicating with a Forwarding Plane Manager component.
>
>   * zebra/main.c
>
> Add the --fpm-format/-F command line option. This allows the user
> to control the format (protbuf|netlink) that is used to
> communicate with the FPM.
>
>   * zebra/zebra_fpm.c
>
> - zebra_init_msg_format(),
>
>   This new function is invoked on process startup to determine the
>   FPM format that should be used.
>
> - zfpm_init()
>
>   Change to accept any 'FPM message format' specified by the user
>   (via the new command line flag).
>
> - zebra_encode_route()
>
>   Tweak to use the selected FPM format.
>
>   * zebra_fpm_protobuf.c
>
> New code to build protobuf messages to be sent to the FPM.
>
>   * zebra/Makefile.am
>
> - Include common.am
>
> - Build new file zebra_fpm_protobuf.c when protobuf is available.
>
> - Link with the fpm_pb library.
>
> Signed-off-by: Avneesh Sachdev 
> ---
>  zebra/Makefile.am  |  10 +-
>  zebra/main.c   |  14 +-
>  zebra/zebra_fpm.c  | 139 +---
>  zebra/zebra_fpm.h  |   3 +-
>  zebra/zebra_fpm_private.h  |   5 +
>  zebra/zebra_fpm_protobuf.c | 313
> +
>  6 files changed, 456 insertions(+), 28 deletions(-)
>  create mode 100644 zebra/zebra_fpm_protobuf.c
>
> diff --git a/zebra/Makefile.am b/zebra/Makefile.am
> index 96dc6f0..f3265b1 100644
> --- a/zebra/Makefile.am
> +++ b/zebra/Makefile.am
> @@ -1,3 +1,5 @@
> +include ../common.am
> +
>  ## Process this file with automake to produce Makefile.in.
>
>  AM_CPPFLAGS = -I.. -I$(top_srcdir) -I$(top_srcdir)/lib
> -I$(top_builddir)/lib
> @@ -20,6 +22,10 @@ if HAVE_NETLINK
>  othersrc = zebra_fpm_netlink.c
>  endif
>
> +if HAVE_PROTOBUF
> +protobuf_srcs = zebra_fpm_protobuf.c
> +endif
> +
>  AM_CFLAGS = $(WERROR)
>
>  sbin_PROGRAMS = zebra
> @@ -30,7 +36,7 @@ zebra_SOURCES = \
> zserv.c main.c interface.c connected.c zebra_rib.c
> zebra_routemap.c \
> redistribute.c debug.c rtadv.c zebra_snmp.c zebra_vty.c \
> irdp_main.c irdp_interface.c irdp_packet.c router-id.c zebra_fpm.c
> \
> -   $(othersrc)
> +   $(othersrc) $(protobuf_srcs)
>
>  testzebra_SOURCES = test_main.c zebra_rib.c interface.c connected.c
> debug.c \
> zebra_vty.c \
> @@ -42,7 +48,7 @@ noinst_HEADERS = \
> rt_netlink.h zebra_fpm.h zebra_fpm_private.h \
> ioctl_solaris.h
>
> -zebra_LDADD = $(otherobj) ../lib/libzebra.la $(LIBCAP)
> +zebra_LDADD = $(otherobj) ../lib/libzebra.la $(LIBCAP)
> $(Q_FPM_PB_CLIENT_LDOPTS)
>
>  testzebra_LDADD = ../lib/libzebra.la $(LIBCAP)
>
> diff --git a/zebra/main.c b/zebra/main.c
> index f3c08f1..9a34b04 100644
> --- a/zebra/main.c
> +++ b/zebra/main.c
> @@ -71,6 +71,7 @@ struct option longopts[] =
>{ "batch",   no_argument,   NULL, 'b'},
>{ "daemon",  no_argument,   NULL, 'd'},
>{ "keep_kernel", no_argument,   NULL, 'k'},
> +  { "fpm_format",  required_argument, NULL, 'F'},
>{ "config_file", required_argument, NULL, 'f'},
>{ "pid_file",required_argument, NULL, 'i'},
>{ "socket",  required_argument, NULL, 'z'},
> @@ -130,6 +131,7 @@ usage (char *progname, int status)
>   "-b, --batchRuns in batch mode\n"\
>   "-d, --daemon   Runs in daemon mode\n"\
>   "-f, --config_file  Set configuration file name\n"\
> + "-F, --fpm_format   Set fpm format to 'netlink' or
> 'protobuf'\n"\
>   "-i, --pid_file Set process identifier file name\n"\
>   "-z, --socket   Set path of zebra socket\n"\
>   "-k, --keep_kernel  Don't delete old routes which installed
> by "\
> @@ -295,6 +297,7 @@ main (int argc, char **argv)
>char *progname;
>struct thread thread;
>char *zserv_path = NULL;
> +  char *fpm_format = NULL;
>
>/* Set umask before anything for security */
>umask (0027);
> @@ -310,9 +313,9 @@ main (int argc, char **argv)
>int opt;
>
>  #ifdef HAVE_NETLINK
> -  opt = getopt_long (argc, argv, "bdkf:i:z:hA:P:ru:g:vs:C", longopts,
> 0);
> +  opt = getopt_long (argc, argv, "bdkf:F:i:z:hA:P:ru:g:vs:C",
> longopts, 0);
>  #else
> -  opt = getopt_long (argc, argv, "bdkf:i:z:hA:P:ru:g:vC", longopts,
> 0);
> +  opt = getopt_long (argc, argv, "bdkf:F:i:z:hA:P:ru:g:vC", longopts,
> 0);
>  #endif /* HAVE_NETLINK */
>
>if (opt == EOF)
> @@ -336,6 +339,9 @@ main (int argc, char **argv)
> case 'f':
>   config_file = optarg;
>   break;
> +   case 'F':
> + fpm_format = optarg;
> + break;
> case 'A':
>   vty_addr = 

[quagga-dev 14921] Re: [PATCH 1/6] Add support for protobuf.

[Donald Sharp]

Can you give us some background on why proto-buf was choosen as a
communication methodology and why it's superior from a netlink perspective?

Some more thoughts inline.


On Fri, Mar 11, 2016 at 3:21 PM, 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 

[quagga-dev 14920] Re: [PATCH] lib: fix MIN/MAX macros to not double-eval

[Donald Sharp]

Acked-by: Donald Sharp <sha...@cumulusnetworks.com>

On Sat, Mar 12, 2016 at 5:12 PM, David Lamparter <
da...@opensourcerouting.org> wrote:

> On Sat, Mar 12, 2016 at 04:31:52PM -0500, Donald Sharp wrote:
> > Let me rephrase a little bit.  If this code was inspired from the linux
> > kernel I'd like to attribute it properly, if not I'm not going to get too
> > worried about it.  The code just looks similiar enough that I'd like to
> > make sure we don't run afoul of anyone shaking their virtual fists at us.
>
> I took it from the gcc docs in the assumption it's below the boundary of
> creativeness required by copyright law, but if we can copy it off the
> kernel sources that would be better (since the kernel is GPL, gcc docs
> are GFDL which is not GPL compatible).
>
>
> -David
>
> > On Sat, Mar 12, 2016 at 4:29 PM, Donald Sharp <
> sha...@cumulusnetworks.com>
> > wrote:
> >
> > > I agree this is less surprising!  I was looking at pretty much the
> exact
> > > same thing in the linux kernel on friday afternoon right as I walked
> out
> > > the door.  Should we attribute the original author?
> > >
> > > thanks!
> > >
> > > donald
> > >
> > > On Sat, Mar 12, 2016 at 1:58 PM, David Lamparter <
> > > equi...@opensourcerouting.org> wrote:
> > >
> > >> cf. https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
> > >> (Works on all compilers on Quagga's compiler support list in
> > >> doc/overview.texi)
> > >>
> > >> Signed-off-by: David Lamparter <equi...@opensourcerouting.org>
> > >> ---
> > >> Would suggest this additional fix to make the macro less surprising.
> > >>
> > >> -David
> > >>
> > >> ---
> > >>  lib/zebra.h | 12 +---
> > >>  1 file changed, 9 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/lib/zebra.h b/lib/zebra.h
> > >> index d980283..0ea5ee4 100644
> > >> --- a/lib/zebra.h
> > >> +++ b/lib/zebra.h
> > >> @@ -373,10 +373,16 @@ struct in_pktinfo
> > >>
> > >>  /* MAX / MIN are not commonly defined, but useful */
> > >>  #ifndef MAX
> > >> -#define MAX(a, b) ((a) > (b) ? (a) : (b))
> > >> -#endif
> > >> +#define MAX(a, b) \
> > >> +   ({ typeof (a) _a = (a); \
> > >> +  typeof (b) _b = (b); \
> > >> +  _a > _b ? _a : _b; })
> > >> +#endif
> > >>  #ifndef MIN
> > >> -#define MIN(a, b) ((a) < (b) ? (a) : (b))
> > >> +#define MIN(a, b) \
> > >> +   ({ typeof (a) _a = (a); \
> > >> +  typeof (b) _b = (b); \
> > >> +  _a < _b ? _a : _b; })
> > >>  #endif
> > >>
> > >>  #define ZEBRA_NUM_OF(x) (sizeof (x) / sizeof (x[0]))
> > >> --
> > >> 2.3.6
> > >>
> > >>
> > >> ___
> > >> 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 14914] Re: [PATCH 5/6] vtysh: support for invoking functions by name

[Donald Sharp]

Avneesh -

Can you expand a bit on why adding the ability to call random functions
from the cli is better than just adding a 'test XXX' function as needed?
Additionally how do you plan to allow the end user to pass in useful data
to functions if the function you want to call takes a complex data
structure?  I'm pretty dubious about adding a cause a crash button even for
developer builds, especially since adding a test XXX function is an easy
task.

donald

On Fri, Mar 11, 2016 at 3:21 PM, Avneesh Sachdev 
wrote:

> This functionality is only compiled into a developer build, It allows
> test functions to be invoked by name from the vtysh as follows.
>
> Changes:
>
>   * vtysh/vtysh.c
>
> Handle the 'invoke  function  [args]'
> command.
> Forward it the client with the given name.
>
>   * lib/vty_invoke.c
>
> Code that handles an 'invoke function' command inside a vtysh
> client process (e;g., a routing protocol daemon). It invokes the
> named function, and prints out some stats about the execution
> time.
>
>   * lib/thread.h
>
> Extern timeval_elapsed().
>
>   * lib/vty.[ch]
>
> - vty_init():
>
>   Install element for 'invoke' command handler. This sets up the
>   handler that runs inside of a vtysh client.
>
>   * lib/Makefile.am
>
> Also compile vty_invoke.c.
>
>   * configure.ac
>
> Include '-rdynamic -ldl' in LDFLAGS for a development build. These
> options allow dlsym() to work for functions inside a quagga
> program.
>
> Signed-off-by: Avneesh Sachdev 
> ---
>  configure.ac |   4 ++
>  lib/Makefile.am  |   2 +-
>  lib/thread.h |   3 ++
>  lib/vty.c|   4 ++
>  lib/vty_invoke.c | 120
> +++
>  lib/vty_invoke.h |  30 ++
>  vtysh/vtysh.c|  78 
>  7 files changed, 240 insertions(+), 1 deletion(-)
>  create mode 100644 lib/vty_invoke.c
>  create mode 100644 lib/vty_invoke.h
>
> diff --git a/configure.ac b/configure.ac
> index ae2e527..60a9118 100755
> --- a/configure.ac
> +++ b/configure.ac
> @@ -331,6 +331,10 @@ fi
>
>  if test "x${enable_dev_build}" = "xyes"; then
> AC_DEFINE(DEV_BUILD,,Build for development)
> +
> +   # Link with -ldl so that the developer build can use dlsym and
> +   # company.
> +   LDFLAGS="${LDFLAGS} -rdynamic -ldl"
>  fi
>  AM_CONDITIONAL([DEV_BUILD], [test "x$enable_dev_build" = "xyes"])
>
> diff --git a/lib/Makefile.am b/lib/Makefile.am
> index ac51fc6..17dc575 100644
> --- a/lib/Makefile.am
> +++ b/lib/Makefile.am
> @@ -13,7 +13,7 @@ libzebra_la_SOURCES = \
> sockunion.c prefix.c thread.c if.c memory.c buffer.c table.c
> hash.c \
> filter.c routemap.c distribute.c stream.c str.c log.c plist.c \
> zclient.c sockopt.c smux.c agentx.c snmp.c md5.c if_rmap.c
> keychain.c privs.c \
> -   sigevent.c pqueue.c jhash.c memtypes.c workqueue.c vrf.c
> +   sigevent.c pqueue.c jhash.c memtypes.c workqueue.c vrf.c
> vty_invoke.c
>
>  BUILT_SOURCES = memtypes.h route_types.h gitversion.h
>
> diff --git a/lib/thread.h b/lib/thread.h
> index 5bc756c..215ac5d 100644
> --- a/lib/thread.h
> +++ b/lib/thread.h
> @@ -229,6 +229,9 @@ extern time_t quagga_time (time_t *);
>  extern unsigned long thread_consumed_time(RUSAGE_T *after, RUSAGE_T
> *before,
>   unsigned long *cpu_time_elapsed);
>
> +/* Returns elapsed time in microseconds */
> +extern unsigned long timeval_elapsed (struct timeval a, struct timeval b);
> +
>  /* Global variable containing a recent result from gettimeofday.  This can
> be used instead of calling gettimeofday if a recent value is
> sufficient.
> This is guaranteed to be refreshed before a thread is called. */
> diff --git a/lib/vty.c b/lib/vty.c
> index 8befcb0..657ed97 100644
> --- a/lib/vty.c
> +++ b/lib/vty.c
> @@ -40,6 +40,8 @@
>  #include 
>  #include 
>
> +#include "vty_invoke.h"
> +
>  /* Vty events */
>  enum event
>  {
> @@ -3073,6 +3075,8 @@ vty_init (struct thread_master *master_thread)
>install_element (VTY_NODE, _ipv6_access_class_cmd);
>install_element (VTY_NODE, _vty_ipv6_access_class_cmd);
>  #endif /* HAVE_IPV6 */
> +
> +  vty_invoke_init ();
>  }
>
>  void
> diff --git a/lib/vty_invoke.c b/lib/vty_invoke.c
> new file mode 100644
> index 000..3c43568
> --- /dev/null
> +++ b/lib/vty_invoke.c
> @@ -0,0 +1,120 @@
> +/*
> + * vty_invoke.c
> + *
> + * @copyright Copyright (C) 2016 Sproute Networks, Inc.
> + *
> + * @author Avneesh Sachdev 
> + *
> + * This file is part of GNU Zebra.
> + *
> + * GNU Zebra is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2, or (at your option) any
> + * later version.
> + *
> + * GNU Zebra is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; 

[quagga-dev 14913] Re: [PATCH 1/3] bgpd, lib: Remove RESTRICTED_NODE from code base

[Donald Sharp]

No? :)

It's not clear to me at all that:

(a) allot of people use telnet over vtysh
(b) that they've read the code to know that there is a restricted
functionality that only exists for bgp
(c) and read the code to implement the functionality
(d) that people are logging in and only giving themselves limited
permissions
(e) that we are not working towards fixing performance issues that are
listed as a main cause of needing this functionality.

Having said all of that I'm not sure this is worth the argument over this
code.  I can just withdraw this part of the patches, I'm more interested in
the ENABLE_NODE and VIEW_NODE code changes...

donald

On Sat, Mar 12, 2016 at 2:15 PM, Paul Jakma  wrote:

> On Sat, 12 Mar 2016, Paul Jakma wrote:
>
> So, the question is, does anyone use or need the unauthenticated bgpd
>> telnet feature? It could be hard to answer that...
>>
>
> And these definitely exist, e.g. route-views. I can't tell exactly if
> they're using 'anonymous restricted' but it does seem some commands aren't
> there. So in principle at least this is a desired and used feature.
>
> Does that resolve the issue?
>
> regards,
> --
> Paul Jakma  p...@jakma.org  @pjakma Key ID: 64A2FF6A
> Fortune:
> The worst part of valor is indiscretion.
>
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14912] Re: [PATCH] lib: fix MIN/MAX macros to not double-eval

[Donald Sharp]

Let me rephrase a little bit.  If this code was inspired from the linux
kernel I'd like to attribute it properly, if not I'm not going to get too
worried about it.  The code just looks similiar enough that I'd like to
make sure we don't run afoul of anyone shaking their virtual fists at us.

donald

On Sat, Mar 12, 2016 at 4:29 PM, Donald Sharp <sha...@cumulusnetworks.com>
wrote:

> I agree this is less surprising!  I was looking at pretty much the exact
> same thing in the linux kernel on friday afternoon right as I walked out
> the door.  Should we attribute the original author?
>
> thanks!
>
> donald
>
> On Sat, Mar 12, 2016 at 1:58 PM, David Lamparter <
> equi...@opensourcerouting.org> wrote:
>
>> cf. https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
>> (Works on all compilers on Quagga's compiler support list in
>> doc/overview.texi)
>>
>> Signed-off-by: David Lamparter <equi...@opensourcerouting.org>
>> ---
>> Would suggest this additional fix to make the macro less surprising.
>>
>> -David
>>
>> ---
>>  lib/zebra.h | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/lib/zebra.h b/lib/zebra.h
>> index d980283..0ea5ee4 100644
>> --- a/lib/zebra.h
>> +++ b/lib/zebra.h
>> @@ -373,10 +373,16 @@ struct in_pktinfo
>>
>>  /* MAX / MIN are not commonly defined, but useful */
>>  #ifndef MAX
>> -#define MAX(a, b) ((a) > (b) ? (a) : (b))
>> -#endif
>> +#define MAX(a, b) \
>> +   ({ typeof (a) _a = (a); \
>> +  typeof (b) _b = (b); \
>> +  _a > _b ? _a : _b; })
>> +#endif
>>  #ifndef MIN
>> -#define MIN(a, b) ((a) < (b) ? (a) : (b))
>> +#define MIN(a, b) \
>> +   ({ typeof (a) _a = (a); \
>> +  typeof (b) _b = (b); \
>> +  _a < _b ? _a : _b; })
>>  #endif
>>
>>  #define ZEBRA_NUM_OF(x) (sizeof (x) / sizeof (x[0]))
>> --
>> 2.3.6
>>
>>
>> ___
>> 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 14901] Re: CI Testresult: PASSED (Re: [quagga-dev, 14893] quagga: Remove double read of stream)

[Donald Sharp]

Martin -

I've pushed this patch to master.

donald

On Fri, Mar 11, 2016 at 6:15 PM, Martin Winter <
mwin...@opensourcerouting.org> wrote:

> 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 
>>
>> This is an EXPERIMENTAL automated CI system.
>> For questions and feedback, feel free to email
>> Martin Winter .
>>
>> 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 14879] [PATCH 2/3] lib: Consolidate VIEW_NODE to be ENABLE_NODE as well

[Donald Sharp]

If you are in VIEW_NODE, the command should exist in ENABLE_NODE
as well.  This is being done to reduce chances of code being
added to one but not the other NODE.

Signed-off-by: Donald Sharp <sha...@cumulusnetworks.com>
---
 lib/command.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/command.c b/lib/command.c
index 8c8bf1b..6cff884 100644
--- a/lib/command.c
+++ b/lib/command.c
@@ -616,6 +616,9 @@ install_element (enum node_type ntype, struct cmd_element 
*cmd)
   vector_set (cnode->cmd_vector, cmd);
   if (cmd->tokens == NULL)
 cmd->tokens = cmd_parse_format(cmd->string, cmd->doc);
+
+  if (ntype == VIEW_NODE)
+install_element (ENABLE_NODE, cmd);
 }
 
 static const unsigned char itoa64[] =
-- 
1.9.1


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

[quagga-dev 14870] [PATCH 3/3] lib: Remove unnecessary paranthesis

[Donald Sharp]

The freebsd compiler complains that there is an extra set of ()'s
around the if statement.

Signed-off-by: Donald Sharp <sha...@cumulusnetworks.com>
---
 lib/vty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/vty.c b/lib/vty.c
index e4510f8..aafa271 100644
--- a/lib/vty.c
+++ b/lib/vty.c
@@ -423,7 +423,7 @@ vty_command (struct vty *vty, char *buf)
   snprintf(vty_str, sizeof(vty_str), "vty[??]@%s", vty->address);
   if (vty)
 for (i = 0; i < vector_active (vtyvec); i++)
-  if ((vty == vector_slot (vtyvec, i)))
+  if (vty == vector_slot (vtyvec, i))
 {
   snprintf(vty_str, sizeof(vty_str), "vty[%d]@%s",
  i, vty->address);
-- 
1.9.1


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

[quagga-dev 14868] [PATCH 2/3] bgpd: Fix code path that leads to uninitialized variables

[Donald Sharp]

subtype and sublength are not initialized and if on Line 1877
BGP_ATTR_ENCAP != type we will not set subtype and sublength,
but these variables are used immediately below that if statement.

This issue was discovered via the freebsd compiler.

Signed-off-by: Donald Sharp <sha...@cumulusnetworks.com>
---
 bgpd/bgp_attr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bgpd/bgp_attr.c b/bgpd/bgp_attr.c
index f34e649..149b888 100644
--- a/bgpd/bgp_attr.c
+++ b/bgpd/bgp_attr.c
@@ -1870,8 +1870,8 @@ bgp_attr_encap(
   }
 
   while (length >= 4) {
-uint16_t   subtype;
-uint16_t   sublength;
+uint16_t   subtype = 0;
+uint16_t   sublength = 0;
 struct bgp_attr_encap_subtlv *tlv;
 
 if (BGP_ATTR_ENCAP == type) {
-- 
1.9.1


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

[quagga-dev 14869] [PATCH 1/3] zebra: Remove unused #ifdef HAVE_STRUCT_SOCKADDR_DL

[Donald Sharp]

The #ifdef HAVE_STRUCT_SOCKADDR_DL is true on freebsd
but the data structures that are defined by it are
never used.  This commit removes the dead code.

Signed-off-by: Donald Sharp <sha...@cumulusnetworks.com>
---
 zebra/interface.h | 10 --
 zebra/rtadv.c |  3 ---
 2 files changed, 13 deletions(-)

diff --git a/zebra/interface.h b/zebra/interface.h
index dbb33c5..936156e 100644
--- a/zebra/interface.h
+++ b/zebra/interface.h
@@ -196,16 +196,6 @@ struct zebra_if
   struct irdp_interface irdp;
 #endif
 
-#ifdef HAVE_STRUCT_SOCKADDR_DL
-  union {
-/* note that sdl_storage is never accessed, it only exists to make space.
- * all actual uses refer to sdl - but use sizeof(sdl_storage)!  this fits
- * best with C aliasing rules. */
-struct sockaddr_dl sdl;
-struct sockaddr_storage sdl_storage;
-  };
-#endif
-
 #ifdef SUNOS_5
   /* the real IFF_UP state of the primary interface.
* need this to differentiate between all interfaces being
diff --git a/zebra/rtadv.c b/zebra/rtadv.c
index 9450f9a..fa62d97 100644
--- a/zebra/rtadv.c
+++ b/zebra/rtadv.c
@@ -132,9 +132,6 @@ rtadv_send_packet (int sock, struct interface *ifp)
   struct cmsghdr  *cmsgptr;
   struct in6_pktinfo *pkt;
   struct sockaddr_in6 addr;
-#ifdef HAVE_STRUCT_SOCKADDR_DL
-  struct sockaddr_dl *sdl;
-#endif /* HAVE_STRUCT_SOCKADDR_DL */
   static void *adata = NULL;
   unsigned char buf[RTADV_MSG_SIZE];
   struct nd_router_advert *rtadv;
-- 
1.9.1


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

[quagga-dev 14860] Monthly Quagga Meeting

[Donald Sharp]

The quagga monthly meeting is next tuesday.  If you would like an invite,
please let me know.

If you have something that you would like to talk about please let me know
and I can add it to the agenda.

Current agenda items that I would like to talk about:

1) Proposed branching scheme, sent under cover of another email
2) Call for more gatekeepers.  Please self nominate!

Additionally David Lamparter has generously agreed to give a presentation
on his current cli api abstraction work, which we will be seeing
immediately after all other agenda items have been accounted for.

thanks!

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

[quagga-dev 14858] Proposal for how to improve patch pipeline

[Donald Sharp]

Problem statement:

Patches can be in an unaccepted stated for a long time while the current
proposed branch is in a frozen state in order to get it ready for release.
This causes problems for the developer because there can be an extremely
long lead time between feedback on the patch and application to the quagga
git repository.

Proposed Solution:

Immediately after a proposed/X branch is declared 'frozen', a proposed/X+1
branch will be created off of the proposed/X branch and a new gatekeeper
will start accepting new patches on that branch.  As soon as proposed/X is
merged into master, any changes made to proposed/X will also be merged up
into proposed/X+1 by the X+1 gatekeeper.

thoughts?

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

[quagga-dev 14856] Release 1.0.20160309 of Quagga

[Donald Sharp]

Quagga 1.0.20160309 has been released.


This release addresses Security Vulnerability VU #270232.

Users using VPNv4 to untrusted peers and zebra that have

untrusted clients talking to it are advised to upgrade to

this release.


This release is up on Savannah or download at:


http://download.savannah.gnu.org/releases/quagga

http://download.savannah.gnu.org/releases/quagga/quagga-1.0.20160309.tar.gz

http://download.savannah.gnu.org/releases/quagga/quagga-1.0.20160309.tar.xz

http://download.savannah.gnu.org/releases/quagga/quagga-1.0.20160309.tar.asc


If you encounter a “404” error, Savannah mirrors are probably

still synchronizing the files, please give it another day.


Major user-visible changes:

[quagga] - Namespace VRF Support has been added.

[lib] - Add 'show commandtree'

[bgpd] - vpnv4 and vpnv6 handling has been included.

[bgpd] - Add 'set metric (rtt|+rtt|-rtt)' to route map handling.

[bgpd] - Addition of 'show ip bgp dampening' command tree.

[bgpd] - If route-map does not exist default to DENY for redistribute
statements

[bgpd] - Lower default 'timers connect' in BGP to 10 seconds.

[bgpd] - Enable "bgp log-neighbor-changes" by default

[bgpd] - Add support for timer commands with peer-group syntax

[bgpd] - Extend Dump to allow Extended Time Format

[babeld] - Removed from the distribution.

[isisd] - Allow the adjustment of lsp-mtu

[isisd] - Allow the import of routes from other protocols

[ospfd] - Add per interface 'ip ospf area' command

[ospfd] - Lower the default OSPF spf timers to '0 50 5000'

[ripngd] - Add ECMP support

[pimd] - Add multicast static routes.

[pimd] - Add ability to set DR priority for an interface

[pimd] - Add ability to modify hello and hold timers per interface

[vtysh] - Add 'show thread cpu ..' and 'show work-queues'

[vtysh] - Add 'show run ' command

[vtysh] - Fix history handling

[solaris] - Fix compilation issues.


Distributor-visible changes:

--enable-opaque-lsa is removed.  This is considered industry

  default and there should be no need to specify at compile time

  to include this feature


--enable-ospf-te is removed.  This is considered industry

  default and there should be no need to specify at compile time

  to include this feature


--enable-pimd is default.  This will allow compile time issues

  to be caught before they become a problem


--enable-vtysh is default.  This will allow compile time issues

  to be caught before they become a problem


--enable-werror has been added.  If turned on, compilation will

  turn all warnings into errors


--enable-babeld has been removed.  The babel daemon has been

  removed from Quagga distribution.


Thanks!


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

[quagga-dev 14849] Re: XR-Like Commit Feature

[Donald Sharp]

David -

Thanks for agreeing to present at the monthly meeting.  Can't wait to see
what you have.

thanks!

donald

On Tue, Mar 8, 2016 at 7:51 AM, David Lamparter  wrote:

> My plan is to present this at (or directly after, if people want to
> split the topic) the next Quagga monthly meeting.  I have some half-done
> slides that I'd like to finish, and it might also be possible to push
> out some code.
>
> Paul, from your text below ("HPEN are about to start working on this."),
> do you have a time constraint that wouldn't be met with that timeline?
>
> FWIW, it's built around pretty much the thoughts you outline below, and
> then some.  The code is working in a 3rd party setup, but I have
> medium-scale adjustments queued up (based on more "lessons learned").
>
> Cheers,
>
>
> -David
>
> P.S.: Yes, I gave no response at all on what we actually did.  I
> strongly prefer giving a thought-out introduction to the interface over
> starting to pluck away at the design from a random angle with half of
> the picture missing...
>
>
> On Fri, Mar 04, 2016 at 02:30:00PM +, Paul Jakma wrote:
> > On Thu, 3 Mar 2016, Paul Jakma wrote:
> > > On Thu, 3 Mar 2016, David Lamparter wrote:
> > >
> > >>  As for this discussion, the approach that seemed most fruitful in my
> view
> > >>  was to push transaction functionality outside of Quagga. There's no
> > >>  advantage to having it inside, since when it's properly modularised
> it
> > >>  looks like this:
> > >>
> > >>  CLI > transaction code >  settings API
> > >>  (or other config)
> > >
> > > The key thing is the API, want to publish it?
> >
> > I've had some preliminary discussions and investigations on this.
> >
> > It seems there are 2 paths:
> >
> > - Define a structured storage layer and an API both for access (r/w) of
> >objects in some structured way, and notifications
> >
> > - Annotate existing objects with the data needed to introspect them
> >(and maybe find them).
> >
> > The former might be how you'd do things if starting from scratch. The
> > downside of that way is that there's a lot of existing code to change.
> > It'd be a very big and disruptive change, and no doubt the churn would
> > introduce bugs on the routing side.
> >
> > The latter would be easier to fit in to the existing code. Code reading
> > from annotated objects might need little to no modification. The downside
> > of course is it's less encapsulated, so notifications would depend on the
> > writer initiating. The latter could also accommodate a more encapsulated
> > state/storage/settings API.
> >
> > I've played with some of the latter and the 'annotations' or
> introspection
> > objects can be added in a relatively type-safe way, using similar "encode
> > info into the C symbol space" tricks as in the memory patches you had.
> >
> > HPEN are about to start working on this. If there's existing work to
> build
> > on, collaborate with, and iterate on, that'd be great - if it's available
> > and the other parties are interested. ?? Otherwise, we will start
> > exploring the latter approach, implementation wise.
> >
> > Our aim is to able to support an OPS like architecture, where state
> > (routing state as well as config state) can be easily externalised and
> > modified.. It seems we're agreed that would have a lot of benefits. HPEN
> > are, of course, particularly interested in being able to slot-in an
> > RFC7047 like protocol to/from an external DB (i.e. the client protocol
> > side to an OpenVSwitch OVSDB).
> >
> > regards,
> > --
> > Paul Jakma, HPE Networking, Advanced Technology Group
> > Fortune:
> > He that breaks a thing to find out what it is has left the path of
> wisdom.
> >   -- J.R.R. Tolkien
> >
> > ___
> > 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 14838] Re: [PATCH 5/5] lib: Add ability to use poll() instead of select

[Donald Sharp]

It's baby steps in my mind.  I left the ability to use select over poll,
currently, was because poll causes a tiny bit higher load for smaller
working sets.  I didn't go directly to kqueue and epoll because I didn't
want to have to implement freebsd's version.

I'll rework commit messages a bit more this evening or tomorrow.  I might
rework 5 a bit more as well.  I'm not totally happy with it yet though.

donald

On Sat, Mar 5, 2016 at 10:15 AM, Paul Jakma <p...@jakma.org> wrote:

> On Fri, 4 Mar 2016, Donald Sharp wrote:
>
> This patch originated w/ Hannes Hofer <hho...@barracuda.com>.
>> I've taken the patch fixed some bugs and reworked the code
>> to allow both poll and select to be choosen at compile time.
>>
>
> Couple of comments (with one comment effectively nested inside the first
> ;) ):
>
> I'd really like a more detailed commit message on stuff like this.
> Starting with at least some kind of rationale, i.e., why do we care about
> supporting poll over select? Why don't we go directly to kqueue and epoll?
>
> regards,
> --
> Paul Jakma  p...@jakma.org  @pjakma Key ID: 64A2FF6A
> Fortune:
> It's currently a problem of access to gigabits through punybaud.
> -- J. C. R. Licklider
>
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14833] Re: CI Testresult: FAILED (Re: [quagga-dev, 14831, 5/5] lib: Add ability to use poll() instead of select)

[Donald Sharp]

Awesome -

HAVE_POLL is defined in net-snmp-config.h  I'm spinning up new patches
here shortly.

donald

On Fri, Mar 4, 2016 at 5:20 PM,  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 .
>
> Patches applied :
>   Patchwork 1850: http://patchwork.quagga.net/patch/1850
>[quagga-dev,14827,1/5] lib: Replace lists with arrays to store read
> and write threads
>   Patchwork 1851: http://patchwork.quagga.net/patch/1851
>[quagga-dev,14830,2/5] lib: Abstract fd set operations
>   Patchwork 1848: http://patchwork.quagga.net/patch/1848
>[quagga-dev,14828,3/5] lib: Refactor read/write functionality
>   Patchwork 1849: http://patchwork.quagga.net/patch/1849
>[quagga-dev,14829,4/5] lib: Refactor thread_process_fd
>   Patchwork 1852: http://patchwork.quagga.net/patch/1852
>[quagga-dev,14831,5/5] lib: Add ability to use poll() instead of
> select
> Tested on top of Git : eae18d1 (as of 20151209.135437 UTC)
> CI System Testrun URL: https://ci1.netdef.org/browse/QUAGGA-QPWORK-249/
>
>
> Get source and apply patch from patchwork: Successful
> 
>
> Building Stage: Failed
> 
> Openbsd58 amd64 build: Successful
> OmniOS amd64 build: Successful
> FreeBSD8 amd64 build: Successful
> NetBSD7 amd64 build: Successful
> Ubuntu1204 amd64 build: Successful
> FreeBSD10 amd64 build: Successful
> FreeBSD9 amd64 build: Successful
> NetBSD6 amd64 build: Successful
> Debian8 amd64 build: Successful
> Ubuntu1404 amd64 build: Successful
>
> Package building failed for CentOS6 amd64 build:(see full log in
> attachment centos6_amd64_pkgbuild.log)
> >   CC thread.lo
> > thread.c: In function 'thread_master_create':
> > thread.c:566: error: 'struct fd_handler' has no member named 'pfdsize'
> > thread.c:567: error: 'struct fd_handler' has no member named 'pfdcount'
> > thread.c:568: error: 'struct fd_handler' has no member named 'pfds'
> > thread.c:568: error: invalid application of 'sizeof' to incomplete type
> 'struct pollfd'
> > thread.c:568: error: 'struct fd_handler' has no member named 'pfdsize'
> > thread.c:569: error: 'struct fd_handler' has no member named 'pfds'
> > thread.c:569: error: invalid application of 'sizeof' to incomplete type
> 'struct pollfd'
>
> Package building failed for CentOS7 amd64 build:(see full log in
> attachment centos7_amd64_pkgbuild.log)
> >   CC   thread.lo
> > thread.c: In function 'thread_master_create':
> > thread.c:566:14: error: 'struct fd_handler' has no member named 'pfdsize'
> >rv->handler.pfdsize = 64;
> >   ^
> > thread.c:567:14: error: 'struct fd_handler' has no member named
> 'pfdcount'
> >rv->handler.pfdcount = 0;
> >   ^
> > thread.c:568:14: error: 'struct fd_handler' has no member named 'pfds'
>
>
> 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 14830] [PATCH 2/5] lib: Abstract fd set operations

[Donald Sharp]

Abstract FD set operations so that we can eventually
choose what type of select/poll operation that
we want to use.

Signed-off-by: Donald Sharp <sha...@cumulusnetowkrs.com>
---
 lib/thread.c | 69 +++-
 lib/thread.h | 12 ---
 2 files changed, 59 insertions(+), 22 deletions(-)

diff --git a/lib/thread.c b/lib/thread.c
index 6c2b0b0..9b201de 100644
--- a/lib/thread.c
+++ b/lib/thread.c
@@ -754,6 +754,41 @@ thread_get (struct thread_master *m, u_char type,
   return thread;
 }
 
+#define fd_copy_fd_set(X) (X)
+
+static int
+fd_select (int size, thread_fd_set *read, thread_fd_set *write, thread_fd_set 
*except, struct timeval *t)
+{
+  return(select(size, read, write, except, t));
+}
+
+static int
+fd_is_set (int fd, thread_fd_set *fdset)
+{
+  return FD_ISSET (fd, fdset);
+}
+
+static int
+fd_set_read_write (int fd, thread_fd_set *fdset)
+{
+  if (FD_ISSET (fd, fdset))
+return 0;
+
+  FD_SET (fd, fdset);
+
+  return 1;
+}
+
+static int
+fd_clear_read_write (int fd, thread_fd_set *fdset)
+{
+  if (!FD_ISSET (fd, fdset))
+return 0;
+
+  FD_CLR (fd, fdset);
+  return 1;
+}
+
 /* Add new read thread. */
 struct thread *
 funcname_thread_add_read (struct thread_master *m, 
@@ -764,14 +799,13 @@ funcname_thread_add_read (struct thread_master *m,
 
   assert (m != NULL);
 
-  if (FD_ISSET (fd, >readfd))
+  if (!fd_set_read_write (fd, >readfd))
 {
   zlog (NULL, LOG_WARNING, "There is already read fd [%d]", fd);
   return NULL;
 }
 
   thread = thread_get (m, THREAD_READ, func, arg, debugargpass);
-  FD_SET (fd, >readfd);
   thread->u.fd = fd;
   thread_add_fd (m->read, thread);
 
@@ -788,14 +822,13 @@ funcname_thread_add_write (struct thread_master *m,
 
   assert (m != NULL);
 
-  if (FD_ISSET (fd, >writefd))
+  if (!fd_set_read_write (fd, >writefd))
 {
   zlog (NULL, LOG_WARNING, "There is already write fd [%d]", fd);
   return NULL;
 }
 
   thread = thread_get (m, THREAD_WRITE, func, arg, debugargpass);
-  FD_SET (fd, >writefd);
   thread->u.fd = fd;
   thread_add_fd (m->write, thread);
 
@@ -923,13 +956,11 @@ thread_cancel (struct thread *thread)
   switch (thread->type)
 {
 case THREAD_READ:
-  assert (FD_ISSET (thread->u.fd, >master->readfd));
-  FD_CLR (thread->u.fd, >master->readfd);
+  assert (fd_clear_read_write (thread->u.fd, >master->readfd));
   thread_array = thread->master->read;
   break;
 case THREAD_WRITE:
-  assert (FD_ISSET (thread->u.fd, >master->writefd));
-  FD_CLR (thread->u.fd, >master->writefd);
+  assert (fd_clear_read_write (thread->u.fd, >master->writefd));
   thread_array = thread->master->write;
   break;
 case THREAD_TIMER:
@@ -1039,7 +1070,8 @@ thread_run (struct thread_master *m, struct thread 
*thread,
 }
 
 static int
-thread_process_fd (struct thread **thread_array, fd_set *fdset, fd_set 
*mfdset, int num, int fd_limit)
+thread_process_fd (struct thread **thread_array, thread_fd_set *fdset,
+  thread_fd_set *mfdset, int num, int fd_limit)
 {
   struct thread *thread;
   int ready = 0, index;
@@ -1049,10 +1081,9 @@ thread_process_fd (struct thread **thread_array, fd_set 
*fdset, fd_set *mfdset,
   for (index = 0; index < fd_limit && ready < num; ++index)
 {
   thread = thread_array[index];
-  if (thread && FD_ISSET (THREAD_FD (thread), fdset))
+  if (thread && fd_is_set (THREAD_FD (thread), fdset))
 {
-  assert (FD_ISSET (THREAD_FD (thread), mfdset));
-  FD_CLR(THREAD_FD (thread), mfdset);
+  assert (fd_clear_read_write (THREAD_FD (thread), mfdset));
   thread_delete_fd (thread_array, thread);
   thread_list_add (>master->ready, thread);
   thread->type = THREAD_READY;
@@ -1107,9 +1138,9 @@ struct thread *
 thread_fetch (struct thread_master *m, struct thread *fetch)
 {
   struct thread *thread;
-  fd_set readfd;
-  fd_set writefd;
-  fd_set exceptfd;
+  thread_fd_set readfd;
+  thread_fd_set writefd;
+  thread_fd_set exceptfd;
   struct timeval timer_val = { .tv_sec = 0, .tv_usec = 0 };
   struct timeval timer_val_bg;
   struct timeval *timer_wait = _val;
@@ -1142,9 +1173,9 @@ thread_fetch (struct thread_master *m, struct thread 
*fetch)
   thread_process (>event);
   
   /* Structure copy.  */
-  readfd = m->readfd;
-  writefd = m->writefd;
-  exceptfd = m->exceptfd;
+  readfd = fd_copy_fd_set(m->readfd);
+  writefd = fd_copy_fd_set(m->writefd);
+  exceptfd = fd_copy_fd_set(m->exceptfd);
   
   /* Calculate select wait timer if nothing else to do */
   if (m->ready.count == 0)
@@ -1178,7 +1209,7 @@ thread_fetch (struct thread_master *m, struct thread 
*fetch)
 timer_wait = _ti

[quagga-dev 14826] [PATCH 0/5] Refactor lib/thread.c and allow select/poll

[Donald Sharp]

Having the ability to scale beyond 1k fd's by using poll
is a good thing.  Also write code to setup for using
a library like libev where we can use a more efficient
os agnostic selection mechanism.

Denil Vira (1):
  lib: Replace lists with arrays to store read and write threads

Donald Sharp (4):
  lib: Abstract fd set operations
  lib: Refactor read/write functionality
  lib: Refactor thread_process_fd
  lib: Add ability to use poll() instead of select

 configure.ac |   6 +
 lib/thread.c | 434 ++-
 lib/thread.h |  49 +--
 3 files changed, 412 insertions(+), 77 deletions(-)

-- 
1.9.1


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

[quagga-dev 14831] [PATCH 5/5] lib: Add ability to use poll() instead of select

[Donald Sharp]

This patch originated w/ Hannes Hofer <hho...@barracuda.com>.
I've taken the patch fixed some bugs and reworked the code
to allow both poll and select to be choosen at compile time.

Signed-off-by: Donald Sharp <sha...@cumulusnetworks.com>
---
 configure.ac |   6 ++
 lib/thread.c | 295 ---
 lib/thread.h |  25 -
 3 files changed, 289 insertions(+), 37 deletions(-)

diff --git a/configure.ac b/configure.ac
index 3003e62..fcd78fc 100755
--- a/configure.ac
+++ b/configure.ac
@@ -302,6 +302,8 @@ AC_ARG_ENABLE(fpm,
   AS_HELP_STRING([--enable-fpm], [enable Forwarding Plane Manager support]))
 AC_ARG_ENABLE(werror,
   AS_HELP_STRING([--enable-werror], [enable -Werror (recommended for 
developers only)]))
+AC_ARG_ENABLE(poll,
+  AS_HELP_STRING([--enable-poll], [Use poll semantics instead of select]))
 
 if test x"${enable_gcc_rdynamic}" != x"no" ; then
   if test x"${enable_gcc_rdynamic}" = x"yes" -o x"$COMPILER" = x"GCC"; then
@@ -317,6 +319,10 @@ if test x"${enable_time_check}" != x"no" ; then
   fi
 fi
 
+if test "${enable_poll}" = "yes" ; then
+   AC_DEFINE(HAVE_POLL,,Compile poll support in)
+fi
+
 if test "${enable_fpm}" = "yes"; then
AC_DEFINE(HAVE_FPM,,Forwarding Plane Manager support)
 fi
diff --git a/lib/thread.c b/lib/thread.c
index cbcf2a9..674d6cd 100644
--- a/lib/thread.c
+++ b/lib/thread.c
@@ -522,7 +522,7 @@ thread_timer_update(void *node, int actual_position)
 
 /* Allocate new thread master.  */
 struct thread_master *
-thread_master_create ()
+thread_master_create (void)
 {
   struct thread_master *rv;
   struct rlimit limit;
@@ -562,6 +562,12 @@ thread_master_create ()
   rv->timer->cmp = rv->background->cmp = thread_timer_cmp;
   rv->timer->update = rv->background->update = thread_timer_update;
 
+#if defined(HAVE_POLL)
+  rv->handler.pfdsize = 64;
+  rv->handler.pfdcount = 0;
+  rv->handler.pfds = (struct pollfd *) malloc (sizeof (struct pollfd) * 
rv->handler.pfdsize);
+  memset (rv->handler.pfds, 0, sizeof (struct pollfd) * rv->handler.pfdsize);
+#endif
   return rv;
 }
 
@@ -677,7 +683,10 @@ thread_master_free (struct thread_master *m)
   thread_list_free (m, >ready);
   thread_list_free (m, >unuse);
   thread_queue_free (m, m->background);
-  
+
+#if defined(HAVE_POLL)
+  XFREE (MTYPE_THREAD_MASTER, m->handler.pfds);
+#endif
   XFREE (MTYPE_THREAD_MASTER, m);
 
   if (cpu_record)
@@ -753,45 +762,151 @@ thread_get (struct thread_master *m, u_char type,
   return thread;
 }
 
+#if defined (HAVE_POLL)
+
+#define fd_copy_fd_set(X) (X)
+
+static short
+realloc_pfds (struct thread_master *m, int fd)
+{
+  size_t oldpfdlen = m->handler.pfdsize * sizeof(struct pollfd);
+  void *newpfd = NULL;
+
+  m->handler.pfdsize *= 2;
+  newpfd = XREALLOC (MTYPE_THREAD, m->handler.pfds, m->handler.pfdsize * 
sizeof(struct pollfd));
+  if (newpfd == NULL)
+{
+  close(fd);
+  zlog (NULL, LOG_ERR, "failed to allocate space for pollfds");
+  return 0;
+}
+  memset((struct pollfd*)newpfd + (m->handler.pfdsize / 2), 0, oldpfdlen);
+  m->handler.pfds = (struct pollfd*)newpfd;
+  return 1;
+}
+
+/* generic add thread function */
+static struct thread *
+generic_thread_add(struct thread_master *m, int (*func) (struct thread *),
+  void *arg, int fd, int dir,
+  debugargdef)
+{
+  struct thread *thread;
+
+  u_char type;
+  short int event;
+
+  if (dir == THREAD_READ)
+{
+  event = (POLLIN | POLLHUP);
+  type = THREAD_READ;
+}
+  else
+{
+  event = (POLLOUT | POLLHUP);
+  type = THREAD_WRITE;
+}
+
+  nfds_t queuepos = m->handler.pfdcount;
+  nfds_t i=0;
+  for (i=0; ihandler.pfdcount; i++)
+if (m->handler.pfds[i].fd == fd)
+  {
+queuepos = i;
+break;
+  }
+
+  /* is there enough space for a new fd? */
+  if (queuepos >= m->handler.pfdsize)
+if (realloc_pfds(m, fd) == 0)
+  return NULL;
+
+  thread = thread_get (m, type, func, arg, debugargpass);
+  m->handler.pfds[queuepos].fd = fd;
+  m->handler.pfds[queuepos].events |= event;
+  if (queuepos == m->handler.pfdcount)
+m->handler.pfdcount++;
+
+  return thread;
+}
+#else
+
 #define fd_copy_fd_set(X) (X)
+#endif
 
 static int
-fd_select (int size, thread_fd_set *read, thread_fd_set *write, thread_fd_set 
*except, struct timeval *t)
+fd_select (struct thread_master *m, int size, thread_fd_set *read, 
thread_fd_set *write, thread_fd_set *except, struct timeval *timer_wait)
 {
-  return(select(size, read, write, except, t));
+  int num;
+#if defined(HAVE_POLL)
+  /* recalc timeout for poll. Attention NULL pointer is no timeout with
+  select, where with poll no timeount is -1 */
+  int timeout = -1;
+  if (timer_wait != NULL)
+timeout = (timer_wait

[quagga-dev 14827] [PATCH 1/5] lib: Replace lists with arrays to store read and write threads

[Donald Sharp]

From: Denil Vira <de...@cumulusnetworks.com>

With arrays, a thread corresponding to given fd is looked up in constant time
versus the linear time taken for list traversals.

Signed-off-by: Denil Vira <de...@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sha...@cumulusnetworks.com>
---
 lib/thread.c | 102 ++-
 lib/thread.h |   5 +--
 2 files changed, 83 insertions(+), 24 deletions(-)

diff --git a/lib/thread.c b/lib/thread.c
index 5e40261..6c2b0b0 100644
--- a/lib/thread.c
+++ b/lib/thread.c
@@ -22,6 +22,7 @@
 /* #define DEBUG */
 
 #include 
+#include 
 
 #include "thread.h"
 #include "memory.h"
@@ -525,6 +526,9 @@ struct thread_master *
 thread_master_create ()
 {
   struct thread_master *rv;
+  struct rlimit limit;
+
+  getrlimit(RLIMIT_NOFILE, );
 
   if (cpu_record == NULL) 
 cpu_record 
@@ -532,6 +536,26 @@ thread_master_create ()
 (int (*) (const void *, const void *))cpu_record_hash_cmp);
 
   rv = XCALLOC (MTYPE_THREAD_MASTER, sizeof (struct thread_master));
+  if (rv == NULL)
+{
+  return NULL;
+}
+
+  rv->fd_limit = (int)limit.rlim_cur;
+  rv->read = XCALLOC (MTYPE_THREAD, sizeof (struct thread *) * rv->fd_limit);
+  if (rv->read == NULL)
+{
+  XFREE (MTYPE_THREAD_MASTER, rv);
+  return NULL;
+}
+
+  rv->write = XCALLOC (MTYPE_THREAD, sizeof (struct thread *) * rv->fd_limit);
+  if (rv->write == NULL)
+{
+  XFREE (MTYPE_THREAD, rv->read);
+  XFREE (MTYPE_THREAD_MASTER, rv);
+  return NULL;
+}
 
   /* Initialize the timer queues */
   rv->timer = pqueue_create();
@@ -573,6 +597,18 @@ thread_list_delete (struct thread_list *list, struct 
thread *thread)
   return thread;
 }
 
+static void
+thread_delete_fd (struct thread **thread_array, struct thread *thread)
+{
+  thread_array[thread->u.fd] = NULL;
+}
+
+static void
+thread_add_fd (struct thread **thread_array, struct thread *thread)
+{
+  thread_array[thread->u.fd] = thread;
+}
+
 /* Move thread to unuse list. */
 static void
 thread_add_unuse (struct thread_master *m, struct thread *thread)
@@ -601,6 +637,25 @@ thread_list_free (struct thread_master *m, struct 
thread_list *list)
 }
 
 static void
+thread_array_free (struct thread_master *m, struct thread **thread_array)
+{
+  struct thread *t;
+  int index;
+
+  for (index = 0; index < m->fd_limit; ++index)
+{
+  t = thread_array[index];
+  if (t)
+{
+  thread_array[index] = NULL;
+  XFREE (MTYPE_THREAD, t);
+  m->alloc--;
+}
+}
+  XFREE (MTYPE_THREAD, thread_array);
+}
+
+static void
 thread_queue_free (struct thread_master *m, struct pqueue *queue)
 {
   int i;
@@ -616,8 +671,8 @@ thread_queue_free (struct thread_master *m, struct pqueue 
*queue)
 void
 thread_master_free (struct thread_master *m)
 {
-  thread_list_free (m, >read);
-  thread_list_free (m, >write);
+  thread_array_free (m, m->read);
+  thread_array_free (m, m->write);
   thread_queue_free (m, m->timer);
   thread_list_free (m, >event);
   thread_list_free (m, >ready);
@@ -718,7 +773,7 @@ funcname_thread_add_read (struct thread_master *m,
   thread = thread_get (m, THREAD_READ, func, arg, debugargpass);
   FD_SET (fd, >readfd);
   thread->u.fd = fd;
-  thread_list_add (>read, thread);
+  thread_add_fd (m->read, thread);
 
   return thread;
 }
@@ -742,7 +797,7 @@ funcname_thread_add_write (struct thread_master *m,
   thread = thread_get (m, THREAD_WRITE, func, arg, debugargpass);
   FD_SET (fd, >writefd);
   thread->u.fd = fd;
-  thread_list_add (>write, thread);
+  thread_add_fd (m->write, thread);
 
   return thread;
 }
@@ -863,18 +918,19 @@ thread_cancel (struct thread *thread)
 {
   struct thread_list *list = NULL;
   struct pqueue *queue = NULL;
+  struct thread **thread_array = NULL;
   
   switch (thread->type)
 {
 case THREAD_READ:
   assert (FD_ISSET (thread->u.fd, >master->readfd));
   FD_CLR (thread->u.fd, >master->readfd);
-  list = >master->read;
+  thread_array = thread->master->read;
   break;
 case THREAD_WRITE:
   assert (FD_ISSET (thread->u.fd, >master->writefd));
   FD_CLR (thread->u.fd, >master->writefd);
-  list = >master->write;
+  thread_array = thread->master->write;
   break;
 case THREAD_TIMER:
   queue = thread->master->timer;
@@ -903,9 +959,13 @@ thread_cancel (struct thread *thread)
 {
   thread_list_delete (list, thread);
 }
+  else if (thread_array)
+{
+  thread_delete_fd (thread_array, thread);
+}
   else
 {
-  assert(!"Thread should be either in queue or list!");
+  assert(!"Thread should be either in queue or list or array!");
 }
 
   thread->type = THREAD_UNUSED;
@@ -979,29 +1039,27 @@ thread_ru

[quagga-dev 14818] Re: Community and governance

[Donald Sharp]

Paul -

I believe I understand your logic.  I'm not sure I agree with it, but I
don't have to necessarily :)

The one thing that concerns me most is the semantics of 'rounds keeper'.
If I go and talk to someone outside of the quagga community and explain
what I do( or am attempting to do ) in the quagga community 'rounds keeper'
has no meaning and just provokes more questions.  I think I would prefer
terms that are universally understood by people and as such 'rounds keeper'
fails this test for me.

Why not call you, Vincent, and Greg the board of directors and people with
commit access maintainers?

donald

On Fri, Feb 26, 2016 at 11:02 AM, Paul Jakma  wrote:

> Hi,
>
> A topic that rumbles around in the background. Here's my view of the
> status quo. The key, for me, is that everyone should feel able to be
> involved:
>
> General governance and admin:
>
> - Quagga is a community project.
>
> - The running and development of Quagga proceeds by community consensus
>   the intersection of what is broadly acceptable - as much as possible.
>
> - Everyone is welcome to participate
>
> - The final arbiters and stewards of Quagga are the "maintainers",
>   currently Paul Jakma, Vincent Jardin, and Greg Troxel (who have been
>   with Quagga for a long time) They should operate on consensus
>   themselves.
>
> - The consensus is (or should be) documented in HACKING.md in the SCM.
>   All community members are encouraged to help update and evolve this
>   document.
>
>
> In terms of specific development processes, things have evolved and should
> continue to evolve. At present it's roughly:
>
> - Contributors submit a patch to the list as a 'diff' with a suitable
>   commit message.
>
>   The best way to do this is to prepare a commit to a local git tree and
>   use 'git send-email' to send it to the list.
>
>   As per HACKING, note the commit message is there for a number of
>   reasons. Good commit messages make life easier for everyone
>   ultimately.
>
> - Patches are tracked via 'patchwork' currently, though you may also use
>   bugzilla (create a bugzilla bug, include the bug ID in the commit with
>   "bug #ID", attach patch there, git-send-email it to the list too)
>
> - A "rounds keeper" will queue *every* patch to a set of "proposed"
>   branches, under volatile/patch-tracking/$ROUND/proposed/...
>
> - At some point, a review deadline is set - of at least 2 weeks
>   currently (if I remember correctly).
>
>   *Everyone* is entitled to give reviews, comments and objections to
>   patches queued up as proposed.
>
> - Patches by default go in. I.e. the default is a "fast-track" for
>   contributions.
>
>   Queries, objections, etc., to a (set) of patches send them off this
>   default fast-path, to a path where the contributor and the reviewers
>   should work together to find the acceptable patch-set. This may
>   require different degrees of discussion and iteration of the
>   contribution. Once there
>
> - The "rounds keeper" curates a branch with contributions that are ready
>   for integration. I.e., those on the fast-track, and any others on
>   which there is consensus. This branch is published and some kind of
>   summary sent to the list for verification and final testing (e.g.,
>   NetDEF do a wide range of platform and protocol conformance and
>   regression tests, as a very useful service to the community).
>
> - After a review window of time has passed and everything appears in
>   order, the rounds keeper may integrate the consensus patches to
>   'master', and start a new round.
>
>   Patches still in discussion from the previous should be carried
>   forward. Contributors should though re-submit if they feel something
>   has been missed.
>
> - Repeat
>
> The "rounds keeper" task should be fairly objective, and my goal is to
> have it regularly rotated around anyone able and willing to do it, as a
> 'chore'.
>
> The above might not be perfect, and it may be we need to change it. That's
> fine. Other projects do thinks like give 'windows' to people who have a
> patch train, to integrate stuff.
>
> We still don't track patch status perfectly (patchwork is great, but not
> perfect).
>
> regards,
> --
> Paul Jakma  p...@jakma.org  @pjakma Key ID: 64A2FF6A
> Fortune:
> Don't guess -- check your security regulations.
>
> ___
> 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 14817] Re: XR-Like Commit Feature

[Donald Sharp]

David -

In addition to a write up would you be willing to present it at the monthly
meeting?  We have one in a few weeks and I think that would be a good place
to get people familiar with it.

thanks!

donald

On Thu, Mar 3, 2016 at 7:13 AM, David Lamparter <
equi...@opensourcerouting.org> wrote:

> On Wed, Mar 02, 2016 at 06:09:45PM +, Paul Jakma wrote:
> > On Wed, 2 Mar 2016, Paul Jakma wrote:
> >
> > > Someone mentioned Vyatta had done some work in this area. I think
> Cumulus
> > > might have done some work on other interfaces into things too, but I'm
> not
> > > sure.
> >
> > Oh, and David Lamparter was also tinkering on stuff. There was a
> > discussion recently.
>
> Indeed, the work I had announced several months ago has come to bear
> some results;  I need to send a writeup on that to the list.
>
> As for this discussion, the approach that seemed most fruitful in my
> view was to push transaction functionality outside of Quagga.  There's
> no advantage to having it inside, since when it's properly modularised
> it looks like this:
>
> CLI > transaction code >  settings API
> (or other config)
>
> And when the settings API is properly isolated, there's no point in
> having the transaction code in the same process (or codebase, or
> language) -- you can just put some nice IPC there.  Any point where a
> transaction handler could be attached is also a point where IPC can be
> attached to modularize things.
>
> This is IMHO a very strong argument against adding much in this front.
> I believe the Cumulus approach makes the same argument, showing that
> this functionality doesn't need to be shoehorned in at brute force.
>
>
> -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 14812] Re: [PATCH 10/10] build: goodbye, gawk

[Donald Sharp]

On a side note, extract.pl.in as far as I can tell only is used to auto
generate the perl binary location.  Is there a modern distribution that
doesn't have perl in /usr/bin?  Would people mind if I removed the
extract.pl.in -> extract.pl configure creation?

donald

On Wed, Mar 2, 2016 at 8:27 PM,  wrote:

> Paul Jakma  wrote:
>
> > TBH, I'd rather nuke perl, and go back to AWK script for the
> > route-types. There was something I wanted to extent or fix to that
> > but... Perl.
> >
> > AWK is a lot more easier to pick up from scratch or just dive into for a
> > C programmer - the syntax is more compact, and it's C-like. It's also
> > just one binary.
>
> I agree, and rewrote the awk script ages ago to get rid of the "gensub"
> and make it run with stock awk, obviating the gawk dependency, too.
> The patch below did the job for me.
>
> Alas, I cannot check it anymore because my FreeBSD-4.7 got ridiculed
> as hopelessly outdated and quagga stopped even making it through autohell
> a long time ago.
>
> Martin Neitzel
>
>
> diff --git a/lib/memtypes.awk b/lib/memtypes.awk
> index 5429f6e..f980f77 100644
> --- a/lib/memtypes.awk
> +++ b/lib/memtypes.awk
> @@ -30,8 +30,6 @@
>  #
>
>  BEGIN {
> -   mlistregex = "memory_list_(.*)\\[\\]";
> -   mtyperegex = "^(MTYPE_[[:upper:]_[:digit:]]+).*";
> header = "/* Auto-generated from memtypes.c by " ARGV[0] ". */\n";
> header = header "/* Do not edit! */\n";
> header = header "\n#ifndef _QUAGGA_MEMTYPES_H\n";
> @@ -44,13 +42,15 @@ BEGIN {
>  # catch lines beginning with 'struct memory list ' and try snag the
>  # memory_list name. Has to be 3rd field.
>  ($0 ~ /^struct memory_list /) && (NF >= 3) {
> -   mlists[lcount++] = gensub(mlistregex, "\\1", "g",$3);
> +   name=$3; sub(/^memory_list_/, "", name); sub(/ *\[\].*/, "", name)
> +   mlists[lcount++] = name
>  }
>
>  # snag the MTYPE, it must self-standing and the second field,
>  # though we do manage to tolerate the , C seperator being appended
>  ($1 !~ /^\/?\*/) && ($2 ~ /^MTYPE_/) {
> -   mtype[tcount++] = gensub(mtyperegex, "\\1", "g", $2);
> +   name=$2; sub(/,$/, "", name)
> +   mtype[tcount++] = name
>  }
>
>  END {
>
> ___
> 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 14808] Re: XR-Like Commit Feature

[Donald Sharp]

Alexander -

Cumulus has almost all that, except the timer, but that would be 5 minutes
with a shell script.  Look at the tools/quagga-reload.py script in our
cm_2.5 branch on github.  We've also written an addition to vtysh which
will tell you if your cli is correct and on what line the error is.

donald

On Wed, Mar 2, 2016 at 6:43 PM, Alexander Turner 
wrote:

> Thanks for kicking off the discussion guys.
>
> So Vyatta is interesting though looking through the source code, it seems
> as if they've modified bash (I think for autocomplete functionality?) and
> written their own shell. Their commit function is hiding in here from what
> it seems.
>
> Paul, I like your reload idea and plan on using it (this in on your public
> fork?), though I'm thinking more along the lines of preventing screwups in
> the CLI which could result in lost connectivity. Along the lines of:
>
>- Don't action commands until `commit` issued
>- Review pending commands with `commit review`
>- Commit revert timer `commit revert 5` to revert commands after 5
>minutes if `commit confirm` not issued.
>
> Just thinking out loud here.
>
> AT
>
> On Thu, Mar 3, 2016 at 5:09 AM, Paul Jakma  wrote:
>
>> On Wed, 2 Mar 2016, Paul Jakma wrote:
>>
>> Someone mentioned Vyatta had done some work in this area. I think Cumulus
>>> might have done some work on other interfaces into things too, but I'm not
>>> sure.
>>>
>>
>> Oh, and David Lamparter was also tinkering on stuff. There was a
>> discussion recently.
>>
>> regards,
>> --
>> Paul Jakma  p...@jakma.org  @pjakma Key ID: 64A2FF6A
>> Fortune:
>> Fertility is hereditary.  If your parents didn't have any children,
>> neither will you.
>>
>
>
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14805] Re: XR-Like Commit Feature

[Donald Sharp]

We've implemented a couple code changes that allow you to modify the
/etc/quagga/*.conf files individually and then to load them via a reload
script, which diff's the running and the *.conf  and only applies the
actual changes needed.

You could also do a poor man's vtysh -f  if you wanted to as
well.

donald

On Wed, Mar 2, 2016 at 10:47 AM, Paul Jakma  wrote:

> On Wed, 2 Mar 2016, Alexander Turner wrote:
>
> What's the consensus amongst the community? Has anyone tried this or
>> spoken about this previously?
>>
>
> Someone mentioned Vyatta had done some work in this area. I think Cumulus
> might have done some work on other interfaces into things too, but I'm not
> sure.
>
> Interested to hear thoughts and get a discussion going...
>>
>
> The one I know about is OpenSwitch (OpenSwitch.net). They've modified the
> daemons to publish their configuration state (and routing state) into the
> OpenvSwitch "OVSDB" embedded DB via the OVSDB / RFC7047 protocol, and pick
> up on changes in that DB.
>
> See:
>
>
> http://openswitch.net/documents/user/architecture#top-level-view-of-the-system
>
> That DB has a schema, and the protocol supports transactions, so with that
> you can at least have an entire configuration verified against the schema
> and published to the daemons atomically, as a transaction. However, the
> schema might not fully capture all the requirements.
>
> I would like to get support for atomically applied configurations, and
> more structured storage of config (and maybe other) state. So we can
> support architectures like the above. It would solve problems for users and
> it would make certain technical problems easier to fix.
>
> We probably have to find a way to get there in smaller, more manageable
> chunks.
>
> regards,
> --
> Paul Jakma  p...@jakma.org  @pjakma Key ID: 64A2FF6A
> Fortune:
> Never do today what you can put off until tomorrow.
>
>
> ___
> 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 14775] Re: [PATCH 04/10] lib: migrate to new memory-type handling

[Donald Sharp]

David -

As a heads up, after we get the current proposed/6/ff into main and a new
release released,  I intend to start working in the cumulus take-3 branch
on the next iteration of work.  If you would like to rebase to there, I
would be willing to help you do that.

donald

On Wed, Feb 24, 2016 at 7:18 PM, David Lamparter <equi...@diac24.net> wrote:

> On Wed, Feb 24, 2016 at 06:25:06PM -0500, Donald Sharp wrote:
> > I'm not a big fan of #if 0 or #if 1's introduced with this patch.  Is
> there
> > someway we can mitigate them?
>
> This is what the comments from Paul & myself in the other mail referred to:
> > Paul:
> > > - The __builtin_types_{expect,compatible_p} stuff, would C11 _Generic
> > >allow the same to be achieved?
> >
> > The __builtin_types_* stuff is actually in a commented-out section that
> > I forgot to remove.  It was there for temporary compatibility between
> > the old and new schemes, so that the code works correctly even at every
> > single step in the middle.
>
> I'll resend a version (in a bit - eta a day or two) with
> - this fixed (i.e. removed)
> - whitespace cleaned
> - it applying on the rebased git tree :S
>
>
> -David
>
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev