Replace all `random()` calls with a function called `frr_weak_random()`
and make it clear that it is only supposed to be used for weak random
applications.
Use the annotation described by the Coverity Scan documentation to
ignore `random()` call warnings.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Rather than doing a f*gly hack for the RPKI code, let's do an on-exit
hook in cmd_node. Also allows replacing some special-casing in the vty
code.
Signed-off-by: David Lamparter <equinox@diac24.net>
And again for the name. Why on earth would we centralize this, just so
people can forget to update it?
Signed-off-by: David Lamparter <equinox@diac24.net>
Same as before, instead of shoving this into a big central list we can
just put the parent node in cmd_node.
Signed-off-by: David Lamparter <equinox@diac24.net>
There is really no reason to not put this in the cmd_node.
And while we're add it, rename from pointless ".func" to ".config_write".
[v2: fix forgotten ldpd config_write]
Signed-off-by: David Lamparter <equinox@diac24.net>
The only nodes that have this as 0 don't have a "->func" anyway, so the
entire thing is really just pointless.
Signed-off-by: David Lamparter <equinox@diac24.net>
This is a full rewrite of the "back end" logging code. It now uses a
lock-free list to iterate over logging targets, and the targets
themselves are as lock-free as possible. (syslog() may have a hidden
internal mutex in the C library; the file/fd targets use a single
write() call which should ensure atomicity kernel-side.)
Note that some functionality is lost in this patch:
- Solaris printstack() backtraces are ditched (unlikely to come back)
- the `log-filter` machinery is gone (re-added in followup commit)
- `terminal monitor` is temporarily stubbed out. The old code had a
race condition with VTYs going away. It'll likely come back rewritten
and with vtysh support.
- The `zebra_ext_log` hook is gone. Instead, it's now much easier to
add a "proper" logging target.
v2: TLS buffer to get some actual performance
Signed-off-by: David Lamparter <equinox@diac24.net>
Since we've been writing out "frr version" and "frr defaults" for about
a year and a half now, we can now actually use them to manage defaults.
Signed-off-by: David Lamparter <equinox@diac24.net>
This allows to set motd from an input instead of creating a file.
Example:
root@exit2-debian-9:~/frr# telnet 127.0.0.1 2605
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Hello, this is bgpd
User Access Verification
Password:
exit2-debian-9> enable
exit2-debian-9# sh run
Current configuration:
!
frr version 7.3-dev-MyOwnFRRVersion
frr defaults traditional
!
hostname exit2-debian-9
password belekas
log file /var/log/frr/labas.log
log syslog informational
banner motd line Hello, this is bgpd
!
!
!
line vty
!
end
exit2-debian-9#
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
nb_candidate_edit() was calling both the lyd_schema_sort() and
lyd_validate() functions whenever a new node was added to the
candidate configuration. This was done to ensure the candidate
is always ready to be displayed correctly (libyang only creates
default child nodes during the validation process, and data nodes
aren't guaranteed to be ordered by default).
The problem is that the two aforementioned functions are too
expensive to be called in the northbound hot path. Instead, it makes
more sense to call them only before displaying the configuration
(in which case a recursive sort needs to be done). Introduce the
nb_cli_show_config_prepare() to achieve that purpose.
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.
Commit eaf6705d7a fixed a problem caused by configuration changes
coming from the kernel. The fix consisted of regenerating the
candidate configuration before every configuration command (when
using the non-transactional CLI mode). There's no need, however,
to regenerate the candidate when it's identical to the running
configuration. Since the northbound keeps track of the version
of each configuration, we can use that information to prevent
regenerating the candidate configuration when that is not necessary.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This implements BMP. There's no fine-grained history here, the non-BMP
preparations are already split out from here so all that remains is BMP
proper.
Signed-off-by: David Lamparter <equinox@diac24.net>
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>
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>
Added a CLI "debug route-map" to enble route-map debugs
Added debugs for following triggers
1. Add/delete a route-map
2. Add/delete a sequence in route-map
3. Add/delete a match statement(dependency)
4. Update a dependency
5. Apply a route-map
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
Although the RFC states hostname length should be < 255 chars,
FRR allows infinite length technically. However, when you try
to set a hostname > 80 chars, you would immediately notice a crash.
RCA: Crash due to buffer overflow. Large buffer sprintf'd into smaller
buffer. Usage of sprintf function instead of snprintf which is safer.
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
It doesn't make much sense for a hash function to modify its argument,
so const the hash input.
BGP does it in a couple places, those cast away the const. Not great but
not any worse than it was.
Signed-off-by: Quentin Young <qlyoung@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>
Two different definitions of "enum filter_type" exist in libfrr:
one in lib/filter.h and other in lib/command_match.h. Rename one
of them to resolve a conflict that happens when both headers are
included by the same file.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
FRR log targets are independent, so "log syslog" must not disable
"log file" output.
Fixes: #3551
Fixes: 0204baa876
Signed-off-by: David Lamparter <equinox@diac24.net>
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>
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 editing the candidate configuration, the northbound must ensure
that either all changes made by a command are accepted or none are.
This is done to prevent inconsistent states where only parts of a
command are applied in the event any error happens.
The previous API for converted commands, the nb_cli_cfg_change()
function, required callers to pass an array containing all changes
that needed to be applied in the candidate configuration. The
problem with this API is that it was very inconvenient for complex
commands, which change different configuration options depending
on several factors. This required users to manipulate the array
of configuration changes using low-level primitives, making it
complicated to implement some commands.
To solve this problem, introduce a new API based on the two following
functions:
- nb_cli_enqueue_change()
- nb_cli_apply_changes()
The first function is used to enqueue configuration changes, one
at time. Then the nb_cli_apply_changes() function is used to apply
all the enqueued configuration changes.
To implement this, a static-sized array was allocated in the "vty"
structure, along with a counter of enqueued changes. This eliminates
the need to declare an array of configuration changes in every
converted CLI command, simplifying things quite considerably.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
