commit 8e7e87593e1b40368f99a6694b982eb8c7dcab1a
Author: David Lamparter <[email protected]>
Date:   Mon Aug 25 18:56:53 2014 +0200

   release: 0.99.23.1

commit 90444ca35e3037ed43ec695428f0ef6d82f9a320
Author: David Lamparter <[email protected]>
Date:   Tue Jul 1 16:14:05 2014 +0200

   lib: unset ZEBRA_IFA_PEER if no dst addr present (BZ#801)

   On OpenBSD, carp interfaces claim to be PtP interfaces with a 0.0.0.0/0
   peer address.  We process those in zebra and try to send them to
   clients, at which point they get encoded as all-0.  The client code,
   however, decodes that to a NULL pointer instead of 0.0.0.0.  This later
   turns into a SEGV when CONNECTED_PREFIX sees that ZEBRA_IFA_PEER is set
   and tries to access the peer prefix.

   This is a band-aid fix for stable/0.99.23, a long-term solution needs
   some conceptual improvements on the entire thing.

   (The usefulness of a PtP-to-0.0.0.0/0 is a separate question;  at this
   point dropping the peer prefix seems the least intrusive solution.)

   Reported-by: Laurent Lavaud <[email protected]>
   Signed-off-by: David Lamparter <[email protected]>

commit ad2f92b6b07883f6a2a26499eab1776933185960
Author: David Lamparter <[email protected]>
Date:   Mon Aug 18 18:05:25 2014 +0200

   isisd: type mix-up in 28a8cfc "don't require IPv4"

   Whoops, these are in6_addrs, not prefix_ipv6... funnily enough, it does the
   right thing either way, if it compiles, which it only does on Linux because
   IN6_IS_ADDR_LINKLOCAL contains a cast to the right type.  On BSD there is no
   such cast, hence it explodes on trying to compile, trying to access struct
   members of in6_addrs while operating on prefix_ipv6...

   Fixes: 28a8cfc ("isisd: don't require IPv4 for adjacency")
   Signed-off-by: David Lamparter <[email protected]>

commit 4c005e3f65a1f5b4592b1ebbac392cbb1a710998
Author: John Glotzer <[email protected]>
Date:   Mon Aug 4 19:39:23 2014 +0000

   bgpd: memmove needed in community_del_val

   In bgpd/bgp_community_del_val memcpy is used for potentially overlapping
   regions which is *not* safe. It may "work" in some cases but is not
   guaranteed to work in all cases. The case that I saw fail was on an
   x86_64 architecture with the number of bytes being moved/copied equal to
   8.

   The way the code is written the uint32_t pointers will always differ by
   1, which is equivalent to a memcpy/memmove of regions that are 4 bytes
   away from one another. So the code failed while copying an 8 byte region
   to an address that is 4 bytes lower i.e. overlapping regions.

   Interestingly, the same architecture had no problems with a 12 byte
   copy.

   When the code failed the communities were [200,300,400] and a call was
   made to delete the 200 community. The result of this was an array that
   looked like [400,400] which was uniquified to [400]. Of course the
   expected result should have been [300, 400].

   One additional point - in our production environment memmove would not
   *link* without including <string.h> but in an isolated quagga git repo
   this #include does not seem to be required and I see memmove is used in
   vtysh.c without this #include either.

   Signed-off-by: David Lamparter <[email protected]>

commit 3ef0b877f08344aa52367794aa4ec32b12becd6d
Author: Timo Teräs <[email protected]>
Date:   Tue Jul 29 09:41:56 2014 +0000

   build: do not assume glibc on linux

   The whole IPv6 stack detection could need refactoring. But this
   fixes the linux check to not assume glibc. Fixes build against
   musl c-library.

   Signed-off-by: Timo Teräs <[email protected]>
   Signed-off-by: David Lamparter <[email protected]>

commit c299ed717eea4dbf7ca3581bcba05ff09f79276c
Author: Timo Teräs <[email protected]>
Date:   Tue Jul 29 09:41:55 2014 +0000

   zebra: fix struct msghdr initializers

   struct msghdr field orders are not strictly specified in POSIX.
   Improve portability by using designated initializer. This fixes
   build against musl c-library where struct msghdr is POSIX
   compliant (Linux kernel and glibc definitions are non-conforming).

   As the result is also more readable, struct iovec initilizers
   were also converted.

   Signed-off-by: Timo Teräs <[email protected]>
   Signed-off-by: David Lamparter <[email protected]>

commit 16ffb26fbbf8b3d1fee7a14eb401ecb02eed5058
Author: Timo Teräs <[email protected]>
Date:   Tue Jul 29 09:41:54 2014 +0000

   *: fix detection and usage of sys/cdefs.h

   This header is non-standard (though present on many systems) and
   there is no standard for what it should or should not define.

   Remove it where it is not really needed. But add also a configure
   check, so it can be used if available but otherwise fallback to
   defining the needed macroes.

   Signed-off-by: Timo Teräs <[email protected]>
   Signed-off-by: David Lamparter <[email protected]>

commit 28a8cfcbc3a5cc74bb3b87981b878f8b4edc2dd6
Author: David Lamparter <[email protected]>
Date:   Sun Jun 29 13:48:18 2014 +0200

   isisd: don't require IPv4 for adjacency

   This was precluding isisd from IPv6-only operation; no adjacency would
   come up unless there was IPv4 in parallel.

   Reported-by: Martin Winter <[email protected]>
   Signed-off-by: David Lamparter <[email protected]>

commit 8b16ed74fa61523c3348d2584b66a56a8ad4e350
Author: David Lamparter <[email protected]>
Date:   Sun Jul 6 22:33:48 2014 +0200

   tests/bgpd: don't hardcode error number (fix f57000c)

   f57000c ("bgpd: don't send NOTIFY twice for malformed attrs") introduces
   BGP_ATTR_PARSE_ERROR_NOTIFYPLS as additional error code that implies the
   caller should sent a NOTIFY and convert it to BGP_ATTR_PARSE_ERROR.
   Sadly, the latter was hardcoded in bgp_mp_attr_test.c, which now didn't
   consider the new value to be an error.

   Make the testcase treat all nonzero values as error without discern.

   Signed-off-by: David Lamparter <[email protected]>

commit f57000c0dbdd0e30e71b6651022392f284201e19
Author: David Lamparter <[email protected]>
Date:   Wed Jun 4 01:01:10 2014 +0200

   bgpd: don't send NOTIFY twice for malformed attrs

   Most of the attribute parsing functions were already sending a notify,
   let's clean up the code to make it happen only once.

   Signed-off-by: David Lamparter <[email protected]>

commit bb02b82354a80f74706efc5e4c914b3f89fb033e
Author: David Lamparter <[email protected]>
Date:   Wed Jun 4 01:01:00 2014 +0200

   bgpd: fix IP endianness in debug message

   inet_ntop expects network byte order.

   Signed-off-by: David Lamparter <[email protected]>

commit f80f838b2f54738937ef1281b237710132195c44
Author: David Lamparter <[email protected]>
Date:   Wed Jun 4 01:00:51 2014 +0200

   bgpd: fix memory leak on malformed attribute

   When bgp_attr_parse returns BGP_ATTR_PARSE_ERROR, it may already have
   parsed and allocated some attributes before hitting that error.  Free
   the attr's data before returning.

   Signed-off-by: David Lamparter <[email protected]>

commit 27bf90a14670283a899b96c56dd23f8413e0973e
Author: David Lamparter <[email protected]>
Date:   Wed Jun 4 00:59:01 2014 +0200

   bgpd: fix double free after extcommunity set (BZ#799)

   The route-map extcommunity set code was incorrectly assuming that it
   owns the intern'd struct ecommunity reference.  In reality, the intern'd
   reference belongs to bgp_update_receive() and we're not supposed to
   touch it in the route-map code.

   Instead, like all the other set commands, we use a on-heap but
   non-intern'd ecommunity to set the new value.  This is then either
   intern'd in bgp_update_main/_rsclient() through bgp_attr_intern(), or
   free'd through bgp_attr_flush().

   This fixes Bugzilla #799, which is that bgpd otherwise crashes with a
   double free.  The ecommunity got unintern'd first in the route-map set
   command, then in bgp_update_receive().

   Debugged-by: Milan Kocian <[email protected]>
   Reported-by: Florian S <[email protected]>
   Signed-off-by: David Lamparter <[email protected]>

commit 73d78ea0153fd36a300be5fec2ef0fca34a67477
Author: David Lamparter <[email protected]>
Date:   Wed Jun 4 00:58:47 2014 +0200

   bgpd: remove duplicate route-map extcommunity code

   route_set_ecommunity_rt and _soo share almost all of their code.
   Let's remove one of the redundant copies.

   Signed-off-by: David Lamparter <[email protected]>

commit c460e5720c1101a6da53e5b753b736ac2c7981af
Author: David Lamparter <[email protected]>
Date:   Wed Jun 4 00:54:58 2014 +0200

   bgpd: fix some bgp_update_main() attribute leaks

   bgp_update_main() wasn't doing anything to release attribute values
   set from route maps for two of its error paths.  To fix, pull up the
   appropriate cleanup from further down and apply it here.

   bgp_update_rsclient() doesn't have the issue since it immediately
   does bgp_attr_intern() on the results from bgp_{export,import}_modifier.

   Signed-off-by: David Lamparter <[email protected]>

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.