RCA:
when client is killed, show running-config command crashes vtysh.
vtysh_client_config function temporarily makes vty->of which is standard output file
pointer to null inorder to suppress output to user.
This call further tries to communicate with each client and when the client
is terminated, socket call fails and hits the exception path to print the
connection has failed using vty_out.
vty_out crashes because vtysh_client_config has temporarily made vty->of
pointer to NULL to supress o/p to user.
Fix:
vty_out function should check for the sanity of vty->of pointer.
If it doesn't exist, this must have hit exception path, so use the
vty->saved_of if exists.
Signed-off-by: Saravanan K <saravanank@vmware.com>
The `--enable-pcreposix` configure option was not actually compiling
properly. Follow pre-existing pattern for inclusion of regex.h
or the pcreposix.h header.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Load the startup configuration directly into the CLI shared candidate
configuration instead of loading it into a private candidate
configuration. This way we don't need to initialize the shared
candidate separately later as a copy of the running configuration,
which is a potentially expensive operation.
Also, make the northbound process SIGHUP correctly even when --tcli
is not used.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Adding a lock to protect the global running configuration doesn't
help much since the FRR daemons are not prepared to process
configuration changes in a pthread that is not the main one (a
whole lot of new protections would be necessary to prevent race
conditions).
This means the lock added by commit 83981138 only adds more
complexity for no benefit. Remove it now to simplify the code.
All northbound clients, including the gRPC one, should either run
in the main pthread or use synchronization primitives to process
configuration transactions in the main pthread.
This reverts commit 83981138fe.
The FRR community has run into an issue where keeping up our
CI system to work with solaris has become a fairly large burden.
We have also sent emails and asked around and have not found
anyone standing up saying that they are using Solaris.
Given the fact that we do not have any comprehensive testing
being done w/ solaris and the fact that we are getting a steady
stream of new features that will never work on solaris and
we cannot find anyone to say that they are using it. Let's
start the drawn out process of deprecating the code.
If in the mean-time someone comes forward with the fact that
they are using it we can then not deprecate it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The correct cast for these is (unsigned char), because "char" could be
signed and thus have some negative value. isalpha & co. expect an int
arg that is positive, i.e. 0-255. So we need to cast to (unsigned char)
when calling any of these.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Adding a read with the address of the thread pointer we want to
use will allow lib/thread.c to properly handle your thread pointers.
Instead we were setting the pointer to NULL before we passed
into the _read and _write thread functions. Remove the NULL
pointer set and just let thread.c handle everything.
vty_stdio_resume and vty_read would blindly add read and write
which would cause vty_event() to drop the thread pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We need to be calling snprintfrr() instead of snprintf() in places that
wrap snprintf in some user-exposed way; otherwise the extensions won't
be available for those functions.
Signed-off-by: David Lamparter <equinox@diac24.net>
Even when using the classic CLI mode (i.e. when --tcli is not
used), the northbound code still uses vty->candidate_config
to perform configuration changes. From the perspective of the
user, the running configuration is being edited directly, but
under the hood the northbound layer does a full configuration
transaction for each command. When the running configuration is
edited by a northbound client other than the CLI (e.g. kernel,
gRPC), vty->candidate_config might become outdated, and this can
lead to lots of weird problems. To fix this, always regenerate
vty->candidate_config before each configuration command when
using the classic CLI mode. When using the transactional CLI,
the user needs to update the candidate manually using the "update"
command, otherwise the "commit" command will fail with this error:
"% Candidate configuration needs to be updated before commit".
Fixes some problems reported by Don after moving an interface from
one VRF to another one while zebra is running.
Reported-by: Don Slice <dslice@cumulusnetworks.com>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This makes printfrr extensions available in most of our format strings.
snprintf() is the obvious exception.
Signed-off-by: David Lamparter <equinox@diac24.net>
Add 'no log commands' cli and at the same time add a
--command-log-always to the daemon startup cli.
If --command-log-always is specified then all commands are
auto-logged and the 'no log commands' form of the command
is now ignored.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The upcoming gRPC-based northbound plugin will run on a separate
pthread, and it will need to have access to the running configuration
global variable. Introduce a rw-lock to control concurrent access
to the running configuration. Add the lock inside the "nb_config"
structure so that it can be used to protect candidate configurations
as well (this might be necessary depending on the threading scheme
of future northbound plugins).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The ability to lock the running configuration to prevent other users
from changing it is a very important one. We already supported
the "configure exclusive" command but the lock was applied to
the CLI users only (other clients like ConfD could still commit
configuration transactions, ignoring the CLI lock). This commit
introduces a global lock for the running configuration that is
shared by all northbound clients, and provides a public API to
manipulate it. This way other northbound clients will also be able
to lock/unlock the running configuration if required (the upcoming
gRPC northbound plugin will have RPCs for that).
NOTE: this is a management-level lock for the running configuration,
not to be confused with low-level locks used to avoid data races.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
We can make use of the vty->config variable to know when the CLI
user is in the configuration mode or not. This is much simpler
than obtaining this information from the vty node, and also a more
robust solution (the three switch statements below, for example,
were out of sync).
Also, fix a bug where vty->config wasn't being unset in the
vty_config_exit() function (bug introduced by commit f344c66ea3).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The CLI code uses the vty->xpath[] array and the vty->xpath_index
variables to keep track of where the user is in the configuration
hierarchy. As such, we were resetting vty->xpath_index to zero
whenever the user exited from the configuration mode in order to
keep the index valid. We weren't doing this in the vty_stop_input()
function however, which is called when the user types ^C in the
terminal. This was leading to bugs like this:
zebra> en
zebra# conf t
zebra(config)# interface eth0
zebra(config-if)# ^C
zebra# conf t
zebra(config)# interface eth0
% Configuration failed.
Schema node not found.
YANG path: /frr-interface:lib/interface[name='eth0'][vrf='default']/frr-interface:lib
To fix this, do something more clever: instead of resetting the
XPath index whenever the user exits from the configuration mode,
do that when the user enters in the configuration mode. This way
the XPath index needs to be reset in a single place only, not to
mention it's a more robust solution.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Confirmed commits allow the user to request an automatic rollback to
the previous configuration if the commit operation is not confirmed
within a number of minutes. This is particularly useful when the user
is accessing the CLI through the network (e.g. using SSH) and any
configuration change might cause an unexpected loss of connectivity
between the user and the managed device (e.g. misconfiguration of a
routing protocol). By using a confirmed commit, the user can rest
assured the connectivity will be restored after the given timeout
expires, avoiding the need to access the router physically to fix
the problem.
When "commit confirmed TIMEOUT" is used, a new "commit" command is
expected to confirm the previous commit before the given timeout
expires. If "commit confirmed TIMEOUT" is used while there's already
a confirmed-commit in progress, the confirmed-commit timeout is
reset to the new value.
In the current implementation, if other users perform commits while
there's a confirmed-commit in progress, all commits are rolled back
when the confirmed-commit timeout expires. It's recommended to use
the "configure exclusive" configuration mode to prevent unexpected
outcomes when using confirmed commits.
When an user exits from the configuration mode while there's a
confirmed-commit in progress, the commit is automatically rolled
back and the user is notified about it. In the future we might
want to prompt the user if he or she really wants to exit from the
configuration mode when there's a pending confirmed commit.
Needless to say, confirmed commit only work for configuration
commands converted to the new northbound model. vtysh support will
be implemented at a later time.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
A while ago all FRR configuration commands were converted to use the
QOBJ infrastructure to keep track of configuration objects. This
means the configuration lock isn't necessary anymore because the
QOBJ code detects when someones tries to edit a configuration object
that was deleted and react accordingly (log an error and abort the
command). The possibility of accessing dangling pointers doesn't
exist anymore since vty->index was removed.
Summary of the changes:
* remove the configuration lock and the vty_config_lockless() function.
* rename vty_config_unlock() to vty_config_exit() since we need to
clean up a few things when exiting from the configuration mode.
* rename vty_config_lock() to vty_config_enter() to remove code
duplication that existed between the three different "configuration"
commands (terminal, private and exclusive).
Configuration commands converted to the new northbound model don't
need the configuration lock either since the northbound API also
detects when someone tries to edit a configuration object that
doesn't exist anymore.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When reading in config files and we have failures on multiple
lines actually note the actual failure lines and return them.
This fixes an issue where we stopped counting errors after
the first one and we got missleading line numbers that
did not correspond to the actual problem.
This is fixed:
sharpd@donna ~/frr> sudo /usr/lib/frr/pimd --log=stdout -A 127.0.0.1 -f /etc/frr/pimd.conf
2018/10/11 09:41:01 PIM: VRF Created: default(0)
2018/10/11 09:41:01 PIM: pim_vrf_enable: for default
2018/10/11 09:41:01 PIM: zclient_lookup_sched_now: zclient lookup immediate connection scheduled
2018/10/11 09:41:01 PIM: zclient_lookup_new: zclient lookup socket initialized
2018/10/11 09:41:01 PIM: pimd 6.1-dev starting: vty@2611
2018/10/11 09:41:01 PIM: [EC 100663304] ERROR: No such command on config line 2: inteface lo
2018/10/11 09:41:01 PIM: [EC 100663304] ERROR: No such command on config line 3: ip igmp
2018/10/11 09:41:01 PIM: [EC 100663304] ERROR: No such command on config line 4: ip igmp join 224.1.1.1 13.13.13.2
^C2018/10/11 09:45:09 PIM: Terminating on signal SIGINT
2018/10/11 09:45:09 PIM: VRF Deletion: default(0)
Fixes: #3161
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
fabricd is built using the sources of isisd. To allow differentiation
in the code, -DFABRICD=1 is added to its preprocessor flags.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Sometimes a error state is detected when we have added
new code to FRR, but not updated all the places that
we should have. Consider this a developmental escape
that needs to be fixed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add a new error code LIB_ERR_SYSTEM_CALL to the ferr subsystem.
Additionally convert LIB_ERR_VRF_SOCKET to a more generic
LIB_ERR_SOCKET.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are logging a commands via the `log commands`
cli, use zlog_notice instead of zlog_err, since that
this is not an actual error situation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com.
Implement vty shell integration and allow `bfdd` to be configured
through FRR's vtysh.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
When reading the config file add an ability to know
if we have properly read in anything. So that a daemon
can make fallback plans.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
