the "static const" inside DECLARE_MTYPE still causes issues on gcc -O0
(re. gcc bug 69981). Work around by disabling MTYPE declarations for
ospfclient.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
-c was previously ignored when -C (dryrun/config-check) was present.
Change so that -C -c creates an useful dry-run mode.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Test uninstall_element(). The commandline-specified counter allows
isolating memleaks more closely, differentiating one-off vs. repeated
leaks.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Merge the parsed graph into the existing one as a separate step. This
makes it possible to merge identical subgraphs, which is used e.g. in
bgpd for <A.B.C.D|X:X::X:X|WORD> neighbor names.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Like config_write(), this should use rename(), even though atomicity is
not a real issue here.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Pulling in source files from another directory breaks automake's
distclean target, and there seems to be no good fix for this...
(particularly since we need -fPIC build for a DSO here, while ospfd
compiles for an executable...)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
sync() has a HUGE impact on systems that perform actual I/O, i.e. real
servers...
Also, we were leaking a fd on each config write ever since
c5e69a0 "lib/vty: add separate output fd support to VTYs"
(by myself :( ...)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
sync() has a HUGE impact on systems that perform actual I/O, i.e. real
servers...
Also, we were leaking a fd on each config write ever since
c5e69a0 "lib/vty: add separate output fd support to VTYs"
(by myself :( ...)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Don't leak a socket when we are unable to set it
as non-blocking and warn the user as appropriate.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Fix two small memleaks in the CLI code and check the return values of
getsockname() and getpeername().
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Problem:
1 - Add a static route: "ip route 10.0.0.0/24 172.16.1.1";
2 - Receive an LDP mapping for 10.0.0.0/24 from 172.16.1.1;
3 - Remove the static route: "no ip route 10.0.0.0/24 172.16.1.1".
4 - Static route is removed but not uninstalled from the kernel.
What happens is that, on static_uninstall_route(), we can't find the
route we want to uninstall because it has an LDP label where the original
static route doesn't have any MPLS label.
To fix this, we can just stop calling static_nexthop_label_same() and
remove this function. It's impossible to have two routes for the same
prefix with the same distance and same nexthop address. This means that
we can lookup the correct route to uninstall without having to check
its labels.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Cleanup the in_ifname and out_ifname buffers
to be large enough to hold the actual interface
names.
Additionally move the common variables to be defined
once, instead of inside of multiple for loops
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
dn_flag was tested inside of a 'use_json' block
further down in the function. Move initialization
of the value to outside of the !use_json if statement
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
