CR, NL and CRNL are all OK, but CRNL shouldn't get treated as 2
newlines (which causes an empty command to be executed => empty prompt
line.)
Signed-off-by: David Lamparter <equinox@diac24.net>
The FDs are in struct vty, and there's ->fd and ->wfd, which shouldn't
be confused. Passing vty_sock along separately just creates mixups.
Signed-off-by: David Lamparter <equinox@diac24.net>
The return code from smux_trap is never used. If we have
never used it after all this time. Remove the return from
the function.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Neither tabs nor newlines are acceptable in syslog messages. They also
break line-based parsing of file logs.
Signed-off-by: David Lamparter <equinox@diac24.net>
The logging code writes log messages with a `\n` line ending, meanwhile
the VTY code switches it so you need `\r\n`...
And we don't flush the newline after executing a command either.
After this patch, starting daemons like `zebra/zebra -t` should provide
a nice development/debugging experience with a VTY open right there on
stdio and `log stdout` interspersed.
(This is already documented in the man pages, it just looked like sh*t
previously since the log messages didn't newline correctly.)
Signed-off-by: David Lamparter <equinox@diac24.net>
... in case the user does something like `zebra 3>logfile`. Also useful
for some module purposes, maybe even feeding config at some point in the
future.
Signed-off-by: David Lamparter <equinox@diac24.net>
mallinfo() is deprecated as of glibc 2.33 and emits a warning if used.
Support mallinfo2() if available.
Signed-off-by: Quentin Young <qlyoung@qlyoung.net>
The VRF must be marked as configured when user enters "vrf NAME" command.
Otherwise, the following problem occurs:
`ip link add red type vrf table 1`
VRF structure is allocated.
`vtysh -c "conf t" -c "vrf red"`
`lib_vrf_create` is called, and pointer to the VRF structure is stored
to the nb_config_entry.
`ip link del red`
VRF structure is freed (because it is not marked as configured), but
the pointer is still stored in the nb_config_entry.
`vtysh -c "conf t" -c "no vrf red"`
Nothing happens, because VRF structure doesn't exist. It means that
`lib_vrf_destroy` is not called, and nb_config_entry still exists in
the running config with incorrect pointer.
`ip link add red type vrf table 1`
New VRF structure is allocated.
`vtysh -c "conf t" -c "vrf red"`
`lib_vrf_create` is NOT called, because the nb_config_entry for that
VRF name still exists in the running config.
After that all NB commands for this VRF will use incorrect pointer to
the freed VRF structure.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Valgrind reports:
469901-==469901==
469901-==469901== Conditional jump or move depends on uninitialised value(s)
469901:==469901== at 0x3A090D: bgp_bfd_dest_update (bgp_bfd.c:416)
469901-==469901== by 0x497469E: zclient_read (zclient.c:3701)
469901-==469901== by 0x4955AEC: thread_call (thread.c:1684)
469901-==469901== by 0x48FF64E: frr_run (libfrr.c:1126)
469901-==469901== by 0x213AB3: main (bgp_main.c:540)
469901-==469901== Uninitialised value was created by a stack allocation
469901:==469901== at 0x3A0725: bgp_bfd_dest_update (bgp_bfd.c:376)
469901-==469901==
469901-==469901== Conditional jump or move depends on uninitialised value(s)
469901:==469901== at 0x3A093C: bgp_bfd_dest_update (bgp_bfd.c:421)
469901-==469901== by 0x497469E: zclient_read (zclient.c:3701)
469901-==469901== by 0x4955AEC: thread_call (thread.c:1684)
469901-==469901== by 0x48FF64E: frr_run (libfrr.c:1126)
469901-==469901== by 0x213AB3: main (bgp_main.c:540)
469901-==469901== Uninitialised value was created by a stack allocation
469901:==469901== at 0x3A0725: bgp_bfd_dest_update (bgp_bfd.c:376)
On looking at bgp_bfd_dest_update the function call into bfd_get_peer_info
when it fails to lookup the ifindex ifp pointer just returns leaving
the dest and src prefix pointers pointing to whatever was passed in.
Let's do two things:
a) The src pointer was sometimes assumed to be passed in and sometimes not.
Forget that. Make it always be passed in
b) memset the src and dst pointers to be all zeros. Then when we look
at either of the pointers we are not making decisions based upon random
data in the pointers.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This didn't exist yet when the xref code came around, and since
frrtrace() gets collapsed to nothing by the preprocessor when
tracepoints are disabled, it didn't cause any compiler errors...
Signed-off-by: David Lamparter <equinox@diac24.net>
gcc fucks up global variables with section attributes when they're used
in templated C++ code. The template instantiation "magic" kinda breaks
down (it's implemented through COMDAT in the linker, which clashes with
the section attribute.)
The workaround provides full runtime functionality, but the xref
extraction tool (xrelfo.py) won't work on C++ code compiled by GCC.
FWIW, clang gets this right.
Signed-off-by: David Lamparter <equinox@diac24.net>
The function smux_trap only allows the paaasin of one index which is
applied to all indexed objects. However there is a requirement for
differently indexed objects within a singe trap. This commit
introduces a new function smux_trap_multi_index which can be called
with an array of indices. If this array is onf length 1 the original
smux_trap behaviour is maintained. smux_trap now calls the new
function with and index array length of 1 to avoid changes to
existing callers.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
Add defines for IANA SNMP routing protocol values
Add macro for returning an IPv6 address to the SNMP agent.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
Add if_vrf_lookup_by_index_next to get the next ifindex in a vrf
given the previous ifindex or 0 for the first.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
Add SNMP support for L3vpn Vrf table as defined in [RFC4382]
Keep track of vrf status for the table and for future traps.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
Run through the vrf's interface list and return a count, skipping
the l3mdev which has a name which matches the vrf name.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
We don't use `%n` anywhere, so the only purpose it serves is enabling
exploits.
(I thought about this initially when adding printfrr, but I wasn't sure
we don't use `%n` anywhere, and thought I'll check later, and then just
forgot it...)
Signed-off-by: David Lamparter <equinox@diac24.net>
Description: When we get a new vrf add and vrf with same name, but different vrf-id already
exists in the database, we should treat vrf add as update.
This happens mostly when there are lots of vrf and other configuration being replayed.
There may be a stale vrf delete followed by new vrf add. This
can cause timing race condition where vrf delete could be missed and
further same vrf add would get rejected instead of treating last arrived
vrf add as update.
Treat vrf add for existing vrf as update.
Implicitly disable this VRF to cleanup routes and other functions as part of vrf disable.
Update vrf_id for the vrf and update vrf_id tree.
Re-enable VRF so that all routes are freshly installed.
Above 3 steps are mandatory since it can happen that with config reload
stale routes which are installed in vrf-1 table might contain routes from
older vrf-0 table which might have got deleted due to missing vrf-0 in new configuration.
Signed-off-by: sudhanshukumar22 <sudhanshu.kumar@broadcom.com>
This allows grabbing a list of all DEFUNs and their help texts through
the xref extraction mechanics.
Signed-off-by: David Lamparter <equinox@diac24.net>
This allows extracting a list of all log messages including their ECs
and autogenerated unique IDs for them.
Signed-off-by: David Lamparter <equinox@diac24.net>
Our "true" libraries (i.e. not modules) don't invoke neither
FRR_DAEMON_INFO nor FRR_MODULE_SETUP, hence XREF_SETUP isn't invoked
either. Invoke it directly to get things working.
Signed-off-by: David Lamparter <equinox@diac24.net>
This adds the machinery for cross reference points (hence "xref") for
things to be annotated with source code location or other metadata
and/or to be uniquely identified and found at runtime or by dissecting
executable files.
The extraction tool to walk down an ELF file is done and working but
needs some more cleanup and will be added in a separate commit.
Signed-off-by: David Lamparter <equinox@diac24.net>
Makes more sense to have this as a static inline. Also I don't want to
be forced to link network.o into clippy ;)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The output from `show thread cpu` was not lined up appropriately
for the header line. As well as the function name we were
calling in the output. Fix it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In 5a3cf85391 the trailing empty line
following the "show ip(v6) route" header was removed. Restore it for
consistency.
Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>
