Fix: reverse logic of when to pass the supplied group address
This was causing a crash when no group address was passed
because a garbage pointer valuse was used. It also was ignoring
the group address when passing one.
Hung-Weic Chiu [Tue, 2 May 2017 00:28:41 +0000 (00:28 +0000)]
Revert "Fix the "Use-after-free" of clang SA."
- This's the wrong way to fix this problem.
- Since the "TAILQ_FIRST()" always return diferent pointer as we call "TAILQ_REMOVE()", the clang static analyzer can't detect this behavior.
- Ignore this warning and keep files identical to its original one.
We shouldn't check the operational status of an interface in ldpd if
it's configured with "no link-detect" in zebra. That's what all the
other routing daemons do.
Restore the original logic in netlink_link_change() which works like this:
* once an interface event is detected, lookup the associated interface
by its name;
* call the set_ifindex() function;
* set_ifindex() will lookup the interface again but now by its ifindex. If
the lookups by name and ifindex yield to different results, then the
interface was renamed and set_ifindex() will take care of that.
In the future, zns->if_table will be split into two different data
structures to allow faster lookups by both name and ifindex.
Quentin Young [Fri, 28 Apr 2017 22:45:59 +0000 (22:45 +0000)]
lib: allow nonblocking thread_fetch()
This change adds three fields to thread_master and associated code to
use them. The fields are:
* long selectpoll_timeout
This is a millisecond value that, if nonzero, will override the
internally calculated timeout for select()/poll(). -1 indicates
nonblocking while a positive value indicates the desired timeout in
milliseconds.
* bool spin
This indicates whether a call to thread_fetch() should result in a loop
until work is available. By default this is set to true, in order to
keep the default behavior. In this case a return value of NULL indicates
that a fatal signal was received in select() or poll(). If it is set to
false, thread_fetch() will return immediately. NULL is then an
acceptable return value if there is no work to be done.
* bool handle_signals
This indicates whether or not the pthread that owns the thread master
is responsible for handling signals (since this is an MT-unsafe
operation, it is best to have just the root thread do it). It is set to
true by default. Non-root pthreads should set this to false.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
zebra: fix infinite loop when deleting non-default vrf
How to reproduce the bug:
% ip link add vrf-red type vrf table 10
% ip link set dev vrf-red up
% ip rule add oif vrf-red table 10
% ip rule add iif vrf-red table 10
% ip link add name lo1 type dummy
% ip link set dev lo1 up
% ip link set dev lo1 master vrf-red
% ip link del dev vrf-red
(zebra gets stuck in an infinite loop inside work_queue_run())
Quentin Young [Sun, 16 Apr 2017 03:14:36 +0000 (03:14 +0000)]
lib: add pthread manager
Adds infrastructure for keeping track of pthreads.
The general idea is to maintain a daemon-wide table of all pthreads,
running or not. A pthread is associated with its own thread master that
can be used with existing thread.c code, which provides user-space
timers, an event loop, non-blocking I/O callbacks and other facilities.
Each frr_pthread has a unique identifier that can be used to fetch it
from the table. This is to allow naming threads using a macro, for
example:
The idea here is to be relatively flexible with regard to how daemons
manage their collection of pthreads; the implementation could get away
with just some #define'd constants, or keep a dynamically allocated data
structure that provides organization, searching, prioritizing, etc.
Overall this interface should provide a way to maintain the familiar
thread.c userspace threading model while progressively introducing
pthreads.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Mon, 17 Apr 2017 18:33:58 +0000 (18:33 +0000)]
lib: additional thread.c MT-safety work
Fixes a few insufficient critical sections. Adds back locking for
thread_cancel(), since while thread_cancel() is only safe to call from
the pthread which owns the thread master due to races involving
thread_fetch() modifying thread master's ready queue, we still need
mutual exclusion here for all of the other public thread.c functions to
maintain their MT-safety.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Donald Sharp [Fri, 28 Apr 2017 02:04:56 +0000 (22:04 -0400)]
ospf6d: Fix parse_type_spec
The function parse_type_spec was always looking in argv[0] of
for figuring out the type of the command. Since the type location
could change, use the passed in idx_lsa.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 27 Apr 2017 17:13:30 +0000 (13:13 -0400)]
bgpd: Fix 'show .. bgp ... neighbors ' command
The 'show ip bgp neighbors swp31s0' command was not
working properly. This fixes that issue.
This command still has issues that need to be investigated
but for the moment this gets the command working in the
form that is needed. More rework can come.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 27 Apr 2017 15:00:25 +0000 (11:00 -0400)]
bgpd: Modify 'show ... bgp ... summary' to only display pertinent info
Modify the 'show ... bgp ... summary' command when you are
looking at a afi( with no safi specified ) to only display
output for those safi's that have been configured.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The use of VTY_DECLVAR_CONTEXT(bgp, bgp) here is wrong as we are not
inside the "router bgp" configuration node. This was making the clear
commands always fail with a "Current configuration object was deleted
by another process" error, which doesn't make any sense.
Also, the bgp_clear() function will already check for us if the given
peer-group or neighbor exists or not, there's no need to duplicate this
logic here.
Daniel Walton [Wed, 26 Apr 2017 21:45:32 +0000 (21:45 +0000)]
Update to draft-ietf-idr-bgp-prefix-sid-05
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
The initial implementation was against draft-keyupate-idr-bgp-prefix-sid-02
This updates our label-index implementation up to draft-ietf-idr-bgp-prefix-sid-05
- changed BGP_ATTR_LABEL_INDEX to BGP_ATTR_PREFIX_SID
- since there are multiple TLVs in BGP_ATTR_PREFIX_SID you can no longer
rely on that flag to know if there is a label-index for the path. I
changed bgp_attr_extra_new() to init the label_index to
BGP_INVALID_LABEL_INDEX
- put some placeholder code in for the other two TLVs (IPv6 and
Originator SRGB)
Daniel Walton [Wed, 26 Apr 2017 15:53:35 +0000 (15:53 +0000)]
BGP_ATTR_LABEL_INDEX fixes
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
- cleaned up the "show bgp ipv4 labeled-unicast x.x.x.x" output
- fixed some json keys to use camelCase
- bgp_attr_label_index() was clearing BGP_ATTR_LABEL_INDEX because it
was comparing mp_update->afi against SAFI_LABELED_UNICAST instead of
mp_update->safi
Don Slice [Fri, 21 Apr 2017 18:18:42 +0000 (11:18 -0700)]
zebra: fix attempt to install a second rib from imported table entries
Problem reported by a customer with prefix imported by rdnbrd not being
successfully installed in the quagga rib. Determined that this was due
to VRR resolving the same arp entry, causing two entries to be installed
in table 10. When these were imported into the quagga rib, they came in
as two different rib entries from the same table/instance, which is not
permitted and caused them to be deleted.
Added logic to zebra_add_import_table_entry to do the same actions as
rib_add and delete the older rib entry if a new rib entry is received
which matches.
Manual testing successful and automated tests for redistribute neighbor
have the same passes and failures as the base.
Ticket: CM-15926 Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by:
When the transport address is changed, all interfaces and targeted
neighbors are temporary disabled in the ldpe process until new sockets
bound to the new transport address are received from the parent.
This patch fixes a problem in which adjacencies weren't being removed
after the associated targeted neighbors were disabled. This was causing
ldpd not to set some MD5 sockoptions for new neighbors are thus preventing
MD5-protected sessions to come up after a change in the transport-address.
It's doesn't make sense to enforce that a targeted-hello is received
on an LDP-enabled interface. It should be possible, for example, to use
LDP only to signal pseudowires and other another protocol (e.g. RSVP-TE)
to create end-to-end LSPs.
ldpd: schedule the sending of label messages when necessary
Once we send a Label Withdraw, we can't send a Label Mapping for the
same FEC until we receive a Label Release from the peer. This is due to
some limitations in the LDP algorithms described in Appendix A. ("LDP
Label Distribution Procedures") of RFC 5036.
To workaround this issue, make it possible to schedule the sending of
a Label Mapping as soon as a Label Release is received for the same FEC.
The easiest way to test this patch is by typing the "label local advertise
explicit-null" command. ldpd will withdraw all null labels using a
Wildcard FEC and then send new Label Mappings as soon the corresponding
Label Releases are received.
On unstable networks, routes can be lost and relearned very often. If
we deallocate the input label every time a route is lost and allocate
a new one when the route is relearned, a lot of changes are made in vain.
This patch introduces a logic in which labels are preserved for at least
five minutes before being deallocated by the LIB garbage collector. This
is consistent with what other implementations do.
ldpd: accept notifications during the session establishment process
If we don't do this, we'll never trigger the backoff exponential timer
since it's impossible to distinguish between Initialization NAK's and
general errors.
Also:
* Implement some missing bits from RFC 5036;
* remove superfluous log message in session_shutdown()
(send_notification() logs that we're sending a fatal notification).
ldpd: use synchronous channels for sending log messages
This is necessary to guarantee that all log messages sent from the child
processes are received in the parent process right away.
Without this patch, when a child process calls fatal() or fatalx(),
the log messages don't make it to the parent because the child doesn't
have a chance to flush its buffers before exiting.
When ldpd fails to start for some reason, like failing to create a pid
file, the child processes call their shutdown functions without being
completely initialized. This patch adds some protections to prevent a
segmentation fault on such circumstances.
ldpd: simplify initialization of the child processes
In order to have separate ASLR/cookies per process, ldpd calls exec()
in the child processes after fork() (this is also known as the fork+exec
model).
This is an important security feature but it makes the initialization
of the child processes a bit more complicated as they're not a copy of
the parent anymore, so all parameters given via command line are lost.
To solve this problem, we were creating an argv array by hand with all
necessary parameters and providing it to the exec() syscall. This works
but it's a very ugly solution. This patch introduces a different approach
to solve the problem: send an IMSG_INIT message to the child processes
with all parameters they need in order to initialize properly. This
makes adding additional initialization parameters much more convenient
and less error prone.