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 <equinox@opensourcerouting.org>
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 <mwinter@netdef.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
*: 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 <timo.teras@iki.fi>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
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 <timo.teras@iki.fi>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
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 <timo.teras@iki.fi>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
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 <equinox@opensourcerouting.org>
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 <equinox@opensourcerouting.org>
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 <laurent.lavaud@ladtech.fr>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
release: 0.99.23.1